Fathom Synth Development Thread

[Scrubbing Monkeys]

I am having an issue with an instance of Fathom with a simple preset (one oscillator, reverb, one modulator with a short envelope).

This is a Hi hat patch.
I press a key the sound plays
I see 2 to 3 percent cpu show up and return to zero
3 seconds after the cpu returns to zero it goes up to 23 % and stays there,
If I hit the key again everything repeats.

I noticed this when i fired up a recent project and the project quickly came to a halt due to cpu overload. this was not happening 5 hrs earlier.

I have noticed this in the past on all kinds of different patches but then it would disappear. I thought maybe it had to do with midi note off messages in Reaper.

Here's what I have tried.

The project I noticed it on was for the OSC. I am using Mulab 64 on win 7.
The project has about 20 instances of Fathom
I noticed the issue on two different patches ( oddly both drum related )

I reloaded the preset into Fathom. same result
I deleted the instance of Fathom then reinserted it. same result.
I shut down Mulab and restarted. Same result
I shut down windows. same result.
I opened Reaper, put in one instance of Fathom with same preset. NO PROBLEM
I opened a new project in Mulab inserted one Fathom with same preset. the problem returned.
This only takes place after a note is played.

Like I said before I have experienced this in Reaper using only one instance of Fathom. This was not happening earlier today in Mulab.
I am at a loss

Any thoughts?

[TheNeverScene]

I am having an issue with an instance of Fathom with a simple preset (one oscillator, reverb, one modulator with a short envelope).

This is a Hi hat patch.
I press a key the sound plays
I see 2 to 3 percent cpu show up and return to zero
3 seconds after the cpu returns to zero it goes up to 23 % and stays there,
If I hit the key again everything repeats.

I noticed this when i fired up a recent project and the project quickly came to a halt due to cpu overload. this was not happening 5 hrs earlier.

I have noticed this in the past on all kinds of different patches but then it would disappear. I thought maybe it had to do with midi note off messages in Reaper.

Here's what I have tried.

The project I noticed it on was for the OSC. I am using Mulab 64 on win 7.
The project has about 20 instances of Fathom
I noticed the issue on two different patches ( oddly both drum related )

I reloaded the preset into Fathom. same result
I deleted the instance of Fathom then reinserted it. same result.
I shut down Mulab and restarted. Same result
I shut down windows. same result.
I opened Reaper, put in one instance of Fathom with same preset. NO PROBLEM
I opened a new project in Mulab inserted one Fathom with same preset. the problem returned.
This only takes place after a note is played.

Like I said before I have experienced this in Reaper using only one instance of Fathom. This was not happening earlier today in Mulab.
I am at a loss

Any thoughts?

Does removing the reverb make any difference in cpu usage? Also, is there some extra release in an envelope that might not be audible, but is sucking up cpu anyway? I'm a little confused on whether it's Reaper or Mulab that's exhibiting the problem. I'm on Reaper, and have had similar cpu efficiency issues where an envelope that may have started with a short period, then the period got longer for whatever reason due to exploring, and then I ended up with a sound resembling the first period via tweaks, but the residuals had to be be refined to get cpu down, still ending up with the intended envelope setting. This probably makes no sense, and "periods" are not something I'm used to dealing with.

[Teksonik]

I've had to put Fathom on the shelf for awhile. Just a little too quirky at this point but I'll keep an eye on future development.

[FathomSynth]

RPH, The distortion dial on the noise page only adds distrotion to the oscillator not the noise. It doesn’t really belong on the noise page. I was planning on moving it to the front page of all oscillators but have not had the chance yet. I could apply it to the noise also but it would probably be useless since the frequency deviation of the distortion dial applied to the oscillator is very subtle and it would not make any difference on the noise which has a very wide frequency range.

Tj, Feature requests noted. The preset arrow only loads the audio not the gui. To load the gui for a preview hit the up arrow button next to it.

Setting modulation range manually is a good idea.

Scrubbing Monkeys, Yes, that’s a serious bug, I’ll fix that for the next release. But could you post the preset here even if it’s simple. I have not seen that problem yet here in my testing.

TheNeverScene. ADSR’s or Envelopes with long release times up the CPU load because the voice is busy on the release phase and is not available for new notes, so more voies are used. If the release time is as long as the midi notes being played it will double your CPU.

However once the envelope is done, it should not raise CPU. If CPU is high after the release phase and nothing is playing, then that is a bug, like the one SM just found, and if so please post the preset here.

Teksonik, Sorry to see you go, but please list the most quirky things here so I can fix them for everyone.

[tonedef71]

RPH, The distortion dial on the noise page only adds distrotion to the oscillator not the noise. It doesn’t really belong on the noise page. I was planning on moving it to the front page of all oscillators but have not had the chance yet. I could apply it to the noise also but it would probably be useless since the frequency deviation of the distortion dial applied to the oscillator is very subtle and it would not make any difference on the noise which has a very wide frequency range.

Tj, Feature requests noted. The preset arrow only loads the audio not the gui. To load the gui for a preview hit the up arrow button next to it.

Setting modulation range manually is a good idea.

Scrubbing Monkeys, Yes, that’s a serious bug, I’ll fix that for the next release. But could you post the preset here even if it’s simple. I have not seen that problem yet here in my testing.

TheNeverScene. ADSR’s or Envelopes with long release times up the CPU load because the voice is busy on the release phase and is not available for new notes, so more voies are used. If the release time is as long as the midi notes being played it will double your CPU.

