Proper tablet reading for wavetable synths

#1

Hi - so after thinking everything is pretty cool sounding, I started looking at the details of my instrument. Although happy accidents are great, I don't want to stay ignorant of how to properly do something.

What I am doing is playing back a table that has a sample loaded into it.

Here are my issues:

  1. I am using a Phasor to play it back since I want pitch variation. The phasor seems to be flipping the sample waveform - perhaps it should be a rising saw instead of a falling saw? Placing a math invert object before the phasor goes into the table read object doesn't produce any sound at all from the table.
    ** inverting after the table seems to work fine!

  2. The Memory allocation for the table doesn't make sense to me. If the sample is 1186 bytes - shouldn't I allocate more bytes than that to the table? I am thinking since my wav is a 16bit 48khz sample, I create a 16bit table. I figure the numbers in the drop down are bytes. So i give it 2048 bytes. I incorrectly (i guess) assumed that the table is now about half full and when I run a phaser through it, it will output all of the values and once it reaches and empty value it will start from the begining. Not sure where I got that assumption but it seems wrong. I can see on an oscilloscope that theres a big gap until the sample waveform starts up again. Interestingly, giving the table 1024 bytes, seems to fit the sample as well, and the gap is smaller. 512 bytes seems to almost correctly fill the table but theres some weird waveform mangling at the start of the sample.
    ***what I really dont get is if the sample is 1186 bytes, and i allocate memory for it as a 1024 table..why is there still a gap when i play it back with a phasor. Shouldn't it actually be without a silent gap since the whole table is already full since i tried to load a 1186 byte sized amount of data?

  3. The waveform mangling that happens at the beginning of the sample wave form while using a phasor - is this something to do with the phasor? Is it bandlimited or something?

#2

2.

I also had a few issues with sample length.... Did you try calculate from sample length and not from wavefile size? For example a wavefile 16 bit 44.1khz, 1 Bar at 180 BPM is 64000 samples long. I am not 100% sure about it, but I think this is correct way to calculate sample length.

Going to do a test with the scenario you present here later today...

#3

ahh. the drop down is number of samples?

#4

Can you post a picture of how you set up the tables for the patch? To make sure we are on same page smile

I think the drop down menu is buffer size, but it not not necessarily related too sample length.

#5

yeah i cant use the sdcard streaming object because it isn't pitchable - its just a trigger to play it.

wavetable.JPG786x478 53.2 KB

#6

the size is number of elements in the tables. e.g if its 16 bit, then is N 16 bits, if its 8b its N 8b

remember 16bits = 2 bytes (a byte is 8 bits) (32b would therefore be 4 bytes per element)

so 1024 16 bit elements = 2056 byes

the table is independent of samples... obviously if you drive pos at sample rate then you would be interpreting as samples, but this is your code making that decision, if you read at half speed then its not.

#7

thanks that is very clear now.

Any idea why this garbage data is being introduced in a single cycle of the table though?

bottom is the sample opened in Audacity and the top is a vst oscilloscope showing a strange bunch of spikes. Is that due to the table size not being exact enough?

#8

Ok it is a bit different than I thought. I havent played around with that table yet.

#9

the table is table/read interp

in the screen shot is my modification of it but its just a size adjustment knob (with a bad min/max amount setup that i've replaced). If you use the default table read interp object you should get the same problems with table sizing.

i guess the table size needs to be adjustable very finely. And then we can work out some way to pass the correct size amount upon sample selection.

#10

ok, I've only had a quick look at the code, and played with a table a few times, but heres what I think is the issue...

table alloc is a fixed size

table load, reads in as much as it can... ie. will truncate if too big, but if file is smaller, will leave what ever is in the table at the end alone. I guess this would usually be zeros, if thats what you do in table init.
(but table load does not 'reset' this... so if you load that table with different samples you will end up with whats left over from last time - perhaps it should zero it out?)

now the hard bit.. table/read (I don't like how this is done, but i can understand why) , position is a fraction of the table length size. i.e. 0.5 = 50% thru the table

the advantage of this 'scheme' is it doesn't matter what your table size is, the reading code will work the same. (it has disadvantages in the maths you need to use when you want to relate it to 'real time', but such is life)

anyway, the issue I think you have, is you don't know where the end of the real buffer its... so if you run 0 to 1, your going elements 0 to 1024, but your wave possibly is only 0 to 512... in this case you need to run 0 to 0.5

as you say, the issue is... you dont have access to number of bytes read.
what we should return (as its most useful) from load, is fraction of buffer filled.
this could then be used to ensure you don't overrun the amount of the buffer used.

really to figure this all out, id have to go sit down and play with it, as i said i don't really like the way pos works, because as soon as you don't fill the entire buffer, it gets a bit more complicated about how you drive it. (its easy to do by ear using dials, but not so easy to calculate it)
but perhaps this is just because I've not used it a huge amount smile

#11

Im playing around with the table alloc object now. Thankfully this conversation brought my attention to it. I think a lot of cool stuff can be done but at the moment it still has some "garbage" data in the sample table even with the size correctly set. Hopefully its still possible to squeeze that data out and it isnt something that is always added.

Also..i know i've been advized not to make the table size live adjustable but its totally stable smiley pretty fun stuff

#12

even with the table size too small the same pattern appears.
I cant understand where it is coming from. Perhaps the table read object, since im getting the same result from a saw lfo as with a phasor.

#13

i think even the 32b table alloc object with sliders has this artifact.

#14

Thinking out loud....Isn't there something about using wav of raw files can make a click sound at the start of the file? But I dont remember which one it is that makes the click.

#15

well im using the table/allocate 16b sliders object now and you can see a weird spike that appears when adjusting a single slider.

32btable2.JPG889x182 27.4 KB

i hope its something silly from my end. like exec order or something

#16

Can you zoom out a bit on the analyzer.... Just to see if the noiseclick has the same period between each spike?

Maybe add a restart button... And check it the click is first everytime you restart the cycle. Then you can atleast eliminate the start click theory I think it might be...

#17

yeah. this is from the table with sliders. its a click at the start of the table.

its not interpolated - just a table/read object of the following values.

#18

Yeah I see.... Besides the first one it seems pretty consistent.... ...Could still be when the the wavfile is restarted,,,,,,, Maybe try retriggering the sound and check if it the click comes first when you retrigger the waveplayer/table.

#19

i bet its because im not using a normal Phasor....

#20

Could be.... I am out of ideas for now.