Fathom Synth Development Thread

[FathomSynth]

Frostline, Very in depth testing. This much detail makes it a lot easier to debug problems,
so thanks for collecting the data.

Edit: Sorry this reply is long, but RT is a complex issue.

First, in general, Fathom still needs huge improvements for real time processing.
The biggest factor is that it is not yet using Vector SIMD instructions for parallel processing.
If your other synths have this feature, then it explains why Fathom is requiring four times
as much CPU cycles. This is high on the list of improvements but has not been done yet.

The reason the CPU goes way up with the GUI open is real time graph animation, and also showing the real time spectrum requires running the Fast Fourier Transform in real time during audio processing which eats up some CPU. On the front panel try turning the Panel Mode dial to "No Overlay" and see if that has an effect on your performance graph.

CPU will also spike when you drag any dial that requires any buffer pre-calculation such as oscillator partials.

One small question, explain the difference in your tests between "RT CPU" and "overall CPU" just so I know and can also test.

I just noticed you are using Reaper. I have Reaper and I love it, However, the VST interface with Reaper is extremely problematic, and I've had constant reported problems with Fathom running on Reaper.

The problem is that Reaper does not use essentially constant sample block sizes like most hosts, and furthermore, it jumps around drastically in block size, including very small blocks. In my testing I even found Reaper sending me blocks of 1 sample.

This makes it impossible to manage operations that must be done once every block versus per sample operations in the VST. You can imagine the effect on real time performance if all the VST operations that need to be done once every 512 samples are being done every sample. That will kill the CPU performance.

This is a design flaw in Fathom NOT in Reaper since the VST spec allows for small blocks.

The problem is I have not yet come up with a solution to handle Reaper.

If Reaper has a "use constant block size" setting like FL Studio has, try that!

[Scrubbing Monkeys]

http://bedroomproducersblog.com/2017/08 ... nthesizer/

Pointed them to your plugin, today a review appeared

Awesome. I really like their reviews compared to others that simply repeat website info. He actually uses the stuff.

[Frostline]

The reason the CPU goes way up with the GUI open is real time graph animation, and
also showing the real time spectrum requires running the Fast Fourier Transform in real time
during audio processing which eats up some CPU. On the front panel try turning the Panel Mode dial to "No Overlay" and see if that has an effect on your performance graph.

While I'm sure it might help a smidgen, I have not noticed any real difference in the CPU graphs with GUI open or closed. Maybe a couple of %.
I have actually been very impressed with how nice the display is vs the performance impact of having the GUI open. Maybe the video card I'm using helps with that? I have no idea. I just mentioned that it might add a bit of CPU overhead, but it was not significant to me.
I had previously done the tests with the GUIs all closed, but the results were almost the same. I only opened the GUI for the test to easily have the patch shown with the graph in the same screenshot.

One small question, explain the difference in your tests between "RT CPU" and "overall CPU"
just so I know and can also test.

