Bandlimited wavetables

[Panoply]

Hi everyone,

I'm hoping for a bit of guidance on rebuilding the 'wave table read' module into something a bit more powerful. A 'wave table array read' module. Obviously, this requires a bit of work.

I'd like to use the data the wavetable 'set' primitive generates with the 'wave array read' primitive module, as this would allow me to build up an array of arrays and do things like the sync oscs you might see on a waldorf synth, or the wavetrip oscs, or the 'carbon' osc on Massive from NI, ie things that you can't do by fading between two oscs.

I'm pursuing this method rather than say doing the same thing in float arrays as float arrays simply are not fast enough for this purpose. Believe me, I've tried. Scanning through the wavetable in real time, is vital for this method, and rebuilding the wavetable after every tweak in the middle of a sound simply is not a viable option. Nor is stacking 128 wavetable oscs.

Of course, this generates a problem, all the wave read stuff freely aliases when stuff is pitched up. Which is why I'm trying to use the wavetable primitive - as this generates bandlimited single cycle waveforms in a big array - which is perfect. If I feed it an array of 2048 it comes back with a big array of 2097152 samples - 1024 very nicely FIR'd single cycle 2048 waveforms, with the most filtered waveform starting at array[0] and the least filtered cycle at array[2095104].

The issue comes with understanding the scaling of the array that is ouput from this wavetable primitive.

Now, these arrays are tricky to work with as I can't open them up exactly and have a look - that crashes SM, or maybe not, but I haven't got the patience to give it the time it would need to fill the text box on my rubbish old laptop.

But I'm struggling. If anything I'm worsening the aliasing. Some advice on how to work with this data would be appreciated. For example is it designed as 8 single wave cycles per midi note, or a new cycle every 1024th sub nyquist ... or ?

I could I suppose go into a wave editor, and do this work manual, with an FIR filter by hand, and put the output waveforms in an array I understand, but that would be time consuming to say the least - basically a (far) clearer explanation of the output of the wave table primitive would be much appreciated

[Dozius]

A couple of things from my own observations.

1) The number of tables changes based on the size of the original table. Seems to be that the number of tables is half the size of the original table size. e.g. 256 sample table results in 128x 256 sample tables. I'm not sure why it is calculated like this, it doesn't even seem like the correct way to do it at all. I've always read that generally you want to do one table per MIDI note.

2) Looking at the resulting table it would appear that the higher notes are first in the table. As can be seen in this spectrum shot of a saw table dump. You can clearly see the band limiting increasing as you get nearer the start. Another interesting thing to note, is that the first table is always all 0s.

saw table.png (206.41 KiB) Viewed 1453 times

Hope this helps some.

[Panoply]

Yeah, I was very surprised when I saw the size of the wavetable generated!

Alchemy for example lets you make your own oscillators, but in that case it uses 20, 1 for each half octave, and clearly states how the formula is derived, so I think there is no general consensus on the issue.

I'd figured out that the values towards the start of the array are the more filtered (therefore to be played higher) cycles, but without a clearer idea of how to scale the values, I'm a bit lost on how to progress.

I've attached a .osm so that just in case I'm doing something else that is going to cause the issues is obviously spotted by someone.

This is annoying tbh. This could be a way to generate a really powerful, great sounding oscillator that would be quick and efficient.


http://www.cosmonikaudio.co.uk/wavetablesnapshot.rar - 21.8 MB!!! why?

[Panoply]

Hmmm, no I get the concept ....

here is one of my own creation using 20 single cycles and a crappy read algo, which already sounds pretty good - obviously increasing the numer of cycles to per note is going to radically help eliminate transition.

much smaller in size!

The aliasing results TBH are pretty good. This sounds perfectly acceptable for a tech demo. Could sound great.

Guess we can do proper wavetables in SM after all

The construction is a pig though Gonna take around an hour to generate one waveform. Really would help if the method that is already in SM was a lot clearer, or the wavetable reader could handle realtime arrays of tables

[oddson]

@Panoply - I've not studied your effort above.. this is just to discuss the bandlimiting of the wavetables in the stock primitives.

Here's a little tool (using square waves as examples) for seeing the data is as Dozius has described -- at least for input tables to 512 size -- after that I'm not too sure what goes on.

{edit - I originally forgot to disable the limit on the loop for 1024 and larger arrays -- which is why I wasn't sure for sizes larger than 512 - with it disabled you need to be careful not to overload the memory etc.)

[oddson]

The issue comes with understanding the scaling of the array that is ouput from this wavetable primitive.

I'm not sure why it is calculated like this, it doesn't even seem like the correct way to do it at all. I've always read that generally you want to do one table per MIDI note.

It occurs to me that the differences between adjacent sub-tables are the result of exactly one new harmonic being added.
And that's the key to why the data is arranged as it is. To get the index of the starting table to use all you need to do is take the normalized frequency, find it's reciprocal (1/x) and round down to the nearest whole number. That is the number of harmonics that can be present in a wave with that fundamental below the nyquist -- and the data from the Wave Table primitive that starts at that sub-table will have just that many harmonics present.

Since the last table seems to be non-bandlimited it's likely best to never go past the second to last table even for the deepest bass note (why they didn't continue bandlimiting for the final table eludes me at present).

