Fathom Synth Development Thread

[zzz00m]

In my experience with Fathom, CPU consumption is directly related to the number of notes actually being played in polyphonic mode.

Polyphony really seems to add up quickly. I can play a mono lead line and maybe hit 5-15% CPU, so no problems there. But if I play a chord with 3-4 notes it can easily get to 30-60%. And if I play a huge pad with both hands and the polyphony knob cranked way up, it can easily red line.

It probably has much to do with the amount of processing for each oscillator in the patch, multiplied by the number of active oscillators required for each note played simultaneously. I assume that each polyphonic note, or pitch, that you play in real-time requires an additional copy of the oscillator processes and other linked modules to be running in parallel in the CPU.

Using draft mode doesn't seem to have a huge effect on this, but dialing down the max amount of polyphony does.

[FathomSynth]

zzz00m,

Yes, that is correct, the relationship between voices and CPU is a direct multiply.

I have not yet found anyway to share calculated resources between voices. Changing to draft mode should give you a 40% increase in CPU, at least that's what I found during my own testing.

Also, I'm glad you brought this up again, because I've been wanting to do this for a long time. I just added sections to the manual on Memory and CPU. You can download the latest copy here:

https://www.fathomsynth.com/support/

The new sections on Memory and CPU cover everything you need to know to minimize both. To be honest, only once have I ever had to bounce tracks for Fathom when I make the web site demo songs, and some of my songs have 25 tracks of Fathom all playing at once. The two new manual sections cover all the tricks I use to get CPU to behave nicely.

Also 2.19 will coming out in a day or two and the Memory will go from about 1.5 GB to 150 MB.

After that the CPU will be the last frontier in terms of weaknesses for Fathom. And before the end of this year I will be rewriting the processor code to use Vector SIMD which will multiply the CPU efficiency by 4 and get Fathom's CPU in line with other synths such as Sylenth and Omnisphere.

[zzz00m]

@FathomSynth, thanks for the explanation, and the additional sections in the manual! That explains things quite well. It gives some good examples for making adjustments, if necessary.

Knowing that you are about to release an update with the memory footprint reduction, and are discussing openly your planned roadmap for processor optimization, gives me hope that this will be a very high performance synth as it matures.

Also knowing that you use Ableton on your test system is good to know for reference, because that is one of the DAWs that I have available to me.

I realize that I am probably CPU bottlenecked with an older Intel dual core CPU, compared to the 6 cores you are testing with. Hopefully one of these days I can upgrade my build to at least 6 cores in order to catch up with these modern times!

[FathomSynth]

Yes, from now to the end of the year the Vector SIMD processing will be top priority.

Once I get that done CPU will no longer be an issue.

[glokraw]

In my experience with Fathom...snip...if I play a huge pad with both hands and the polyphony knob cranked way up, it can easily red line.

Is the Fathom reverb on? Maybe the daw, or known light-cpu reverb
could supply that ambience tacked on after Fathom?

Have you tried how much amp release and sustain you can reduce,
while keeping the sound likeable and useful?

Is there a long filter release that could be shortened
etc
Cheers

Don't forget the sustain pedal when testing cpu, I use that
when trying to peg the meter, looking for ways to minimize other things

[Scrubbing Monkeys]

I finally got a chance to play around with the basic AdSR. I like the implementation. It reminds me of a bank of Hartke 3 inch speakers.

Two requests....

Allow the decay to be modulated.
Allow it to jump straight from decay to release.

Right now.... if you set decay to say 1 second, the sustain to 0 and the release to 1 second. If you release the key before 1 second it cuts off because the sustain is 0. If you hold the key untill the decay finishes then release there is no sound because sustain is at zero.
This is exactly like the full ADSR. You cant have release without sustain.

[FathomSynth]

OK, I'll see what I can do.

[monomaker]

Thanks for your reply.

I could not find in the link above a description of what exactly micro-tuning is.