When I first started noticing problems with audio glitching/cutting out it was happening with two instances of Fathom playing together and I was building a chord progression. At the 6th or 7th sustaining note the audio would crackle/glitch but on the CPU meter in Reaper I was only seeing 27-30%.
In Windows 10 resource monitor it was showing all the activity going to one core (of the 4 my pc has). Once that core hit 100% it looked like Windows(or Reaper, I have no idea what processes was doing it) would try to dump everything from the maxed out core to another one in a big chunk and as this occurred the audio would go bad.
So some googling lead me to this RT value and how to enable it in the graph.
It seemed to follow the same path as whichever core was getting beat up on. The RT value was within a few % of the hammered core up to 100%. But the default Reaper CPU graph was still 25-30% which matched fairly close to the value Windows gave for overall CPU.
I then found out things to check in Reaper to allow all cores.
This helped tremendously. I could play more notes with two instances.
But the second instance was stealing notes after 7. (it is a much more complicated patch, I don't know why it only does 7 notes when set to full 16 but that is an issue for another day).
So I decided to concentrate on the simpler patch I posted previously of just two OSCs and two filters and little modulation and seeing if it could actually do 16 notes at once.
And in Windows monitor it seems the load is more spread out, no single core is getting hammered, but the RT graph still climbs like it did previously and >100% there starts glitches. At 120% it is mostly glitch.
So I really don't know what RT CPU value is vs CPU value. It did match fairly close to the used individual core, but with the setting change it does not match now but the RT CPU still indicates when some limit is about to be breached and audio issues are going to happen when using Fathom. And as indicated in the previous screenshot the other synths don't move the RT CPU at all. So I don't know what it means, other than when near 100% it is a bad thing to be having.

If Reaper has a "use constant block size" setting like FL Studio has, try that!

I can't seem to find a clear answer to this. Most of my googling seems to indicate the only block size setting has to do with the ASIO driver and trying to request a buffer size different than the ASIO has set already.
I tried multiple sizes for this buffer number(because at first I thought this whole issue was soundcard related since CPU use seemed too low to cause this and I was not aware of RT CPU being a thing nor had I started watching Windows resource monitors) and none really had an effect on the CPU values or the glitches when Fathom played. At higher buffers the pops/glitches were still happening at the same number of notes, just the frequency of the repeating of the glitches changed slightly.

[FathomSynth]

Frostline, Thanks for your hard work on this.

I will make this a priority this week before release 1.0.13 and see if I can get it fixed for Reaper.

Do you have any other DAW's, if so please try them with the same preset and see what happens.

Also, sorry If I overlooked it, but are you on 32 or 64 bit? And how much RAM do you have?

[FathomSynth]

Folks, I just released version 1.0.12.

This is a major bug fix release.

This is an important release if you are mixing down your songs and they include Fathom tracks. This release fixes the DC offset error so that Fathom's output is perfectly balanced above and below the zero amplitude line for absolutely zero DC drift.

[Frostline]

Frostline, Thanks for your hard work on this.

You are quite welcome. This is one of my favorite synths. It really inspires me to explore what it is capable of doing.

Do you have any other DAW's, if so please try them with the same preset and see what happens.

I tried it with the patch I made in MuLab 7.something. Performance was much much worse. Though admittedly MuLab has not been optimized for my system, so better performance in MuLab could very well be possible with tweaks that I have no idea how to do.

Also, sorry If I overlooked it, but are you on 32 or 64 bit? And how much RAM do you have?

I am using Reaper 5.4 x64 on Windows 10 x64 w/8Gb RAM.

To muddy things further with my experimentation, I started a new project, added an instance of Fathom, and then duplicated it so I had two tracks of Fathom.
On each I selected the factory preset "Jazz Organ Lite".
On each track I placed the 16 note midi from previous tests, which is adding a new additional note every 1/2 bar.
Soloing the first instance, I got no RT CPU gain, but would start to loose notes as it progressed past the 7th note and by the end only 4 notes were playing. The effect was obvious in SPAN as the lower frequencies dropped out. And this corresponded to the note display in Fathom itself.
Soloing the 2nd instance, I got immediate RT CPU gain, but lost no notes until the 15th (which was when RT CPU broke 90% and popped/crackled a bit) and by the end it looked and sounded like 14 notes were still playing cleanly.
Same patch, same midi, different performance and end result.
Going to try the updated version, and looking forward to 1.0.13

[yellowmix]

So I really don't know what RT CPU value is vs CPU value.

RT CPU in Reaper is Realtime CPU; that is, how close it is to taking up available CPU time to render audio in realtime. If its goes over 100%, it's not in time, and audio will break up. CPU is how much of the CPU is being utilized, like you would see in Task Manager or whatever.

[RPH]

RPH, Dude, I owe you many beers.

I just read the review and its amazing, what a great review!

WE owe you a LOT more!

On Facebook the reviewer was really surprised the plugin went unnoticed for so long.
Hope this leads to even more sales for you.

[AncientFuture]

http://bedroomproducersblog.com/2017/08 ... nthesizer/

Pointed them to your plugin, today a review appeared

Awesome. I really like their reviews compared to others that simply repeat website info. He actually uses the stuff.

For a whole day too

[mik82]

I've found a possible bug with program saving (using the built in system)
The steps are
1) Create Wave Table oscillator and automate Wave Index - I've tried with both envelope and ADSR
2) Add FM (bipolar, modulator as amplitude)

If the preset is saved then on reloading, the FM doesn't work at all, with a flat line graph shown in the display next to the FM parameters
If I don't automate the Wave Index, then FM works fine on reload. I've tried automating the oscillator volume to see if it's a general problem with automation, but again, FM works fine.

[Scrubbing Monkeys]

http://bedroomproducersblog.com/2017/08 ... nthesizer/

Pointed them to your plugin, today a review appeared

Awesome. I really like their reviews compared to others that simply repeat website info. He actually uses the stuff.

For a whole day too

Is that you Tomislav?

[FathomSynth]

RPH, Thanks!

Frostline,

I will do some testing with Reaper today and the rest of this week.
If its caused by the block size it will require some redesign,
but it must be done because so many people use Reaper.
This will be issue 0021.

mik82,

OK, This will be an easy bug, I'll get it fixed for you pronto. Issue number 0020.

Yes, I first noticed a spike in sales after the ScottAxxe & RPH KVR reviews,
and now another huge spike in sales ever since the BPB review came out.
BPB has a massive user base and influence so it's not surprising.

It's funny that staying under the radar so long probably worked to our advantage,
considering all the features we got in before a major reviewer found it.

[RPH]

Yes, I first noticed a spike in sales after the ScottAxxe & RPH KVR reviews,
and now another huge spike in sales ever since the BPB review came out.
BPB has a massive user base and influence so it's not surprising.

Cool, glad more people are liking and buying your synth!

Yesterday I also placed a msg naming the free mono version plus link to your site thru Facebook on German mag Beats and Computer music ( post about best free synths in 2017 or so ).

[Distorted Horizon]

Computer music

I sent msg to musicradar too

[FathomSynth]

Cool!