Fathom Synth Development Thread

[RPH]

I will try that again, but i’ve already done that to the sequencer modulator.
From 8 segments changed it to 4 and some other things. That’s how I found out the bug, I needed to copy the modulator so not having to redo the settings.

[RPH]

OK. Tried it with my patch:
- added 4 segments.
- saved the patch.
- closed the window in Reaper.
- re-opened the window.
- edited modulator is empty / shows nothing.

[FathomSynth]

OK, thanks for checking that, I'll fix it.

[courtjestr]

Fathom will Import Serum Wave Tables

I've been looking into the Serum wave tables today and reading them is going to be close to trivial, so the Fathom Intel AVX release will also include being able to read any Serum Wave Table into Fathom.

This is awesome. It should be a real selling point to entice people to go pro.

Writing Fathom's wave tables to Serum format mechanically is also trivial in terms of the actual wave data. However writing the correct information into the WAV RIFF chunks so Serum will load it is tricky.

I checked out the thread
viewtopic.php?t=517146

However, what Steve is saying does not make any sense to me. I can not find any description of a CLM RIFF chunk anywhere online, so it looks like it might be Serum's own made up chunk. There is also a mysterious JUNK chunk. So anyway I will try to figure this out, but at the very least Fathom will be able to import Serum wave tables.

I wonder if the CLM chunk is related to an old sound synthesis package called CLM.
Check out http://www.moz.ac.at/sem/lehre/lib/cm/C ... /headers.c
There is a routine in there called write_riff_header which writes both a clm and a junk chunk. Not sure how much help this will be though.

[glokraw]

@ courtjestr: Thanks for taking the time with the wavetables!
Will happily download and try them soon

@ The Boss: I hope you can take a fun break after the avx release.
Very cool that you've saved preset data along the way for
a rythmic bank!
Cheers

[FathomSynth]

Thanks, the Serum wave table feature will be really cool.

For writing I think I may just be able to copy the same header without necessarily knowing the meaning of all the data inside it.
As long as the length field of the main data section is correct it should be OK.

Yes, I'll probably take a short break after AVX comes out.

[] Peter:H []

Fathom will Import Serum Wave Tables

I've been looking into the Serum wave tables today and reading them is going to be close to trivial, so the Fathom Intel AVX release will also include being able to read any Serum Wave Table into Fathom.

This is awesome. It should be a real selling point to entice people to go pro.

Writing Fathom's wave tables to Serum format mechanically is also trivial in terms of the actual wave data. However writing the correct information into the WAV RIFF chunks so Serum will load it is tricky.

I checked out the thread
viewtopic.php?t=517146

However, what Steve is saying does not make any sense to me. I can not find any description of a CLM RIFF chunk anywhere online, so it looks like it might be Serum's own made up chunk. There is also a mysterious JUNK chunk. So anyway I will try to figure this out, but at the very least Fathom will be able to import Serum wave tables.

I wonder if the CLM chunk is related to an old sound synthesis package called CLM.
Check out http://www.moz.ac.at/sem/lehre/lib/cm/C ... /headers.c
There is a routine in there called write_riff_header which writes both a clm and a junk chunk. Not sure how much help this will be though.

I don't get all the hazzle about serum. Icarus uses 2048 samples per slot wavetables (see attached file), thats about it, no more hazzle about chunks. It's just as simple as that. I opened it in a RIFF chunk view and there was just one chunk.

Other examples: http://synthtech.com/eurorack/E352/ has for instance 256 samples per slot...and comes with an editor http://synthtech.com/waveedit/. Audioterm supports other formats as well...Adventure Kids original single cycles are 640 samples IIRC.
That said: I would really apprecciate a more cannonical importer that does not rely on Serum specific chunks format, but rather has a "samples per slot" setting...which btw could be used in a creative way as well if you deliberately us a "wrong" setting

---

@Tone2: Hope you don't mind I've shared a simple example of Icarus wavetables in the attachment. Please drop me a PM if I should remove it.

[] Peter:H []

Did a little experiment to show how you can use wavetables and transform from one slot size to another.

first: When I talk about a slot, I mean a "number of samples" that the synth uses as the smallest playable single cycle. Intuition: Think about a sine wave. then a single cycle thru this sine wave could be used as the content of slot[1]. then think of a saw tooth wave. you can choose to use the samples of a single cycle and put it into slot[2]...and something ins slot[3]. A wavetable is: Take all the samples you have collected into your slots and put them in a single wavefile. A wavetable synth can now play each slot/single cycle individually or "scan" thru them driven by a modulator. anyway...

