WTO: NrWav not slicing short files of single-cycle waveforms properly

Bug description:

The NrWav parameter in WTO does not appear to be slicing wavetables downloaded from waveeditonline properly. Each wavetable consists of 64 single-cycle waveforms at 16-bit, 44.1kHz. Each wave is 256 samples with an overall file length of around 371ms (16,384 samples).

When I load any of these files into WTO with NrWav set to the default 64, the oscillator is sampling 16 cycles (waves) as one waveform. The Z-axis rotates between 4 aggregated waves of 16 cycles, and the X and Y axis rotate between full and zero amplitude with no other timbral/structural changes in the wave.

When changing NrWav on these tables, the display doesn’t reflect the file getting sliced differently, nor do changes to the XYZ controls. I also tried pressing “Load” after changing NrWav to no effect. I tried 36 different wavetables, all with 64 single-cycle waveforms. Most of these are dumps from other instruments like Plaits, Braids, Prophet VS, MS2000, PPG Wave, etc. When loading the files in the input recorder or Audacity, the waveforms and whole file appear as expected.

When using NrWav values in the single digits (2-8), it’s unpredictable compared to the expected behavior. Values above 8-10 result in no change.

Bert commented on another thread about slicing wavetables into a 10x10x10 grid using a value of 1000. I looked into turning NrWav up to 512 or 1024 to further divide these tables, but the control stops at 255 with no change to the wave.

I can record a video if this needs a more detailed explanation.

Steps to reproduce:

  1. Load a wavetable file from waveeditonline (example Prophet VS table)
  2. Observe 16 single-cycle waves loaded as one waveform
  3. Using X and Y axis controls, observe amplitude drop to 0 by the midpoint of the range
  4. Using Z control, observe rotation through 4 pages of 16 cycles as one waveform then flattening to amplitude 0 in the later half of the control (>70% or so)
  5. Use NrWav control to adjust slicing away from 64
  6. Observe no change to the wavetable display or impact of xyz controls compared to previous

Software version: 20012020

Type: major - unable to use imported wavetables

Related questions:

  1. Does WTO expect a minimum length on the input file and/or might require a minimum number of samples per NrWav slice?
  2. Does the NrWav value reflect a decimal number of slices or 8-bit value of the control itself (0-255)? If the latter, is there a matrix/table for how that control value translates to number of slices?
2 Likes

There is info in the forum here that explains how the WTO works. It creates a 3D space from the WAV file you load, if you set NrWaves to 64 then you will get a 4x4x4 cell space (4 is the cube root of 64). In each cell there is a waveform. In this case the length of that waveform is 16384/64=256. When you change XYZ parameters you navigate this space, interpolating between the waveforms.

That might be the problem, the input file being too short. Copy-paste your wavetable a few times in audacity (concatenate the copies), then save and try again. I would also convert your wavetable to 32-bit 48kHz and see if that makes any difference.

See above.

There are 2 significant problems with this statement.

  1. “might” - You are the developer receiving a detailed bug report for a closed-source product. Literally the very least you can do is test this on the certified build under the conditions reported.

  2. Your suggestion for a labor-intensive workaround is unacceptable. Are you saying you expect SSP users to spend hours manually slicing and converting dozens of wavetable files that work on literally EVERY other wavetable module because your code is not tested with the most well-used source of wavetables on the Internet?

If WTO samples are only supported at a specific sample rate with a minimum required length, the documentation should clearly state that.

I was referencing that exact information when i created this post, and that is not an answer to the question asked. Please re-read my question in its entirety so you can better understand. Your statements do not match the module behavior in either display or function.

Again, why aren’t you or other members of the dev team testing these issues? Has this ever worked, or did the QA process not test this? Could this bug have been introduced in recent code? These are questions we cannot answer as users without access to the source and build environments.

Edit: I see @wavejockey and @MOTOKO liked the original post. Could I ask you to please try to reproduce this WTO bug if you have a chance?

To be honest, I didn’t understand this 100 percent. When I read this article, I probably understood that NrWav was not Morphing until 1-8(or 9). (This is still the case with any file.)

Anyway, I will run the test with your file. Which part should I focus on?

that is one of the less interesting side-effects on the SSP : in this age & day (that big display!), one can hope for on-screen reflecting input actions

i know there’s changed code for sample start/stop (a v short amplitude attenuation, fade in), so maybe that crept in somewhere?

will test later this we

