Proper tablet reading for wavetable synths

#21

well normal phasor makes the click go away in a slider table object. but its still there with wav playback.

#22

Did you try changing the format? From wav to raw or vice versa?

#23

raw format works. ffs. thanks.
the header is what was causing that garbage in the playback when using a wav.

#24

Nice it is Working 👍 😄 I had The Feeling it was format problem.

#25

yeah thank you guys for reading the spam! I think i might be able to make very clean wavetable synths now!

I am using the phasor compl object and it is pitching everything correctly.

I am also going to see if adjusting the table alloc object with custom element numbers can perfectly fit wavs..but im not sure it is necessary now..or the difference is so small that i am not noticing it yet.

#26

NP wink

Sometimes a little incorrectness adds some character. So if you like the sound that sums it up for me smile

#27

am i understanding correctly that if my sample is (in windows and in axo file manager) a raw file at 1114 bytes - i will need 557 16bit elements for the table? seems like its off by a bit when i drive the table with a phasor - like the table is too small. Probably making a different object that plays only the filled table space is best practice but, I am wondering if theres a more exact way to do it with existing objects.

#28

I don't think so... its a week since i looked at the code, but from memory, when the files read it is not reported anywhere how much of the table was filled. similarly the table knows its length, but not how much is filled.
really what we need to do is have the load or perhaps read object on table, know much of the length is really in use.
(i.e. it may be 512 elements long, but we only have 256 elements filled).
then i think perhaps the pos should be using the 'actual length' rather than the possible length.
this would mean the user would not need to know/care about it....

(I think it would be handy also for the load object to also report some info... in particular so you can know if the file was too large to be fully loaded, so was truncated ... useful when your initially trying the patch out, so you know if to use a bigger table or not)

#29

yeah best to do it properly..otherwise you'll have to make like custom table objects with custom lengths for all of your hundreds of samples or whatever..
thanks. will chill a bit and approach it with a fresh brain sometime

#30

@alexk

Which raw format did you export to? I am using Audacity and there are like 20 different raw formats to choose from?

Can I just change the filename instead? like melo4n.wav to melo4n.raw in finder window and let OSX select the fileattributes? or do I have to do it in an audio editor?

I am working on my first table patch, but I am not really getting any sound out of it. When I use .wav I only get the header click. When I use .raw I get no sound. I might be using the wrong raw format?

Any help appreciated :smile:

Table test 2.axp (3.3 KB)

table ppatch1.png765x400 46.2 KB

#31

i also use audacity - you must first resample the sound you are preparing to 48000 ( in top menu: tracks - >resample). Then export it as "other uncompressed files" and go to options. then select RAW (headerless) ,signed 16 bit pcm and save it as a .raw file and dont use more than 8 characters in the name.

and yeah better use audacity! i dont know if osx is clever enough to do such stuff haha.

#32

All files are 16 bit 48khz, less than 8 char. and they all work as wav files, so I just needed to get the raw format right.

Now I saved the file as you suggested, but I still get no sound.... It must be something not setup right in the patch, because when I use wav I still only get header and when using raw still no sound at all....

EDIT:
A little bit of extra info: The file I use is 2.5 megabyte and I have set the table alloc to 4096.

#33

Please set the table alloc to 2097152, that will still truncate your file a bit, but at least you will recognize it :smile:

#34

@jaffasplaffa ! don't forget :

#35

Yeah thank you for your help.

Increasing the table alloc to 2097152 helped. Now it doesnt only play a short bit but the whole file. Now I can use it as when using the waveplayer. Awesome :smile: And now with pitch modulation :smile:

When using the string/c object to load files into a table I noticed:
- Stereofiles needs table/alloc 32b sdram to play normal speed (sounds gets really loud for some reason..thats nice :smile: ).

  • Monofiles need table/alloc 16b sdram to play at normal speed.
#36

Loading stereo files into a table is currently not supported. You'd need to convert them into separate mono files, and allocate two tables.
That it plays at normal speed when allocating a 32bit table is a side effect. But it consumed the double amount of memory for no reason that way.

#37

Super. Then I need to make a dual setup with the two mono files loaded into each of its own table/load and table/play. And use table/alloc 16b sdram. Thanks :smile:

#38