1.) I have started with waveedit 1.1. (http://synthtech.com/waveedit/). Loaded a saw2triangle wavetable from "waveedit online" which is an tab in the editor.
2.) I simply saved "the bank" into "Test.wav", see attachment. Inspected the file --> Single chunk
3.) Now I have a 64 slot WT based on 256 samples per slot.
4.) Went to Waveosaur the Wav-Editor to do a resampling to blow up the number of sample to fit it for Icarus: I deliberately used 44.100 * 4 as target sample rate. Who get's what the "mistake" here was?
5.) Now I have a wav that is 4 times in size, i.e. 1024 samples per slot...save it as "Test2.wav", see attachment.
6.) Went to Icarus and imported "Test2.wav" into a wavetable. Because I deliberately didn't respect the 2048-Format, I ended up with 2 cycles per WT slot...see screenshot. That's because Icarus works with 2048 samples per slot but I provided it with 1024 per slot...slot aka single cycle.
7.) If I have chosen 44.100 * 8 (i.e. make a 256 sample slot 8 times as big) I would've seen a single cycle in the Icarus view instead...Please do the experiment to correct my "mistake" on your own, files are attached.
8.) I could do the other way around as well, start with a Icarus Wavetable and down sample it to be a candidate for the E352 eurorack oscillator...

That's why I say - It's not important to focus on the specifics how Serum saves a WAV file, but the specifics of WT File formats and a clear understanding what a slot means, what samples per slot means and how most/many WT synths interpret wav files with respect to these parameters.

[jbraner]

I think what Peter says is right. I'm pretty sure Serum will load a WT without any chunk information - it will just assume defaults (2048 samples per WAV).
These defaults can be overridden in Serum by using a "FolderInfo.txt" file (to tell it what to do with the file)

[FathomSynth]

You're probably right about that, in which case saving the wave table in one big WAV will be easy and Serum will just load it regardless of the header. It's simple enough to try, so we'll just try it.

I have the wave table reader working now in my development version of Fathom.
I can load any of the Serum wave tables no problem.

There will be two modes, serial and extrapolate. In serial mode it will just load what ever waves it finds in order regardless of how many of waves there are. In extrapolate mode it will take all the Serum waves regardless of how many and extrapolate them smoothly to 16 waves for Fathom.

If I get time I may also make the number of Fathom waves per table settable by the user to a value anywhere between 2 and 1024. That way you can load an entire Serum wave table regardless of how many waves it has.

RPH, Yes, I am making the loader generic. You just set the number of samples per wave to what ever you want and it will load the table from any WAV file of one big wave regardless of whether or not it came from Serum. It does a check to make sure the number of zero crossings in the signal is equal to or greater than the number of waves times two. This way a huge wave that is meant to be a single cycle will be loaded as a single wave and a huge wave which is suppose to be a series of waves for a table will be loaded as a wave table.

[] Peter:H []

RPH, Yes, I am making the loader generic. You just set the number of samples per wave to what ever you want and it will load the table from any WAV file of one big wave regardless of whether or not it came from Serum. It does a check to make sure the number of zero crossings in the signal is equal to or greater than the number of waves times two. This way a huge wave that is meant to be a single cycle will be loaded as a single wave and a huge wave which is suppose to be a series of waves for a table will be loaded as a wave table.

Well thought out. But I would recommend to make the zero crossigs detector a selectable option to the importer.

I have constructed wavetable where I have simulated some kind of weird "unsiono" like stuff.
Slot[1]: Saw one complete cycle
Slot[2]: Same as Slot[1] but tuned +12 semitones, i.e. two cylces in one slot
Slot[3] Slot[4]: Saw tuned -12 semitones, i.e. half a cycle into a slot and bth slot form a single Saw cycle
and various slots with detunes in cents...

put these WT in two oscillators, pan one left one right and scan thru them in different ways, say WT one with a ramp up LFO and wt two with a ramp down LFO...that way you will get interesting results.

[courtjestr]

I don't get all the hazzle about serum. Icarus uses 2048 samples per slot wavetables (see attached file), thats about it, no more hazzle about chunks. It's just as simple as that. I opened it in a RIFF chunk view and there was just one chunk.

Actually, no. A WAV RIFF file has multiple chunks, even the Icarus wavetable you posted. At the very minimum, it has a fmt chunk which contains information about the audio format, number of channels, the sample rate, etc. and a data chunk which contains the audio data. The original confusion I think, was that Fathom thought that there were multiple data chunks, one for each waveform. Turns out that is not the case. The sound data is stored in one large chunk which is maybe what you are referring to.

Where a Serum wavetable differs from the Icurus wavetable, is that it has a clm chunk which contains information about the number of samples per waveform as well as how the wavetable should be interpolated. Steve (bitcrusher from xfer), stated that Serum currently assumes 2048 samples per waveform (aka the framesize), but that a future version of Serum could support other framesizes as well. You need to know the framesize if you want to know how many waveforms are in the original wavetable, and extract the waveforms correctly.

When it all comes down to it, you need to know how Serum stores it wavetable if you want your program to be able to load the Serum wavetable correctly into another program.

Also, I guess I should define my terms. When I say waveform, I mean a single cycle waveform, what you refer to as a slot, what Fathom calls a wave, and what bitcrusher calls to a frame.