[Apologies if I'm missing something from what you're already doing... it seems much of what I've discovered on my own was already indicated in your posts above but it didn't make sense to me until I had a run at it myself.]

[Panoply]

hehe no problem, the more brains on it the better IME.

I've got a full range version of the last thing I posted working. Completely smooth, and sounds great. It takes probable half an hour to generate a waveform this way and to say it is tedious to have to copy and paste over a hundred single cycle waveforms (and they need to be carefully selected, to make sure I get a waveform after the FIR filter is stabled out, without pre-ring etc) would be a vast understatement.

However, I now have the oscillator I always wanted, just wish I didn't have to go around the houses.

[oddson]

i've got a full range version of the last thing I posted working. Completely smooth, and sounds great. It takes probable half an hour to generate a waveform this way and to say it is tedious to have to copy and paste over a hundred single cycle waveforms... would be a vast understatement...

So you've given up on using the wave table primitive to do bandlimiting for you?

[Panoply]

No, I'd still prefer to use this primitive, as it does the hard work for me

However, I've had a succesful day and have now largely automated my procedure.

I setup a sequencer project with a FIR filter going through 120 cycles of waves (six per freq, for safety). A nre set of waves are played every second. In between the waves playing the filter changes it's frequency.

This gives me a big file of progressively filtered waveforms with gaps inbetween.

I load this into SM and use the array section tool from the developer toolkit to loop through the wave, pulling out audio automatically and appending it into the 'wavetable'. Because the cycles are exactly a second apart, the gap inbetween the desired waveform for taking out the array remains static, as does the filter offset etc etc etc.

This isn't too shabby. I'd say after creating the actual waveform, the whole process takes no more than 5 minutes to generate a bandlimited wavetable. This is a length of time which makes proper wavetable generation a sensible proposition.

[Panoply]

well ... good news and very bad news

I got my wavetable working, and all was well. Great!

Then I looked at RAM usage

Turns out storing that much in the synth is totally unviable. In fact, I'd go so far as to say I've figured out why my synths are so RAM hungry. Gonna start storing waveforms outside of my synths as txt files, but even one oscillator constructed in the method I've described above sees a 100mb ish ram surge. Obviously not practical.

This leaves me back at looking at the wavetable primitive, although even this needs to be treated with care!

[Acrobat]

This leaves me back at looking at the wavetable primitive, although even this needs to be treated with care!

dunno if can interest you but my experience is I have a synth with 60 x 1024points wavetables, at loading time it needs just 2 or 3 seconds to load on a single processor Pentium 3.4Ghz. It's ultramegaok.

[oddson]

...This leaves me back at looking at the wavetable primitive, although even this needs to be treated with care!

I put together a rough-and-ready wave-morph example last night that used the Mem array primitives and the wavetable primitives with 1024 point wavetables and it was pretty darn quick. A couple of seconds to make an array of arrays of tables that had two different wave forms on each end and 1022 steps in between. (So that's 1024 samples/table *512 tables/array *1024 arrays * 4 bytes/sample = 2048MB of data)

I could even sweep through the arrays in realtime using just the Get At (so green data switching and no effort to avoid non-zero-crossing changes) and it sounded great. (Although I'm thinking you could get the same result panning between two oscillators but I was ONLY doing it to test the feasibility.)

With the Mem array primtive instead read you could do the same sort of thing without relying on green switching of arrays and even forcing changes at phase zero if what your trying to do requires it.

I'll post the example when I get home from work after I've had enought time to clean in up. Hopefully you'll find it helpful.

[oddson]

Turns out I had 256 point arrays so data needed as far less: 256*128*1024*4=128MB (OSM stored at 112 with SM's compression).

When I boosted up to the claimed rate above I ran out of memory.

[Panoply]

That is a pity, I was looking forward to that, but I think I get the general concept anyway

As personal quality thing I'd say that a wavetable has a minimum requirment of 1024 points ... less than that and the sound is definitely less 'natural'. Of course, if I were trying to emulate a PPG than thats different, but, I'm not, I'm trying to make a really really nice oscillator.

Has to be said that just using the nice interpolation from the toolkit on a basic wave is working wonders though ... so nice to hear a waveform in SM that is *completely* steady.

[Panoply]

Basically, I think high level wavearray oscs would be viable if we could stream from disk.

Lot of people seem to have been asking for this feature for a while.