digitalwhitebyte wrote:Tried to populate the wave_array with my wavetable, and after a certain number,
it depends on how big each table, you receive an error message >> OUT OF MEMORY
Oooh - thanks for the report DWB; I hadn't got as far as populating the whole table, so I hadn't seen this before.
Needs a bit of testing, I think - to see if it just the wave array that has a limit, or whether it is affected by the "intermediate" values being stored in e.g . float arrays etc.
Of course, one could make the wavetables smaller, but I chose to stick with 2048, as theoretically that keeps the sound good down to ~20Hz - would be nice not to lose that.
However, in the worst case, it would be possible to do away with the Array IF that is the only limitation - the different waves could all be within a single 'mem' and indexed by sample pointers. I have never encountered a problem loading large wave files into a regular 'mem' - but then again, maybe I just haven't tried hard enough!!
Irminsul wrote: In general, I'd like to ressurect the spirit of the PPG and Prophet Synths
I think we are thinking along very similar lines!
The wave-sequencing and vestor synthesis of those old synth is something I would love to re-create - there are just certain sounds that are easier to make that way than any other.
Irminsul wrote:Oh snap, my bad - i thought that using as many "green" parts as possible will save the CPU. But "mixing green waveforms" and "mixing stream waveforms" gives the same audible effect, right?
The final audio output for any given mix would be exactly the same, yes - and green would save CPU load overall if it could be used. The trouble is just with the speed that green calculations can be done - crossfades would not smoothly change from sample to sample, but in a series of little steps that would lead to bad "zipper" noise.
Irminsul wrote:- Does bigger number of sample arrays means better quality, or simply a longer duration of waveform? (if latter, then maybe a size of 256 could
For a wavetable, the number of samples in the table affects the purity of the sound at low frequencies - ideally, you want enough samples that the oscillator doesn't have to calculate any "in between" samples at the lowest frequency you want to use. For example, if we assume a 44100Hz sample rate, and we want our pitch to go down to 20Hz, we need...
44100 / 20 = 2205 samples
...and so we use 2048 because it is the nearest power of two.
The reason for the greedy memory that DWB pointed out, is that a 2048 sample waveform requires 1024 differently filtered version of the wave to make up the complete table (number of tables = wave size / 2) - so in total each table is 2048 * 1024 = 2097152 samples. So yes, if shrinking the tables doesn't affect the sound too badly, smaller ones would be good to save a lot of memory - 1/2 wave size => 1/4 memory used.
It's worth noting that there is often a bit of confusion here because the term "wave table" is used in two different ways...
1) In the 'PPG'/Waldorf sense - a set of waves of different shapes that get faded together to make evolving waveforms.
2) In the FS primitives sense - the set of waves are all the SAME waveform, but each with different harmonics filtered out, chosen according to frequency so that the oscillator doesn't create aliasing distortion.
Particularly confusing for this project, as we are trying to do both things in the same oscillator!
Irminsul wrote:- Can it handle a large number of waveforms, e.g. a few thousand?
From what DWB has found out, not if they all need to be kept in memory at the same time - it would be possible to have tables loaded from HDD as wave files though, so that each patch could have it's own smaller set of waves - and you can save a whole wavetable as a single file so that it doesn't need re-calculating every time. This would slow down patch changes a bit, but it would make the synth much more versatile, and allow the end user to add their own custom waveforms.
Irminsul wrote:- Could this work with polyphony? (So when a new voice is triggered, morphing sequence starts from the beginning)
Yes - this is another reason for doing it all using the stream components. If you delete the links to the output section, and replace with a poly to mono "combiner", all of the stream sections should immediately become poly.
This will allow every poly voice to have its own mix of waves independently of all the others.
And, yes - a morphing sequence with a nice long multi-stage envelope curve (tempo synchronised) is exactly what I've been thinking about - it's really nice to have a few people who share the same interest and want to contribute to the project!
About the ideas you proposed - all good!
Looking into the memory problem, and optimising performance are top priority at the moment - it needs to be robust (no memory errors!), and to have low enough CPU that multiple oscillators don't strain everyone's CPU.
Beyond that, well I'd like to take up some of your ideas myself - but ideally it would be made into a single oscillator modules - as easy to use as any other oscillator, except with an extra modulation input that folks could connect up to whatever crazy mod sources and GUI they fancied.
The motion recording particularly interests me - I've implemented it already in my SM "Soopa Loopa" project, so have much of what's needed worked out already. Compared to LFO's, envelope graphs, I find it really the most intuitive way to add musical modulation to a sound - no numbers to worry about, or fiddling with the mouse; just play what you want to hear from your controller, and get the hell on with making some music! That one is definitely on my "to do" list.
Thanks all for your comments - it's nice to see this old project rolling again.
Very busy with work just at the moment (big product release that I have to prepare for), so I doubt I'll be doing much for the next week or so - but keep the mod's, bug reports, ideas coming, this could shape up to be something very nice indeed!