[] Peter:H []

I don't get all the hazzle about serum. Icarus uses 2048 samples per slot wavetables (see attached file), thats about it, no more hazzle about chunks. It's just as simple as that. I opened it in a RIFF chunk view and there was just one chunk.

Actually, no. A WAV RIFF file has multiple chunks, even the Icarus wavetable you posted. At the very minimum, it has a fmt chunk which contains information about the audio format, number of channels, the sample rate, etc. and a data chunk which contains the audio data. The original confusion I think, was that Fathom thought that there were multiple data chunks, one for each waveform. Turns out that is not the case. The sound data is stored in one large chunk which is maybe what you are referring to.

Where a Serum wavetable differs from the Icurus wavetable, is that it has a clm chunk which contains information about the number of samples per waveform as well as how the wavetable should be interpolated. Steve (bitcrusher from xfer), stated that Serum currently assumes 2048 samples per waveform (aka the framesize), but that a future version of Serum could support other framesizes as well. You need to know the framesize if you want to know how many waveforms are in the original wavetable, and extract the waveforms correctly.

When it all comes down to it, you need to know how Serum stores it wavetable if you want your program to be able to load the Serum wavetable correctly into another program.

Also, I guess I should define my terms. When I say waveform, I mean a single cycle waveform, what you refer to as a slot, what Fathom calls a wave, and what bitcrusher calls to a frame.

Thanks. Actually I know that there's chunks in it. I used a RIFF-tool to read my examples. The big thing here is INFORMATION vs REPRESENTASTION. A RIFF chunked file is a representation of an arbitrary length media file.
An "Wavetable" is an interpretation of the representation, i.e. "use 2048 sample and interpret them as a single cycle, interpret all 2048 samples as single cycles and put them into consecutive slots".
Funny - Fathoms representation of the exact same information is a XML file. You can even add lot's more than 2048 samples into each slot...I have handcrafted a few.
The most canonical form of interpretation of WT is currently "2048 samples per slot".
The interpolation bit is implementation detail of Serum is thus hard to use if the algorithm is no specified as standard. And if there is 1024 in the future or something else...could be may be...

Therefore let's state it in other terms - if you have to balance scarce development capacity (Everetts), then a good strategy is to start with the basics and adds value for a most broad user base. Then in Sprint 1 I would put "Make Fathom WT longer then just 16 slots" and in Sprint 2 "Enable the importer to use 2048 sample" and in Sprint 3 "Add more options to the importer".
And I would not focus on Serum only. I use Icarus because it has some niffty importers which can make WTs of arbitrary wave files...like an robotizer. Therefore I don't care about Serum. Many WT Synths out there nowadays and there's even more to come from the Creator of Helm... https://vital.audio/

[courtjestr]

@Peter:H-I orignally started this reply by saying I am not sure I would agree with you. But upon reflection, and rereading what you wrote, I think it may be that we are just approaching the thing from different angles, or from a different starting point. Another factor may be language and terms used. I may be way off base here, and if I am wrong, please accept my sincere apology, but I sense that English is not your first language. I do not mean this as a slight in any way. I just want to make sure that I my understanding and yours match. Here is my understanding, starting from the wavetable perspective and going to its implementation.

The most basic definition of a wavetable is that it is a collection of single cycle waveforms. There is variance on how wavetables are represented. A wavetable could be stored as WAV file, or an XML file, or a folder containing multiple wav files, each holding a single cycle waveform as Sektor Synth does. One of the most common format of a wavetable is a wav file containing multiple waveforms with a framesize of 2048. Does that sound correct to you?

The reason I focused on Serum wavetables was that when you Google "free wavetables" the vast majority are Serum. The thing unique to a Serum wavetable is that the framerate is encoded in the wav file in the clm chunk. If you can extract that info from the Serum wavetable (which is trivial to do) you can load a Serum wavetable without any other information from the user, or any assumptions whatsoever. Importing Serum wavetables is like picking low hanging fruit; it is easy to do and there are thousands of them out there. That is why I was able to generate the Fathom wavetables from Serum wavetables with a few hours of research and a couple of hours of coding. But I agree with you, that there is no reason to focus on Serum wavetables only.

Serum can import non Serum wavetables where the framerate is not stored in the WAV file. Looking at the Serum manual, you need to create a file called either FolderInfo.txt, or file with the same name as the wavetable file but with a txt extension, which contains the framerate. If I understand correctly, if you use FolderInfo.txt then all the wavetables in the folder use the framerate info in the FolderInfo.txt file unless it is overridden with a txt file specific to the wavetable. You would need to do something similar in Fathom if you were to import wavetables whose framerate was not 2048.

[FathomSynth]

I should be able to figure it out from the existing header of Serums WAV files.

Reading the Serum WAV Wave Tables is now working perfectly, I just have to do the write side of it.