music-synthesizer-for-android

This is for Cortex A8, which was the chip in the Nexus One. I wrote the original version of sound synthesis directly in ARM assembler[1]. It was very highly optimized, I remember using a cycle counting app that flagged any dependency chain that would cause the processor to stall, and ultimately utilization was in the 90%+ range. Back in those days, processors were simple enough you could do this kind of optimization by hand. By the time of Cortex A15 (Nexus 10 etc), instruction issue was out-of-order and much harder to reason about. The best current info I could find for the latency advice is [2]. Quoting, "Moving data from NEON to ARM registers is Cortex-A8 is expensive." Looking at [3] partially reveals the reason why: the NEON pipeline is entirely after the integer pipeline, so moves from integer to NEON are cheap, but the reverse dire

The specific thing I've found least documented, yet most important for the distinctive percussive attacks of the DX7, is a random variation of the pitch envelope for the first few milliseconds of the note. That's almost short enough it could be done in the firmware, but I believe it might be in the hardware. It's not present in the msfa source, but might have been recovered by later Dexed authors (I haven't carefully looked at their code). If you get to the envelope hardware, you'll find it's just as clever as the exponential and sine generators. There's some info at [1], but it doesn't capture every single thing I found - there are cases where there is a slight amount of additional noise in the amplitude, I'm not sure whether intentional to give more character or an unintentional artifact. That's also missing from the msfa source. [1]: h

https://github.com/google/music-synthesizer-for-android/tree... has an experimental port, but I'd consider it a starting point, not a polished web app. ETA: there's also https://www.webaudiomodules.org/wamsynths/webdx7/ , but sound is pretty crackly on my setup :/

Not sure exactly what you're asking, that sounds pretty much like what that is. See in particular https://github.com/google/music-synthesizer-for-android/blob...

Sure, it's https://github.com/google/music-synthesizer-for-android . You probably want the "webaudio" branch.

Thank you! Didn't knew that about LFO. And I just found your wiki page [1], it's very informative. So I would like direct any curious reader there :) [1] https://github.com/google/music-synthesizer-for-android/blob...

Shameless self-promotion. There's a high performance C++ (with neon simd acceleration) implementation at [0]. Note, this also compiles cleanly to wasm and runs in the browser (see the "webaudio" branch). This code is also the basis of the reasonably popular free "dexed" vst. Some of my analysis of the DX7 is on the associated wiki as well. Not to take anything away from the original posting, but if performance is a goal, this may be interesting. [0]: https://github.com/google/music-synthesizer-for-android

An example of the linear-interpolated lookup table approach using fixed-point math is the sine generation[0] in my music synthesizer. It generates a table of 1024 entries, then lerps between those. This gives you precision beyond the least perceptible audio error, and is pretty fast. When I first wrote that code, I was targeting 32 bit ARM, with possibly very weak floating point units. These days, on the types of chips you'd see in phones (or computers in the $9-$40 range like rpi 3), the floating point calculation is _so_ fast (especially with simd) that the cost of the memory lookup starts dominating. So, the NEON implementation computes 4 sin values in a gulp, using a floating point polynomial approximation about the same precision as above[1]. [0] https://github.com/google/music-synthesizer-for-android/blob... [1] https://github.com/g

Very cool, looks like clean code. Have you compared performance against https://github.com/google/music-synthesizer-for-android/tree... ? I obsessed quite a bit over the NEON in that.