Fathom Synth Development Thread

[FathomSynth]

OK, I'll get to the bottom of it and fix it.

[RPH]

I'll try to help out as well on my end by doing some more tests.


Btw, I think you missed my bug report on the audiocomponent copy function.
If needed can make a video to show what's happening.

viewtopic.php?f=1&t=482501&start=1485#p7016881

[Frostline]

I think I found the issue.
Started rebuilding the patch using the basic saw instead of analog saw.
No ADSR on volume at this point.
Playing the same midi item as before on E3.
Set all detune values the same as bad patch. Plays fine.
Set noise setting the same(though noise was off anyway). Plays fine.
Got to distortion. Started copying channel 1.
Played seemingly fine, up until overdrive.
As soon as I put the overdrive to 9.77 it starts the bad behavior of overholding the notes and blocking the next notes from playing.
But, the very odd thing is turning the overdrive off does not completely stop the bad behavior.
So I start working back to the left setting knobs back to zero.
Once the distortion knob was set back to zero the bad behavior stopped completely.
So think it is something with the interaction of the distortion and overdrive parameters in that module that causes the note issue.
In the below image the top waveform is with distortion @ 10 and overdrive @ 9.77 while the bottom waveform is distortion @ 0 and overdrive @ 0.
Notice how in the bottom waveform the notes have almost no decay tail, they look very flat which is to be expected without an ADSR.
But the top waveform they starting getting tails and occasionally prevent the next note from starting at the correct position.



It could be that the addition of channel 2 distortion and the AM settings (which I had not gotten to yet for this test) increase the occurrence of the bad behavior but it seems to originate in the distortion module.

[FathomSynth]

RPH, Yes I had missed that one, but I recorded it now.
I will try to get that fix into 2.8 with the rest of the fixes.

Frostline, brilliant work isolating the problem, this will make it a lot easier for me.

Here is the current bug list.

BUG 0086 Copy components disapear
BUG 0085 Pitch note ADSR dropping at end of note
BUG 0084 Volume increasing gradually
BUG 0083 Missing notes if low notes are close together
BUG 0082 Mac OSX Sierra aliasing on high notes if waveform modulated

Most of these I already know how to fix. I will be fixing them this week.
Then I should be able to get 2.8 out Monday with all the fixes.
2.8 will just be a bug fix release.

If anyone else finds anything in the near future, please do your best to report it this week,
so I can get all the fixes into one release and make sure 2.8 is perfect.

[Scrubbing Monkeys]

First congrats on Fathom being chosen for the 109 One Synth Challenge.

viewtopic.php?p=7022602

I am on Reaper 64 on win 7 64 no issues. I have used one instance quite thoroughly. Have not used many instances.

I also use Mulab 64 on win 64. I have used one instance on Mulab as well, no issues. I do not have as much time on Mulab as I do Reaper.
I have noticed I cant drag single cycle waves from Mulab browser to Fathom. Could be a Mulab issue. It will drag n drop from the MS Windows browser while Fathom is in Mulab.

[Frostline]

So I don't know if this is a bug or just how things work.
And if it is a bug I don't know if it is a Fathom bug or a Reaper bug.
So I will try to describe the behavior and maybe I can be given advice to remedy it or work around it.
Current project with 14 instances of Fathom mono.
RAM usage varies in the 4-5GB range. Last night it was like 5.6GB and today it is like 4.6GB. Why that varies I don't know.
I have never had a project using other VSTi that went over 1GB, that I have noticed anyway. So I don't know what happens once RAM is used up and that worries me.
So I tried freezing all the instances of Fathom hoping that would affect RAM like it does CPU to some extent.
RAM usage went from the 4.6GB to around 2.8GB, which was better but not what I was expecting.
So I saved the frozen version and relaunched Reaper.
Opening the frozen project and RAM usage was only 195MB, which is more in line with what I expected the freezing to do.
So why does it not release all the RAM Fathom is using by just freezing the tracks?
Is there a way to force the release of RAM without relaunching Reaper?
Thanks.

[Yeager]

I have the same thing with FLStudio , when I close the project , I suspect Fathom is still in the RAM, and opening the GUIs will add to the RAM used. When I first load a project it will be about 2 GB used and every GUI I open will add 250MB to the RAM. Starting a new project will leave 2GB in the RAM.

W7 64bit FlStudio 32 bit Fathom Mono 32bit.

