Continuing discussion from https://sebiik.github.io/community.axoloti.com.backup/t/best-approach-for-additive-organ-patch/1638
http://electricdruid.net/technical-aspects-of-the-hammond-organ/
http://www.goodeveca.net/RotorOrgan/ToneWheelSpec.html
Say, we put a loops of every tonewheel oscillator into sdram, if we 'd use 128 oscillators, divided over 8MB sdram, that 'd be 64kB data per oscillator, or 32kSamples at 16bit.
If 48kHz samplerate is used for all oscillators, the loop length is 0.66 seconds, and all frequencies would need to be rounded to multiples of 1.5 Hz.That is not really long enough, the periodicity would be noticeable, and the frequency resolution not good enough for the bass tones. But the advantage is that interpolation is not needed, and when all the waves are interleaved in memory, transfer to SRAM can be done with DMA (12MB/s required, while the SDRAM bus allows 184MB/s bursts), the per-audio-sample workload is really multiplying each oscillator output with the corresponding amplitude and summing the results.
So with SDRAM we bump into a capacity limit while bandwidth is plenty. Some compromises are possible to reduce the size, like reducing the resolution to 8bit/sample, or reducing the samplerate. Samplerate could be reduced selectively, for instance running
- the top 16 oscillators at 48kHz samplerate
- the next 16 at 24KHz samplerate (1.33s loops)
- the next 16 at 12kHz (2.66s loops)
- the next 16 at 6kHz (5.33s loops)
- the remaining 64 at 3kHz (10.66s loops)
that adds a few interpolation filters to the workload, but this is not so much since this can be done after the tonewheel group summing.
Another option... sdcard streaming? Less bandwidth, but huge capacity...
Unlike current wave streaming objects, far larger buffers can be used, and only single buffers need to be read, containing all oscillator streams, interleaved...
Hmmmm that 'd also be useful in other contexts than drawbar organs.
For 128 streams at 48kHz/16bit the required bandwidth is 12228 kB/s, I haven't seen benchmark results that support this... Lowering the resolution to 48kHz/8bit requires 6114kB/s, close to what benchmarks with large buffer size indicate.
The quality reduction of 8bit may not be as bad as it looks, if proper dithering is used, this sort of samples does not need a significant dynamic range or any headroom. Still requires a bit too much bandwidth.
Reducing to 24kHz/8bit samplerate looks possible on paper, but that's a bit too aggressive, will lack presence in the sound.
Applying some other lightweight compression schemes could get it there, 4bit DPCM at 48kHz? Or reducing the oscillator count from 128 voices to 96 voices at 48kHz/8bit (4.6MB/s), benchmarks seem to support this bandwidth...
So how could it be partitioned in a patch and objects?
I think the 128 oscillators, vca's and summing should be one "monophonic" object, that accesses a table with the 128 amplitudes. The a polyphonic subpatch should add his weights to the amplitude table on note-on, remove his weights from the amplitude table on note-off...
Anyone interested to collaborate on this?
