Assembly is not inherently faster than compiled C++ code, and in fact will likely be slower due to the difficulties in optimizing assembly compared to C++. It will also make the code less portable, and far more difficult to maintain. If C++ is written and optimized properly it will run as fast as assembly and with the same efficiency.
Apart from device boot, and boot loader utilities, I am not aware of anyone coding digital effects in assembly for any hardware effects devices.
I’m working on a true stereo bucket brigade delay at the moment, but there is a lot of work involved, even with the BBD block availability in VSIG, and most of my algorithms available at https://godlike.com.au/index.php?id=420 (including delay algorithms) are true stereo as opposed to summed to mono. Sometimes stereo summing makes sense, especially for trigger/side chain signals, or where you are trying to emulate certain bits of hardware. It’s also not uncommon for a mono signal to be the source for reverb algorithms (especially the diffusion and ambience section), because if you look at large spaces in particular, any stereo source can be treated as mono because the separation of left and right in the source is very narrow compared to the size of the space. In reverb algorithms, the early reflection section is often stereo, with ambience using a summed signal as a source. This is due not only to delocalization of the sound in a real space, but also for processing requirements.
The only reverb algorithm that I know of that preserves stereo imaging is the dual mini verb algorithm on the KSP8. As Kurzweil state “With stereo material, any panning or image placement can be maintained, even in the reverb tails! This is pretty unusual behavior for a reverb, since even real halls will rapidly delocalize acoustic images in the reverberation. Since maintaining image placement in the reverberation is so unusual, you will have to carefully consider whether it is appropriate for your particular situation”
