symstym

But remember, there's no such thing as a 10x engineer! /s

Sounds cool. If you haven't already, you might want to check out the Fractal Bits iOS app. It doesn't let you manually adjust parameters, only randomly generate sounds, but it makes some nice ones. It sounds probably FM-based to me.

I think this is a much better introduction than TLA, thanks.

This reminds me of some parts of Pieter Hintjens' book Social Architecture. He advocates that open source projects practice "optimistic merging" where essentially any patch that is well-formed should be accepted, without value judgement (though they may be reverted later). He argues that counterintuitively, this leads to better results than having gatekeepers. It seems pretty extreme, but similar in spirit to the idea of permissionless innovation.

I certainly don't think that the market selects good ideas or is sufficient to promote long-term advances. Per the bit of my comment that you quoted, I'm saying that the reason that the ideas are not in use (more) is that they haven't been incorporated into more compelling products. He feels that good ideas are not in wide use because we didn't "get" them or forgot them. I'm saying that sure, that may be part of the reason, but I think most of the reason is that certain ideas that seem good on paper are really hard to put into practice.

Quoting the talk:

> But I do think that it would be kind of a shame if in forty years we’re still coding in procedures and text files in a sequential programing model. I think that would suggest we didn’t learn anything from this really fertile period in computer science. So that would kind of be a tragedy.

Lots of people seem aware of the idea of coding without text files. There are some "visual" programming environments with traction (in the game dev world, Max/MSP). I'm even working on one myself! But there are significant downsides/challenges associated with this approach (more difficult to version control, often tied to one editor, etc.). So to his quote, the fact that we're still coding in text files may not be because we didn't learn anything, but because the idea of non-textual programming is hard to form into a product that more people want to use.

I agree with you that his talk is very valuable in terms of drawing attention to ideas that deserve more exploration, and I love the talk. It's just this one facet that I take issue with, the suggestion that the ideas haven't caught on because nobody appreciates them. His talks are frequently at the top of HN, they are widely appreciated. People have been super excited about related projects, like Light Table and Eve, and yet they haven't gotten much traction. So I think it's worth acknowledging that the problem is less idea-awareness and more compelling-implementation-difficulty.

I think this attitude of "we solved these problems decades ago!" is rather naive and sometimes arrogant.

I think it's a fantastic talk, and that Bret Victor and Alan Kay are geniuses. But I feel that they both promote the idea that we definitively solved all these important computing problems years ago, and that people are just too clueless/resistant to catch on. Yes, I agree that many good ideas have been culturally "forgotten". But for the most part, the reason these great past ideas are not in use is because nobody has made them into a compelling product.

Their attitude is comparable to someone saying "oh I invented the WWW in 1985 but nobody would listen to me", or "oh I invented Twitter before Twitter but users weren't enlightened enough to appreciate it". Almost all good ideas were already had before, but they are worth comparatively little, and unlikely to catch on, until they are reified into something that people want to use.

I agree with them that probably more people should be working in certain areas (e.g. new ways of programming). But if they really had it all figured out, then why haven't they themselves made the amazing new programming language that we all use? What if it's the case that some of their ideas are good in theory, but are hard to translate into a usable product? Most people accept that execution>>idea in the world of startups, but don't acknowledge that the same may apply here.

I'm not sure this is a constructive comment, but I just wanted to say that you are completely correct, everyone else is crazy, and I am baffled at how much confusion there seems to be over this topic.

One thing to add: Wikipedia sayeth "the eye senses brightness approximately logarithmically over a moderate range". If we go with that, then you presumably want to encode brightness logarithmically, and the number of bits you have available will determine the ratio between your adjacent quantized levels. In that case I believe the ratio between adjacent levels would be exp(ln(max_range_ratio)/(2^bits)).

"intelligence requires semantics and semantics is exactly what computers, by definition, lack"

This sort of assertion is experimentally untestable, not rigorously derivable from any axioms that people agree on, has no predictive power, and amounts to vague opinion passed off as fact. About a hundred years ago you might as well have been arguing about how "philosophically unsophisticated an idea like flying machines" was because flying is, strictly speaking, a behavior of flying animals.

Yes.. after I wrote my comment I was feeling a bit bad for sounding like I was just trashing the API. In a world where JS is slow and there is no worker thread machinery, yet you need low latency and flexible processing, the design makes more sense.

That being said, the AudioParam "automation" methods still make me want to cry.

That's unfortunate. I don't have a machine running Edge to test it on. It uses less than 20% of the CPU in Chrome on my 2012 Macbook Air. It's possible that it's a problem with my code, but in general the Web Audio API does not have very good cross-browser support.

> is Web Audio a mess mostly because it's an attempt to expose the features of the twenty-odd different OS audio backends

That is a good guess, but no. The main features of the Web Audio API (built-in nodes, etc.) are not backed by any kind of OS-level backend, it's all implemented in software in the browser. The spec design was based on what someone thought were useful units of audio processing. It's not a wrapping/adaptation of some pre-existing functionality.