So I don't know if this is a bug or just how things work.
And if it is a bug I don't know if it is a Fathom bug or a Reaper bug.
So I will try to describe the behavior and maybe I can be given advice to remedy it or work around it.
Current project with 14 instances of Fathom mono.
RAM usage varies in the 4-5GB range. Last night it was like 5.6GB and today it is like 4.6GB. Why that varies I don't know.
I have never had a project using other VSTi that went over 1GB, that I have noticed anyway. So I don't know what happens once RAM is used up and that worries me.
So I tried freezing all the instances of Fathom hoping that would affect RAM like it does CPU to some extent.
RAM usage went from the 4.6GB to around 2.8GB, which was better but not what I was expecting.
So I saved the frozen version and relaunched Reaper.
Opening the frozen project and RAM usage was only 195MB, which is more in line with what I expected the freezing to do.
So why does it not release all the RAM Fathom is using by just freezing the tracks?
Is there a way to force the release of RAM without relaunching Reaper?
Thanks.

[provoc]

If anyone else finds anything in the near future, please do your best to report it this week, so I can get all the fixes into one release and make sure 2.8 is perfect.

Can you please check loading of the detune settings after they are saved with “save defaults” since it saves them in FathomVoiceMap.xml in the vst folder but never seems to load them again as far as I can tell (I assume this should be automatic since I cannot see a load option anywhere)? Tested on both Reaper x64 and Cubase AI 9 on windows 10.

Thanks,

provoc

[FathomSynth]

Frostline, Yeager, Here’s how the RAM works.

Fathom uses a massive amount of memory, first because it pre-calculates waveform buffers for each partial value, and second because it uses such a large number of samples per waveform.

The primary waveform buffers are 16384 samples, x 5 for the bicubic spline coefficients, x 4 bytes per float. In addition partial modulation buffers are pre-calculated for approximately 100 of the 400 partials. These buffers are 4096 samples but are also x 5 for the bicubic spline coefficients. The memory is even more for the wave table oscillator since all this must be multiplied by 32 wave positions.

So for one wave table oscillator the memory is approximately.

= (32 * 16384 * 5 * 4) + (32 * 4096 * 100 * 5 * 4) =

10,485,760 + 262,144,000 = 272,629,760 = 270 MB per oscillator.

The basic waveforms and analog saw are not as bad because all the tables are the same and can be shared by oscillators, but for wave draw and wave table each oscillator needs its own tables.

This is a massive amount of memory for the sake of almost zero aliasing and high speed playback which only needs to fetch from tables rather than playing each individual partial.

The bicubic spline is used for smooth non-linear table interpolation, which further reduces aliasing. The spline coefficients are pre-calculated for each table sample rather than being calculated at run-time. So there are an additional 4 coefficients per table sample which multiplies the size of all tables by 5.

I think the GUI adds about 250 MB of RAM. Once the GUI is loaded it keeps it in memory after it is closed so it does not have to be loaded again from scratch. But if you load a project and never load the GUI for a track, then the GUI memory is not loaded.

In a future release, I plan on adding a settings page where you will be able to set the number of samples per buffer, and enable or disable bicubic spline table interpolation, and also set whether or not you want the GUI kept in memory.

For the freezing, Fathom currently has no way of knowing you froze the track. So once you load the GUI and make edits to the oscillators all the waveform buffers previously mentioned probably stay in RAM even after a host track freeze.

However, if you freeze a track and then reload the project, I think the host is smart enough not to tell the plugin to load its memory block. So if you had a bunch of Fathom tracks and froze them all, saved and loaded the project, then the Fathom memory should be zero, if the host freezing works as I would hope.

I’m not aware of any VST function which the host can call to tell the plugin that it has been frozen and to release all its memory. However I could add a setting by which you could manually tell Fathom to release all its memory.

Provoc, for saving the default tuning. When I hit save default it creates FathomVoiceMap.xml in the same location so Fathom.dll. Then if I add a new oscillator it uses the new default detune parameters. So it seems to be working as intended.

However, if you are using the Mac, and it is in the system audio library folder, it might not have write permissions to the folder which might prevent it from saving.

You can get around this by temporarily placing Fathom.dll in a writable location, validating that plugin, then hitting save default, then manually moving FathomVoiceMap.xml to the location you want.

[tonedef71]

Fathom uses a massive amount of memory, first because it pre-calculates waveform buffers for each partial value, and second because it uses such a large number of samples per waveform.

270 MB per oscillator.

This is a massive amount of memory for the sake of almost zero aliasing and high speed playback which only needs to fetch from tables rather than playing each individual partial.

Could writing the pre-calculated buffers to temporary disk storage, and then streaming pages of them into memory on demand as needed be a possible alternative to storing it all upfront in RAM? Something similar to the HDD/DFD streaming capability supported by popular samplers like Kontakt. https://www.adsrsounds.com/kontakt-tuto ... ntakt-dfd/

[Frostline]

I think this is also a bug.
At least I don't think the chorus filter is supposed only work part time.
I show all the settings at the start, but its just a basic waveform pulse with slight tweaking and a simple ADSR on volume and 3 channel detune with the detune chorus off.
And I don't know why it is clicking so badly, probably too hot into OBS. Doesn't seem as noticeable until I turn the partials down.

