4 ms·
Shameless plug I made an entire organ synthesizer in under 1024 bytes of html/js (use your keyboard): https://js1024.fun/demos/2022/23 https://js1024.fun/demo
by tomxor 4y ago
Shameless plug
I made an entire organ synthesizer in under 1024 bytes of html/js (use your keyboard):
https://js1024.fun/demos/2022/23 https://js1024.fun/demos/2022/23
source / instructions / background:
https://github.com/ThomasBrierley/js1024-mini-b3-organ-synth https://github.com/ThomasBrierley/js1024-mini-b3-organ-synth
The javascript was significantly reduced in size by using regpack, which is a regex based dictionary compression algorithm targetting very small self decompressing javascript. Writing for regpack takes some thinking because you have to try and make the code the most naturally self similar, which often means consciously avoiding more immediate space saving hacks in order to make larger sequences of characters identical - e.g it would usually make sense to not duplicate an expression, unless it's very short and only used a couple times, it usually makes sense to store it in a variable, but the character cost in defining the variable is actually larger than simply duplicating the expression through regpack (even if it's used a lot).
This might be worse than the lzw type compression used in HTTP, I haven't tested, but this was written for a code golfing competition where source size counts not transmitted size... Then again, conceptually this should lend itself to any any dictionary based compression, so zipping the original source (minus the whitespace), may also work out very well.
Here's a web interface that includes terser and regpack: https://xem.github.io/terser-online/ https://xem.github.io/terser-online/
Note that it's usually best to hand minify for regpack, terser is only convenient for removing whitespace, but advanced automated js compression libraries usually cause the size to inflate when regpack is the final stage.
[edit]
zipping the source comes in at 952 bytes - so it appears this technique applies when targetting dictionary compression in general, including the commonly used compression in HTTP.
- bheadmaster 4y agoI just wanted to say this is really impressive :) The latency is almost zero. I've always thought of "browser applications" as these heavyweight mammoths where each keystroke needs at least a couple hundred milliseconds to process. Good to know these kinds of things are still possible. Browser synthesizers have become my new point of interest :)
- tomxor 4y agoThanks :) I was pleasantly surprised with the latency too, admittedly the web audio engine of the browser is doing all the heavy lifting - I noticed that it seems to sacrifice audio quality for speed if you push it too far, e.g my struggle was with keeping the number of simultaneous oscillators low enough, if you ask to simulate too many then clipping will start happening all over the place since there is going to be some limit based on the CPU... I don't have much experience with audio programming but I expect for this reason additive synthesis is probably not efficient enough for anything that's not as simple as an organ.
- timxor 4y agoNice username!
- tomxor 4y agohaha, snap.
- squarefoot 4y agoJust wow! And you implemented working drawbars too, really impressive!