i can’t get it to work properly either
it seems every (MIDI note) key triggers another slice of the wave
(MIDI pitch going to WTO pitch)
nr waves 1 or 255 doesn’t really make a diff. other than the top display being different
so at this moment it is not possible to play consistently a scale from the WTO

i don’t notice a drop in volume when going midway (i have MIDI gate routed to WTO amp and X/Y/Z routed to MIDI cc’s)

i tried with several wavetables (also other than you provided) , Single Cycle Waves won’t be recognized/loaded anyway, and with a common drumloop to get the feeling of hearing what i’m doing, but i’m hearing NOIZ - great if you’re into INDUSTRIAL music btw

what i noticed too, is if you assign X/Y/Z to a MIDI control, and put the initial value of the X/Y/Z >0, you cannot get past/below that value
more confusing & disturbing : if you turn the X/Y/Z encoder manually from 0->>99 you get a range double squares (2 squares in the display) but if you assign MIDI cc to X/Y/Z and change the value from 0-127 you only get 1 square of movement, which is definitely a bug i think
-edit 3/6 : i’ve added a zip with the used wavetables
Wavetables2.zip (51.2 KB)

I tried using waves from waveeditonline ( i used the app) and everything seem to work perfectly ok for me - as OP mention, its a great source for wavetables.

I dont see any of the issues mentioned in the original post.
perhaps there was something odd going on with the download, and so when im using the wave editor to download, and export its ok.
(this is more interesting to me, since the editor allows you to do some interesting changes to the wavetables :slight_smile: )

as @bert mentioned they are mapped onto a 4x4x4 cube, rather than the 8x8 (xy) that wave editor shows, but you can clearly see the shapes if you use x,y,z at 0,0.25,0.5,0.75.
the morphing is of course more interesting than if you use a x/y wavetable oscillators since you have so many more interpolation possibilities.

midi control also worked for me as expected…
eg. i assigned CC #1 to X, and could move thru the whole range.
what i did, was move x to 0.5, then send CC#1 to it, but rescaled so that its bipolar (-1,1) i.e x2 -1 - this to be is ‘as expected’ … midi cc are unipolar , but most inputs on the SSP are bipolar.

Thanks for getting back to me with an attempt to replicate the issue, Mark. I will make a video this weekend showing the behavior I’m experiencing.

1 Like

did you use the app? how did you copy the files to the SSP?
given your symptoms, id say the files are getting corrupted somewhere along the process.

here are the files i used that worked for me (exported via the wave editor app)

wt.zip (95.7 KB)

I’ll admit I ‘cheat’ to get these wavs to the SSP, I use an ethernet connection… so that i dont have to mess card readers. But I guess, you are able to transfer other samples across to the SSP without issue… so that shouldn’t be a problem?!

also as bert also pointed out, as these are 64 waves, you want NrWav set to 64

one thing to note… generally…
it may be that some wavetables are designed to be on an 8x8 grid,
if this is the case, when you morph with 4x4x4 you won’t really get the ‘designed’ morphing, since you are morphing between unintended points of the grid.
as i eluded to above, this can be an interesting thing.

i guess another thing you could do is combine 8 wavetables (8x8=64 waves), so forming a 8x8x8 cube (512 waves) - this would mean in 2 axis you would get the ‘designed’ morphing, and could switch wavetables ‘sets’ with the 3rd axis (and also morph that too)

(I’d need to test this :slight_smile: )

how do you re-scale your MIDI (cc) input ?

ok, will test furtherrrr then ;
as i can move all kinds of samples on the card of the SSP i think that won’t be the issue here
-the source of the wavetable shoudn’t matter either, as it should work with any wavetable
-some (sources) of these wavetables are very lo-fi, like 24 or 36 Khz samples - but the SSP should handle that correctly

so the NrWav defines the inital total number of waves in the wavetable?

with ‘combining 8 wavetables’ you mean, before import into the SSP, set them one after the other, and make 1 long wavetable?

all I/O can be scaled/offset on the network page. (since latest update?)

wavetable oscillators generally don’t care about sample rate.
the only thing that is important is to split the data correctly into single cycles.
thats why NrWavs is vital to be correct.

lo-fi will not make any difference, however, its quite common to get aliasing if you use small wavetables.
so personally, I look for larger single cycle waves not smaller.

there is no ‘initial’ about it :wink:
it defines the number of waves in the file you have loaded.

note: the wav file format, has no means of encoding this information - this is why the user has to set it appropriately.

yes.