[provoc]

Provoc, for saving the default tuning. When I hit save default it creates FathomVoiceMap.xml in the same location so Fathom.dll. Then if I add a new oscillator it uses the new default detune parameters. So it seems to be working as intended.

However, if you are using the Mac, and it is in the system audio library folder, it might not have write permissions to the folder which might prevent it from saving.

You can get around this by temporarily placing Fathom.dll in a writable location, validating that plugin, then hitting save default, then manually moving FathomVoiceMap.xml to the location you want.

Thanks for checking. In my case it is not a write permission issue since the FathomVoiceMap.xml DOES get created in the Fathom.dll folder and if I open it in a text editor I can see the values are correct (I didn’t change them all but changed a few in a couple of different voice settings 2, 3 voices etc. to test.)

However if I close and reload fathom I just get the default values not the saved ones. On the other hand if I save defaults, delete the oscillator without closing fathom and then create a new osc I do get the modified values but possibly because the values are still in memory?

It is a feature I would like to use to set up some settings for different numbers of voices and be able to recall them (could even swap in and out different .xml files if I had variations).

Do you think it could it be a DAW specific thing? Are there any other Reaper/Cubase users here that can confirm that it works and it isn’t just me?!

Thanks,

provoc

[Frostline]

The basic waveforms and analog saw are not as bad because all the tables are the same and can be shared by oscillators, but for wave draw and wave table each oscillator needs its own tables.

In practice this seems opposite of results.
Running 1 mono version and 1 poly version together and just using wavetable osc on both RAM is 800MB
Run a new project with just 1 analog saw osc and RAM usage is 1GB.

On a somewhat related note, the chorus filter works as it should on wavetable osc, but as in the video it does not like the pulse in the basic osc. Could be related to the aliasing issue with pulse maybe?

[FathomSynth]

provoc,

When you hit the save default button it takes all the current detune values for that oscillator, and saves them as the new default.

However, the new default values are used only when you create a new oscillator. It has no effect on any oscillators which were already created.

I think you are expecting the saving of new default values to change what is already there, but that is not how it works, it is only used when a new oscillator is created.

Thus the name "default".

Keep in mind also that there are 8 completely separate set of detune parameter profiles for each oscillator, one for each number of detune voices.

When you change the number of detune voices you are loading the profile associated with that number of detune voices.

This gives you the ability to create the perfect settings for 3 detune voices, and do the same for 4 detune voices, and keep both without them interfering with each other or losing any values when you change the number of voices.

If you want the ability to load a set of detune parameters into an existing oscillator like you would load a preset, that feature does not yet exist.

Frostline,

It may be that a single Analog Saw oscillator uses more memory than one or two Wave Table oscillators, since the Analog Saw uses a three dimensional table of buffers, and the Wave Table oscillator is two dimensional.

But multiple Analog Saw oscillators in the same instance all share the same tables, where as each Wave Table oscillator has its own set of tables.

Like I said, in the future I will make the size of the tables a setting controlled by the user, but this feature has not been done yet. Right now there is nothing you can do about the memory.

[provoc]

provoc,
I think you are expecting the saving of new default values to change what is already there, but that is not how it works, it is only used when a new oscillator is created.

Thus the name "default".

Keep in mind also that there are 8 completely separate set of detune parameter profiles for each oscillator, one for each number of detune voices.

When you change the number of detune voices you are loading the profile associated with that number of detune voices.

This gives you the ability to create the perfect settings for 3 detune voices, and do the same for 4 detune voices, and keep both without them interfering with each other or losing any values when you change the number of voices.

If you want the ability to load a set of detune parameters into an existing oscillator like you would load a preset, that feature does not yet exist.

Hi Everett,

I am pretty sure my understanding of the expected behaviour is exactly as you describe above and also understand there are different detune settings depending upon number of voices (as is evident from the structure of the FathomVoiceMap.xml).

Therefore, I have recorded a SCREEN CAPTURE video to show what is happening:

http://www.users.on.net/~provoc/fathom.mp4

Steps are as follows
1. Start with no FathomVoiceMap.xml
2. Load fathom instance and add osc
3. Set settings for voice 1 and 2 of the 2 voice detune setting
4. Save default and see that FathomVoiceMap.xml is created (the data inside is correct although I didn’t show for brevity)
4. Delete osc
5. Add new osc to same instance and default settings come up as expected
6. Delete fathom instance and then load new one
7. Add osc but saved settings not loaded for the 2 voice detune config

Anyway hopefully this will help get to the bottom of this even if it means identifying that I am missing something somewhere

Cheers,

provoc