How to fill up an array?
the problem is to fill an array offline with wav file data in SDK.
and i guess shroomz talks about that possibilities
that would at least allow us to build something like a virus wavetable oscillator for mod3. and similar stuff
the adavantage are that the wavetables are inside the mdl file, so you don`t have to distribute 128 wavefiles with your mdl file
and you get the waldorf like walkthrough different wavetables....
I would be completly happy if I can adress the array(WT) offline.
BTW tgstgs a delay is more or less a "realtime array".
and i guess shroomz talks about that possibilities
that would at least allow us to build something like a virus wavetable oscillator for mod3. and similar stuff
the adavantage are that the wavetables are inside the mdl file, so you don`t have to distribute 128 wavefiles with your mdl file
and you get the waldorf like walkthrough different wavetables....
I would be completly happy if I can adress the array(WT) offline.
BTW tgstgs a delay is more or less a "realtime array".
We're building some new array tools & have made some good progress, but I know for sure that the Waldorf Osc is very unusual in the way that it reads data from the arrays. Our understanding of it isn't yet complete, but from what we understand so far, it will be a lot of work just to put together a single wavetable.
Hi Hifiboom,
The Waldorf Osc reading strategy appears to be 16 blocks of 128. The major problem is that each block of 128 contains (what looks like) 7 octaves of waveform data. Each of these Octaves is represented by a half-cycle symmetrical waveform. In terms of the array structure that works out at sizes of 64, 32, 16. etc up to 16*128. The real issue with generating compatible wavetables is that it seems like each block of 128 not only includes octave sections, but is also morphing to the next block, hence making wavetable creation for these Osc's a relatively difficult task without a piece of software which auto creates the desired morphing based tables. If there's a way to do it in sdk, we've still to find it.
So where does this leave us? Well, so far we've managed to generate a sine wave.
Based on what we've learned it should be possible to put other symmetrical waveforms in there which means that sample data can to some extent be embedded in devices, but I wouldn't expect full blown wavetables from us any time soon.
The Waldorf Osc reading strategy appears to be 16 blocks of 128. The major problem is that each block of 128 contains (what looks like) 7 octaves of waveform data. Each of these Octaves is represented by a half-cycle symmetrical waveform. In terms of the array structure that works out at sizes of 64, 32, 16. etc up to 16*128. The real issue with generating compatible wavetables is that it seems like each block of 128 not only includes octave sections, but is also morphing to the next block, hence making wavetable creation for these Osc's a relatively difficult task without a piece of software which auto creates the desired morphing based tables. If there's a way to do it in sdk, we've still to find it.
So where does this leave us? Well, so far we've managed to generate a sine wave.
Based on what we've learned it should be possible to put other symmetrical waveforms in there which means that sample data can to some extent be embedded in devices, but I wouldn't expect full blown wavetables from us any time soon.
Try making a sequencer set eh. Lots of human batch processing in Scope DP, there is no such thing as automation...olase wrote:Ohhh...
Do that 2048 times for example, thats take time...
I thought there is any automatism...
more has been done with less
https://soundcloud.com/at0m-studio
https://soundcloud.com/at0m-studio
I know that it would lead to difficulties.
maybe we should simply put this somewhere into the SC device/sdk wishlist.
It`s def. on top of my personal wishlist. a felxible oscillator, with very high quality pitching algo based on wavs like the wav-oscillator but with some sort of antialiasing pre processing. and very high quality pitchshifting.
For example it sounds different if you take an analog recorded osc waveform and picth it in your wave editor with highest quality or if you do the same with the wav-osc in realtime.
and it should have a sync feature which the wav osc is missing at the moment.
Hi,
here's a visual representation of the first block of 128 from the Waldorf Osc's 1st wavetable (Wave #01). Each wavetable has 16 of these strung together to make up an array of 2048 with subtle differences between them creating the morph. This first block creates the first 4 of 64 morphing stages in Wave #01. Hope this helps.
here's a visual representation of the first block of 128 from the Waldorf Osc's 1st wavetable (Wave #01). Each wavetable has 16 of these strung together to make up an array of 2048 with subtle differences between them creating the morph. This first block creates the first 4 of 64 morphing stages in Wave #01. Hope this helps.
- Attachments
-
- Wavetable_Example.jpg (43.11 KiB) Viewed 2881 times
thanks for the info, shroomz,
don`t know exactly but it looks like the stages seem to represent some kind of pitching also...
not sure about this....
theoretically if i read through a wav file specification I could build some sort of wav to waldorf wavetable converting tool by programming a little tool.
but the question is : do we really want this? the waldorf oscillator is some sort of digital sounding oscillator and due to the small amount of samples per waveset it has inferior quality also intentionally like the original stuff sound digital also.
btw how did you visualize the array in that nice way?
I`m also working on a phase distortion waveshaper that can change the sound of an basic oscillator (sin, saw, tri) in drastical ways, still keeping the quality high.
My major plan with all this wav shaping and wav based oscillator stuff is, that it should give new sound options with out affecting the sound quality.
The Flexor draw waveshaper is a good approach, but its still not yet fixed regarding the jump point and so it delivers non-perfect results.
don`t know exactly but it looks like the stages seem to represent some kind of pitching also...
not sure about this....
theoretically if i read through a wav file specification I could build some sort of wav to waldorf wavetable converting tool by programming a little tool.
but the question is : do we really want this? the waldorf oscillator is some sort of digital sounding oscillator and due to the small amount of samples per waveset it has inferior quality also intentionally like the original stuff sound digital also.
btw how did you visualize the array in that nice way?
I`m also working on a phase distortion waveshaper that can change the sound of an basic oscillator (sin, saw, tri) in drastical ways, still keeping the quality high.
My major plan with all this wav shaping and wav based oscillator stuff is, that it should give new sound options with out affecting the sound quality.
The Flexor draw waveshaper is a good approach, but its still not yet fixed regarding the jump point and so it delivers non-perfect results.
Well, that's the point really. It was more of an exercise into understanding a bit more about arrays than anything because I can't see anyone here including myself making a better job of creating 64 wavetables for that osc than the ones Waldorf produced for it themselves. What's already there is everything you need for that osc & has that classic PPG sound.hifiboom wrote:but the question is : do we really want this?
oooh... that's a secret.btw how did you visualize the array in that nice way?
btw, regarding the wavetables we succeed to fill it based on integer values.
But what about converting the values into and float array.
As you can connect a float 128 array to the wshaper module and trasfer basic waveform through the waveshaper wuite nicely.
I did this by manually inputting different values into the 128 array slots. quite timeconsuming, but it can give some nice new waveshapes.
so we could build a basic wavetransformer around the wshaper.
But what about converting the values into and float array.
As you can connect a float 128 array to the wshaper module and trasfer basic waveform through the waveshaper wuite nicely.
I did this by manually inputting different values into the 128 array slots. quite timeconsuming, but it can give some nice new waveshapes.
so we could build a basic wavetransformer around the wshaper.
hurolura,
problem is that you can convert integer values to float values. but its difficult when it comes to converting integer arrays to float (1....0...-1) arrays.
@shroomz, I guess I understand how the waldorf oscillator works generally.
the first 64 samples are used for the lower octaves through the fact that downshifting doesn`t introduce aliasing
lets say the first 64 samples represent c3, then c2,c1 and c0 is done by downpitching the first 64 samples.
c4 is represented by the next 32 samples as pitching one octave higher should half the the wavecycle....
and so on
c5 16 samples
c6 8 samples
c7 4 samples
c8 2 samples
thats just how i image the generell workflow, I did not verify this.
the higher octaves representations may be antialiased to deliver better pitching quality.
thats why the look of the waves may change in the higher region.
so basically the first 64 samples represent the wave in its pure form, the higher regions the pitched versions.
just a wuick try to explain whats going on, but its not unlikely that I am wrong on this.
that would also explain the inferior quality of the waldorf osc in the down region, where it has no "pressure" and "depth" through a weaker downpitching.
it would be awesome if SC would build an oscillator with 2048 samples in lowest pitch (c0) and the other pitches are represented with fractions of this base picth : 1024 (c1) and so on, So you could use the high quality pitching of a wave editor to generate the octave pitch steps.....
and between the octaves another perfromance algo blend s through the picthings in a satisfieying way.
some sort of flexible and quality wave based oscillator.
just some sort of brainstorming from my side.
problem is that you can convert integer values to float values. but its difficult when it comes to converting integer arrays to float (1....0...-1) arrays.
@shroomz, I guess I understand how the waldorf oscillator works generally.
the first 64 samples are used for the lower octaves through the fact that downshifting doesn`t introduce aliasing
lets say the first 64 samples represent c3, then c2,c1 and c0 is done by downpitching the first 64 samples.
c4 is represented by the next 32 samples as pitching one octave higher should half the the wavecycle....
and so on
c5 16 samples
c6 8 samples
c7 4 samples
c8 2 samples
thats just how i image the generell workflow, I did not verify this.
the higher octaves representations may be antialiased to deliver better pitching quality.
thats why the look of the waves may change in the higher region.
so basically the first 64 samples represent the wave in its pure form, the higher regions the pitched versions.
just a wuick try to explain whats going on, but its not unlikely that I am wrong on this.
that would also explain the inferior quality of the waldorf osc in the down region, where it has no "pressure" and "depth" through a weaker downpitching.
it would be awesome if SC would build an oscillator with 2048 samples in lowest pitch (c0) and the other pitches are represented with fractions of this base picth : 1024 (c1) and so on, So you could use the high quality pitching of a wave editor to generate the octave pitch steps.....
and between the octaves another perfromance algo blend s through the picthings in a satisfieying way.
some sort of flexible and quality wave based oscillator.
just some sort of brainstorming from my side.