wavetables are prepared on a desktop/laptop. (*) often using dedicated wavetable tools, but if you are careful you can do a certain amount with normal audio editors e.g. even with audacity (free) you could combine wav files - but its pretty easy to screw it up :wink:

at the end, all a ‘wavetable’ is, is a series of single cycle waves that are exactly the same length,
and the wavetable oscillator just needs to know how many there are, so it can ‘cut up’ that file correctly.
(they could work by being told the length instead, but its easier for end-users to think in terms of number of waves)

(*) I can’t think of any hardware synth that allows prepping of wavetables on board, its too much ‘fiddling’ to do on something without a full size monitor and a mouse.


there is one thing Im a bit ‘unsure’ on, which perhaps @bert could throw some light on…

how does a non-cubed number of waves get divided by x/y/z.

e.g. 9 (3x3x3) is easy, we have 3 axis each with 3.

but how does (NrWav) 12 wave get divided? 2.289 ^ 3 ?
can fractions of a wave be divided over an axis whilst still ensuring they are cycles?
seems odd in my head - but perhaps Im just ‘overthinking it’ , perhaps the maths ‘just work’ :wink:

Im just curious really, as I think id stick to x^3, just since it makes more sense to my brain!

1 Like

Most wavetable synths are 2D in format, so I must admit that thinking about how to arrange a 1D file for purposes of 3D interpolation, is a bit of a mind bender, and a howto would not be a bad thing.

1 Like

ha, the 4ms SWN screwed with my brain when i heard it described :slight_smile:

(i think a cube is much easer, but given it wraps around, i guess a sphere is a better description, in some ways)

I think the easiest way to think of the cube is as 2d grid with layers.

so the first 16 waves, form a 4x4 grid,
then next 16 , form the next layer (4x4)
etc for 4 layers.

this also allows you to see, why the morphing is different from a 8x8 to a 4x4x4

in an 8x8 grid
1 will morph to waves 2, and 9

but in a 4x4x4 grid,
1 will morph to 2, 5, 17 on the different axis. (in no axis 9 !)

the reason this is ‘important’ is some wavetables will be made such that morphing 1 to 9 ‘makes sense’

but as i said, the way to ‘fix’ this is to build an 8x8x8 cube (with 512 waves), this way the each ‘layer’ is a it’s ‘designed’ 8x8 grid.
(as a bonus you then get the morphing between layers, so playing with that ordering can be fun)

anyway, thats at least how my mind works with these kind of things :wink:

of course, thats the cool thing about the SSP, its a very flexible beast - but guess that means it takes a little more ‘figuring’ out.

2 Likes

It means that many things are arranged in unconventional ways, so you can’t as easily lean on prior knowledge. Fortunately, threads like this can fill in the blanks, but the forum is frequently very quiet. You’ve certainly reinvigorated the discussion, so thanks for that!

2 Likes

correct, but what setting do you use to scale or offset MIDI cc (0-127) to -5 -> +5 ?

with the remark that a single cycle can be very complex & long
take a look at 1 wavetable from my Waldorf Microwave XT:

as i said, multiple by 2 and use an offset of minus 1.

no, they are not longer, and they all form the same single cycle shape…
they have to be, otherwise they will be out of pitch or inharmonic.

as i said, there is little more complexity than splitting the wav file up into single cycle waveforms, and then ‘playing’ them back at a rate determined by the frequency.

the ‘table’ aspect of the a wavetable oscillator is this splitting, and then the way we morph (aka interpolate) between entries in that table (unlike a sampler, which can only move start point, so can only move to different entries in the wavetable.

Does this mean that each single cycle slice in my one dimensional wave file would conceptually have this series of X, Y, Z coordinates?

0,0,0; 1,0,0; 2,0,0; 3,0,0;
0,1,0; 1,1,0; 2,1,0; 3,1,0;
0,2,0; 1,2,0; 2,2,0; 3,2,0;
0,3,0; 1,3,0; 2,3,0; 3,3,0;
0,0,1; 1,0,1; 2,0,1; 3,0,1;
Etc
1 Like

In answer to my own question I just created a file that creates a 5x5x5 cube, sequenced as I described above, and then set NrWav to 125. Seems to be working as expected, no more mid-cycle “crease” that comes from misaligned NrWav.

I would have created a larger cube but NrWav tops out at 256. 512 would be useful.

2 Likes

Yeah , I noticed the 256 limit yesterday :frowning:

@bert could you increase this is 512, so we can have 8x8x8 cubes. This would be useful for combining existing 2d 8x8 wavertables ( as discussed above)

3 Likes