symstym

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

You may appreciate this poignant sci-fi short story/video that references and expands on the story of Alex: https://vimeo.com/195588827

This seems similar to Zig (https://ziglang.org/#Compile-time-reflection-and-compile-tim...)

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.

A while back I found out that the popular Serverless framework/library tracks and reports back usage (https://serverless.com/framework/docs/providers/aws/cli-refe...). This similarly struck me as really out of place, and (at the time at least) it didn't seem sufficiently disclosed or described in the docs. If I NPM install it and invoke it, have I implicitly agreed to this?

Nice! Have you seen this similar project? If not sure if there are any ideas to be borrowed, but it sounds like it achieved excellent accuracy: https://github.com/AlbertoSabater/subtitle-synchronization

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.

It's been under development for a very long time in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=469639

I think there were some false starts where previous specs were written and then found to have issues.

Thanks! After a certain point it felt like a dead end to me, so I dropped it in favor of exploring something more along the lines of a JS-based Max/MSP. But it is surprising how much fun can be had with the small number of modules available in Plinth.

The ability to build primitive synths in a few lines of code (w/o library dependencies) is fine and well, but should not have been a priority for becoming a web standard. What's desperately needed is a well-designed low-level API. That could have been done years ago, and then if there was still sufficient demand for built-in nodes, those could have been added later.

As far as potential audience, in the time I've spent lurking in the Web Audio community, it seems like developers fall into one of two camps: 1) building toy projects for their own edification/learning, and happy to have the Web Audio API 2) trying to build a serious product (DAW, game, whatever) and super frustrated with the API. It seems pretty clear to me that end-users would be much better off if camp 2 had a good low-level API to work with.. camp 1 is not making much that gets used by end-users.

It's not "serious business" but this is the browser after all.

Modern JS performance is actually quite good, and WebAssembly is only going to make it better. I think you underestimate the potential of audio processing in the browser.

It's like a modular synthesiser.

I own hardware modular synths, and I built a proof-of-concept modular synth environment using the Web Audio API (https://github.com/rsimmons/plinth). The API makes it hard to build even simple things like well-behaved envelope generators or pitch quantizers. So even if you viewed the API as a sort of code-level modular synth environment, it's pretty unsuited to anything beyond trivial use cases.

The browser-based experimental/modular audio stuff that has any traction (e.g. https://github.com/charlieroberts) doesn't use the built-in nodes for these reasons.

I've spent quite a lot of time working with the Web Audio API, and I strongly agree with the author.

I got pretty deep into building a modular synthesis environment using it (https://github.com/rsimmons/plinth) before deciding that working within the constraints of the built-in nodes was ultimately futile.

Even building a well-behaved envelope generator (e.g. that handles retriggering correctly) is extremely tricky with what the API provides. How could such a basic use case have been overlooked? I made a library (https://github.com/rsimmons/fastidious-envelope-generator) to solve that problem, but it's silly to have to work around the API for basic use cases.

Ultimately we have to hold out for the AudioWorklet API (which itself seems potentially over-complicated) to finally get the ability to do "raw" output.

Bresenham's algorithm is also the best way to compute Euclidean Rhythms (rhythms where N hits are maximally-evenly distributed among M possible steps).

Did you read the whole article? I don't think it was implying anything negative about tech workers or making value judgements. I am frustrated by some of the same things you are, but I don't think they were present in the article.

To me it was saying something pragmatic like "Now that advances in technology are taking care of more and more of our material needs while requiring less labor, there is a relative need/opportunity for workers in roles requiring especially-high emotional skills and endurance". Would you disagree with that?

The example code inline in the article just illustrates the basic idea of Evolution Strategies (ES), not their new work in applying ES.

The behavior of agents is determined by a "policy function". This function takes in inputs (e.g. what the agent sees) and outputs actions (e.g. what the agent does). The policy function has a set of internal parameters that determines the precise mapping from inputs to outputs.

In their work, they used a neural network as the policy function. The parameters are just all the weights of the network.

In a simple version, you start with some random weights for the NN. Then you make many copies of the network, each with a slight random variation made to the weights. For each of these altered networks, you use them to control an agent for a while, and see how well the agent performs during that trial period. Based on how well the different variations do during their trial runs, you adjust the weights of the network a small amount. You adjust the weights to be more similar to the variations that did well. Then you repeat the process indefinitely (generate new variations, test them, etc.).

Evolution Strategies is not an example of Genetic Programming, and that book by Langdon doesn't cover anything directly relevant to the linked article.

This definitely seems to set a new bar in terms of simplicity for integrating with a backend, which is nice, but this bit is concerning: "jindo will replay every jindo event that has occured on that website". That would presumably need to change if it were to scale beyond a small amount of history, though then I wonder if you can keep the model as simple as it is now.

Success has many fathers; failure is an orphan.

Long ago I got tired of Evernote's bugs and creep of extraneous features and switched to Workflowy [1] for the majority of my general (plaintext) note-taking. I love Workflowy and can't imagine life without it.

[1] https://workflowy.com/

http://fpvlab.com/forums/

http://youtube.com/watch?v=L55M7_gu87I around 2:19

It was fruit juice and boric acid.. not sure what came of it.

http://www.nytimes.com/2011/09/27/health/27mosquito.html

This brings to mind A Declaration of the Independence of Cyberspace, by John Perry Barlow, one of the founders of the EFF:

https://projects.eff.org/~barlow/Declaration-Final.html

It was written in 1996 but feels more relevant as every year goes by.