ok i took a different approach - simply preparing proper length samples. I think its a lot easier! Simply have to use Audacity to show # of Samples in the selection window, then you can measure by what amount of speed you need to adjust the sample length to fit into nice powers of 2. Aaand probably theres a nice way to script that or something.
When creating your own samples (for example wavetables) it would be even easier (but i'm converting old ass sq80 and ppg rom rips).

#39

Yeah I think filesize matters a lot. I think using Serum as an example for creating wavetables is a good idea. Cause in Serum you can load&save wavetables very easily and export in .wav format. And there is al ready thousands and thousand of them available. So if we can calculate how to translate Serum wavetable sample size to bytes, we will have an endless resource of wavetables :smile:

Info on wavetable size in Serum:

Serum can use up to 2048 samples for a wavetable and maximum number of waves/tables is 256. You can set amount of waves you want to use. In this example I use 128 waves/tables cause that is what most synth use.

Serum uses 32 bit 44.1 wavefiles for wavetables. Each wave/table is 8 bytes long, actually 8.328 bytes. I then converted one cycle to 32 bit 48khz: 4 bytes, actually 3.808 bytes. I Guess we need to do the rounding for 4 bytes for the calculations to make sense in relation to what values are possible to set in Axoloti. Soooo:

128 waves/tables of 4 bytes(This example is made from making one wavecycle of the 128 and exporting the single wave from Serum:
128*4= 512 bytes

So a 128 wavetable made in serum and converted to 32 bit 48khz is in theory 512 bytes. Perfect it seems.........

Then I made another test:
This one I made a whole table with 128 waves, exported in one file and converted as same method as above. And now the file is 482(481.690) bytes. I guess that is the roundings that messes up the bytesize. Calcualting it manually makes it fit perfectly 512 bytes. Anyway, how do we make a 482(481.690) byte file fit perfectly in a 512 table alloc object?

I think that using Serum wavetable format would be a good "standard" for using wavetables in Axoloti. Serum wavetables are VERY good quality. I compared to Blofeld which I also made custom wavetables for. Those editors for blofeld are not so good and wave quality is neither. Serum editor is very nice and good quality.

And if we do this, you dont have to convert any wavetables yourself. Like I mention there is thousands and thousands of wavetables for Serum by now and I am pretty sure all the old waldorf tables are already converted to Serum. We only need to make the calculations.

And now I think that it would be REALLY awesome with a table/Alloc object that uses samples instead of bytes. To me that makes a lot more sense when using wavetables which have to be really precise. Then we could avoid the roundings of bytes, even though that is probably what most manufactures do anyway. But sample length table would also be nice in other scenarios like for examle loading drum loops, etc.

@johannes

What do you think about a dedicated table/Alloc sample object to avoid roundings? Is this possible to do such an object and would it make sense? Could be called "table/alloc 16bit sample size". And then you could set the sample size manually according to the sample you use.

Or what about making an object that loads 32 bit 44.1 khz files? Then Axoloti would be 100% compatible with Serums wavetables and that would give users a HUGE librabry that is already there. Anyway, just thinking loud here :smile:

Going to do some more tests on the Serum wavetable sizes today. Would be nice to figure out how do export the Serum wavetables so they fit perfectly into a table alloc 16b with a buffer size of 512.

EDIT:
Extra info on Serum tablesize in bytes:
a 128 wavetable at 32 bit 44.1khz (Serums own format) is
128*8: 1048 bytes (actually 1.048712 bytes).

Converted to 16 bit 48khz raw headerless in Audacity:
482 bytes(481.690)

Converted to 32 bit 48khzkhz raw headerless in Audacity:
482 bytes(481.690)

428 bytes divided by 128(number of waves in table+numbers of a step on a knob to selct the tables) is:
3.765625, rounded to 4. If calculated like this you wont play the tables from their startpoint cause we cannot set a value as 3.765625 in Axoloti, which we need to be able to index the 428 bytes perfectly in 128 steps... But I am not sure how the roundings will affect it. Havent tested it yet. And I am not sure how this works in audio world or it really is an issue...

@thetechnobear any ideas?

Link for Serum manual. Page 11 has some info on table size etc.:
https://vk.com/doc-78391075_345519226?dl=059338af63ff84a2f0

A bunch of Waldorf Microwave wavetables in Serum format:
https://www.clustersound.com/product-detail.php?id=105

Video of Serums Wavetable editor. NICE :smile:

#40

im using a stretch nyquist plugin to change audio file lengths to the right amounts of 48k 16bit samples.
works for me but there are tons of ways of doing it of course since it is primal DCO tech.

btw someone made a nice little app to make serum tables (for walking the samples too) https://sites.google.com/site/glowshrimpsoftware/