However once the envelope is done, it should not raise CPU. If CPU is high after the release phase and nothing is playing, then that is a bug, like the one SM just found, and if so please post the preset here.

Teksonik, Sorry to see you go, but please list the most quirky things here so I can fix them for everyone.

. . .

[RPH]

RPH, The distortion dial on the noise page only adds distrotion to the oscillator not the noise. It doesn’t really belong on the noise page. I was planning on moving it to the front page of all oscillators but have not had the chance yet. I could apply it to the noise also but it would probably be useless since the frequency deviation of the distortion dial applied to the oscillator is very subtle and it would not make any difference on the noise which has a very wide frequency range.

Ahh, I never tried it with the oscillator tone because I thought it was related to noise somehow. Yeah, don’t apply it to the noise. Thanks for explaining.

[RichardSemper]

I am having an issue with an instance of Fathom with a simple preset (one oscillator, reverb, one modulator with a short envelope).

This is a Hi hat patch.
I press a key the sound plays
I see 2 to 3 percent cpu show up and return to zero
3 seconds after the cpu returns to zero it goes up to 23 % and stays there,
If I hit the key again everything repeats.

Using Mulab 7.7.4 and Cubase 7.5 on Windows 7 I have experienced the same issue as above, only the percentage is different to above - these factory patches:-

- 1973 Analog Saw LFO - rises to 43% after note off and stays there.
- Beat box Bass & Chongs Beat box bass - both of these max the cpu after note off.

If I hit the key again cpu returns to normal and then rises again.
This behaviour is consistently reproducible. I have tried dissecting the patch, deleting each modulator in turn until they were all removed, but the behaviour remained until the patch was initialised.

On a further test I have discovered that these patches use the master eq on the front panel. resetting these to default clears the cpu usage - I hope this helps with tracking the cause.

[Scrubbing Monkeys]

I did a lil more investigating. On the Mulab CPU annomoly. It seems to be related to the EQ on the main page.

Once I flattened the EQ on the preset in question the problem went away.
The more, as well as more aggressive the EQ adjustments the bigger the cpu drain.

No need for special preset.

Insert basic waveform Oscillator and make some EQ adjustments.

I have no logical reason why Mulab and not Reaper this time.


Mulab 7.7.4 Reaper 5.76 Win 7 64

[RPH]

No big EQ drain in Renoise, no matter which EQ setting.
I do see the CPU meter constantly blinking from nothing to 2%. Would be nice to have the readout shown permanently instead of blinking.

[RPH]

Bug:
- insert a basic audiocomponent
- Lower volume of the osc.
- Turn noise on to something.
- Addmod an envelope to the volume of the noise.
- Copy the audiocomponent

I notice the copied component does not give sound, while noise volume is 0.5, after I tweak the parameter there is sound.

[Scrubbing Monkeys]

Thae cpu/eq anomaly is also in Reaper. judt takes few more sieconds.

[RPH]

It's affecting your keyboard as well..

[Scrubbing Monkeys]

It's affecting your keyboard as well..

Funny.

Man its a wonder Its not everywhere. I need glasses. My readers are starting to be non useable. Or maybe I could try to extend my arms a bit. Anyway thanks for the chuckle and dont be surprised if you see alot of that.

And by the way thats why I like Fathom so much. I CAN SEE IT!

[FathomSynth]

OK, guys, thanks so much for working on the EQ CPU problem,
I'll be fixing bugs all day today for 2.9, so I will start with this one.

Is it the mulab cpu meter or the fathom meter that is going up?

Nevermind, I found it. Easy bug, will be fixed in 2.9.

For the curious, this is caused by extremely small floating point numbers in the master filter, which can drive CPU way up during floating point math. Most of my filters have a check for this, but I missed the master EQ filter.

I managed to recreate this problem exactly as SM described in MuLab with the debugger going, and the MuLab cpu meter when from 2% to 12% (i7 6 cores 3.3 GHz) as the samples through the master filter decreased after a few seconds.

I put the floating point check on the filter and the CPU stays at 2% constant.

Also, Fathom's signal flow filters are skipped once the voices are no longer used after the final note decay, but this also was left out of the master EQ filter.

So I will also be changing the master EQ filter so it is bypassed after the final note decay on the last voice, this should reduce CPU to almost zero once the last voice is done after a note.

[Scrubbing Monkeys]

OK, guys, thanks so much for working on the EQ CPU problem,
I'll be fixing bugs all day today for 2.9, so I will start with this one.

Is it the mulab cpu meter or the fathom meter that is going up?

Nevermind, I found it. Easy bug, will be fixed in 2.9.

For the curious, this is caused by extremely small floating point numbers in the master filter, which can drive CPU way up during floating point math. Most of my filters have a check for this, but I missed the master EQ filter.

I managed to recreate this problem exactly as SM described in MuLab with the debugger going, and the MuLab cpu meter when from 2% to 12% (i7 6 cores 3.3 GHz) as the samples through the master filter decreased after a few seconds.

I put the floating point check on the filter and the CPU stays at 2% constant.

Also, Fathom's signal flow filters are skipped once the voices are no longer used after the final note decay, but this also was left out of the master EQ filter.

So I will also be changing the master EQ filter so it is bypassed after the final note decay on the last voice, this should reduce CPU to almost zero once the last voice is done after a note.

Sweet!!!