For this purpose microtuning is simply using any tuning other than 12 equal divisions of the octave (it actually means intervals smaller than a semitone, but let's not get hung up on that). A microtonal scale could have any number of notes and they can be arranged in any way possible to create an octave (or not). To implement you just need a list of tuning values for each key, then as midi notes comes in you set its tuning from the 128 value array taken from a TUN or SCL/KBM file. I suggest ignoring the latter, because it's more work and looking at the TUN file spec.

How much resolution or precision is needed?

Two decimal places of a cent is more accurate than anyone can hear I think, so I'd go with that.

Should this be saved per preset, per track, or globally?

Globally and you need to be able to lock the tuning (so you can browse presets with the tuning fixed).

Please provide link to micro-tuning so I can do that in the next release.

The process involves opening a TUN file (its just human readable text) and reading the relevant part which is a 128 note table. You want the [Exact Tuning] table first (which has decimal cents values), if that fails take the [Tuning] table (cents as integers) and then tune each incoming midi note number to the value in the table. Values are relative in cents to A=440 Hz/midi note 69. You only need to implement this part of the TUN spec and to this standard - don't read the whole thing and panic, it's simply opening a text file, reading 128 values and then applying the tuning to the incoming midi note.

Example code is provided :

Here's the spec : https://www.mark-henning.de/files/am/Tu ... V2_Doc.pdf
Here's some tools : https://www.mark-henning.de/files/am/TUN-Tools_V100.zip
Here's C++ source code : https://www.mark-henning.de/files/am/TU ... e_V200.zip

It's implemented in the manner I'm suggesting in U-he synths should you need a frame of reference (or something to test against). There are other ways but this is quickest and most accurate way to code it because the values are fixed so it's simply a list of 128 cent values assigned to keys, relative to A/69. If you need more help let me know.

[FathomSynth]

monomaker, Hi, Thanks so much for the micro-tuning info, that will be useful.

It's actually easier than I thought, since Fathom already has it's own tuning table. All I have to do is read the file and load the ratio's into the existing table, done.

Then at some point in the future I can add an actual tuning interface so you can create your own tunings from inside Fathom.

I've read through most of the material and it seems that the Scala file format is the most common, but if you think AnaMark is equally or more common then I can read that one as well.

I have to be honest, I will probably be doing this after the CPU Vector code since that is a slightly more dire situation for Fathom.

Scrubbing Moneys, I'm having trouble recreating your scenario. It seems to be working perfectly for me.

If I release the note before the end of the decay phase it smoothly goes to the release phase as I intended. This is true no matter how fast the note is released. It also works for me no mater what the sustain level is set to (as long as it is not absolute zero).

It's true that if you set the sustain level to absolute zero which also sets the start of the release phase amplitude to zero then there will be no release at all, but this is because if the release phase does not actually exist then Fathom does not know what to do, it has to at least have some shape no matter how small.

This is easy to get around by simply setting the end of the sustain level and start of the release to a very small value, then it should work fine.

That being said, I can see it might make sense if you want the decay to go to zero if you hold it through the entire decay phase, but to have a gradual release phase if the note is released before the end of the decay.

I think I can probably do this by using a virtual release phase, by assuming if there is a release segment with time duration greater than zero (even if the release segment is at zero amplitude), that the user intends the release phase to kick in if the decay is interrupted.

EDIT: I was in that code today anyway, so I tried it as you suggest, and it seems to work fine and be fairly intuitive, so I will go ahead and put that change into 2.19. In the unlikely event that someone actually wants their envelopes to suddenly shut off to zero amplitude if the release phase amplitude is zero, then we can always just tell them to create a slight difference in amplitude between the last segment and release segment which tells Fathom to take the envelope literally.

[monomaker]

I've read through most of the material and it seems that the Scala file format is the most common, but if you think AnaMark is equally or more common then I can read that one as well.

They're very different; I think TUN is more popular for VSTi's, because it's so much easier to implement. Whereas Scala necessitates calculating the ratios/values and then imposing them on a seperate keyboard map. So much more to go wrong with the SCL/KBM method.

I have to be honest, I will probably be doing this after the CPU Vector code since that is a slightly more dire situation for Fathom.

Sure, just please don't forget about us - we can't use Fathom at all because it's out of tune!

Thanks for your time.

[Scrubbing Monkeys]

monomaker, Hi, Thanks so much for the micro-tuning info, that will be useful.

It's actually easier than I thought, since Fathom already has it's own tuning table. All I have to do is read the file and load the ratio's into the existing table, done.

Then at some point in the future I can add an actual tuning interface so you can create your own tunings from inside Fathom.

I've read through most of the material and it seems that the Scala file format is the most common, but if you think AnaMark is equally or more common then I can read that one as well.

I have to be honest, I will probably be doing this after the CPU Vector code since that is a slightly more dire situation for Fathom.

Scrubbing Moneys, I'm having trouble recreating your scenario. It seems to be working perfectly for me.

If I release the note before the end of the decay phase it smoothly goes to the release phase as I intended. This is true no matter how fast the note is released. It also works for me no mater what the sustain level is set to (as long as it is not absolute zero).

It's true that if you set the sustain level to absolute zero which also sets the start of the release phase amplitude to zero then there will be no release at all, but this is because if the release phase does not actually exist then Fathom does not know what to do, it has to at least have some shape no matter how small.

This is easy to get around by simply setting the end of the sustain level and start of the release to a very small value, then it should work fine.

That being said, I can see it might make sense if you want the decay to go to zero if you hold it through the entire decay phase, but to have a gradual release phase if the note is released before the end of the decay.

I think I can probably do this by using a virtual release phase, by assuming if there is a release segment with time duration greater than zero (even if the release segment is at zero amplitude), that the user intends the release phase to kick in if the decay is interrupted.

EDIT: I was in that code today anyway, so I tried it as you suggest, and it seems to work fine and be fairly intuitive, so I will go ahead and put that change into 2.19. In the unlikely event that someone actually wants their envelopes to suddenly shut off to zero amplitude if the release phase amplitude is zero, then we can always just tell them to create a slight difference in amplitude between the last segment and release segment which tells Fathom to take the envelope literally.

I am not sure how other synths ( hardware or sofware) do this but basically if uou release the key before the decay segment it hands it off to the release . Some synths hand it off at the same ampltude then continue with what ever is left of the release. Others start from the beginging of the release. where you could actually hold down the key indefinitely, then whe n released plays the entire release segment.

The first case allows for one shots.
The second allow for some cool rythm fx.
Both assume sustain is absolute zero.

[willsavino]

I've noticed the same problem as Scrubbing Monkeys. I much prefer it when a synth's release starts at the most recent amplitude when the key is released. So instead of jumping right to the sustain volume (i.e. zero), it continue from where it was at in the decay. Maybe you could just give us a toggle for ADSR behavior?

[FathomSynth]

SM, willsavino, Good news, I have the code changes done for the envelope and it's working fine.

It will continue the release envelope smoothly even if it is at zero amplitude.

Actually it can do it both ways, if in the envelope you make the end point of the last segment before the release different in amplitude than the starting point of the release, then Fathom sees the difference and knows that you do not intend the envelope to be smooth and so it will follow the envelope literally. But if the points match then it will use SM's smoothing request.

monomaker, I will try to get the tuning in the release after this one, which format is "TUN" is that the same as the white paper spec you posted the link to?

[willsavino]

Wow, very cool. Thanks so much! I really appreciate how quickly you respond to these feature requests.

[dandezebra]

Yeah, this shit rocks. If that doesn't sum it up, I don't know what does!