Proper tablet reading for wavetable synths

#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/

#41

Yeah I thought of stretching too, but stretching it in regular manner would probably not be good idea because of artifacts. What is special about the Nyquist stretching? Just checked the Audacity Nyquist plug in. couldnt make much from it :smile:

Which other ways can you recommend for stretching files? Are there any of them that lets you stretch in bytes instead of samples?

And also checked the editor and it is PC only. I am on Mac. I suggested Serum cause you can use it on both pc and Mac.

#42

the topic of loading 44.1 files has already been answered :smile:

#43

Ok, that answered one of the questions :smile: thanks. Will look into other options.

#44

yeah sorry it isnt the commonly known "stretching" its the more basic "repitching" approach..so it doesnt do pitch correction with those horrible artifacts.

#45

So how should I approach it:

If I have a sample that is 482 byte and want to make it 512 byte:
512 - 482 = 30
(30/482) * 100 = 6.22%

How do I apply 6.22 stretch in a manner that doesnt produce artifacts? I cant figure out how to do it with the Audacity Nyquist plug in. It need command lines and I am not sure how to do that.

To be honest I am not sure stretching the files are the best solution, anyway.

#46

Why sample-rate-convert the wavetables?
The transposition error resulting from that can be compensated during playback.
It is more important to preserve the power-of-two length (1024, 2048 etc). So I suggest not to sample-rate-convert, only make it raw.
I do not expect any realistic increased quality resulting from a 32bit resolution wavetable over a 16bit wavetable. Interpolation algorithms are far more important to the sound quality.

#47

The wavetables from Serum is 31 bit float 44.1khz. I thought that Axoloti only used 16/32 bit depending on what you choose and 48khz sample rate?
.
Therefor I thought it was necessary to sample rate convert. If you say there is no need for it, Ill take your word and test it out. Then in theory it is pretty easy to use since a 128 wavetable from serum fits perfectly in a table/alloc 16b with 512 buffer size.

#48

Certainly convert from 32bit float to 16bit or 32bit fixed point. 32bit fixed point will hardly give any noticeable improvement for wavetables.

The size attribute in Axoloti is number of samples regardless of sample size, so select 128 for a 128 point wavetable.

#49

Ups sorry I said something wrong here... All those numbers i just went through....
32bit float and 44.1khz calculations:
128 tables that is 8 bytes is 1024 bytes.
64 tables of 8 byte is 512.

Anyway going to test now. I just made now.

#50

the solution is the quickest for me right now - of course having a nice converter that is intelligent enough to pitch stretch to the closest power of 2 would be neato but whatever.

you need to use this plugin http://forum.audacityteam.org/viewtopic.php?f=42&t=64003 - the second attached file in the thread.

it uses time but you can specific very exact lengths so you can get the right amount of samples.

#51

Ahh an explanation about the plug in. Thanks :smile: But I will still prefer not to stretch anything if possible..... And i think it is possible without stretching..

#52

well its re pitching so i think its good. might be wrong though, but i didn't hear artifacts and code seems super simple (you can open the file).

the EASIEST thing to do would be making your own tables at the correct lengths.

#53

Yes exactly what I am trying to do. And if we can make Serum wavetables fit in Axoloti we dont even have to make them ourselves, because there are thousands already now. I think it is too much of a hassle having to repitch every single wavetable file you want to load in axoloti. WOuld be must simpler if we can just drag them in and set buffer size.

#54

pretty sure batch processing works with this plugin but i havent tried it yet. I want to use old ripped wavetables from some classic machines and no way in hell im doing them by hand hehe

#55

Ok still learning here. I though the table alloc object sets the size in bytes not samples? That is why I pay attention to the tablesize in bytes not in samples.

And a Serum wavetable is 512 bytes, not samples. And therefor I have set table alloc for 512.

Would really like to read a proper explanation of how table alloc works in general. It seems like i get things mixed up.

#56

All the classics are already made for Serum. Again it would be much better to put a little effort into solving this issue that having to repitch all of them... I dont trust the repitch idea....

Since the sizes of Serum wavetable and Axoloti table alloc are compatible it is much better to find out how to make this work perfectly. Then you just download whatever wavetable you need and use it... Much better in my opinion.