Is pitch bend range still considered to be programmed as modulation? I would strongly vote against it! I have not found a parameter for the pitch bend range... (should be global or lockable like in the U-He synths)
For any synth I open this is the first parameter I need to change! (Second is to get rid of any vibrato modulation). I have an expressive controller these parameters I want to play with the controller...
Pitch should always be considered to be a combination of Midi note and pitch bend information. Though the pitch wheel could be used as modulator for specific sounds, its crucial for the standard way of thinking, that its just there for the pitch... To be able to set the range is crucial and I should be able to find it on first glance... (If I wanted it as a different modulator I would also need to set it to zero...)
Fathom Synth Development Thread
-
- KVRAF
- 9543 posts since 6 Jan, 2017 from Outer Space
-
- KVRist
- 64 posts since 8 Mar, 2019
That was awesome! It just needs a "thick bassy drop". Use a pulse with an EQ filter to drop that bad boy into a Trance Rhythm with a low end "Kick"! Thoroughly enjoyed that patch! Check your email. Hope you like the combo
Just a "D" hit and it kick's in: http://ambietica.lyonsdenmultimedia.com ... cer-D3.mp3Ambient Sound Design & Soundtrack Composition - http://ambietica.lyonsdenmultimedia.com/
-
- KVRist
- 392 posts since 1 Jul, 2004
hope that MPE support is still in the pipelineFathomSynth wrote: Sun Nov 18, 2018 12:56 amEdit: Pipeline includes 2.23 released tomorrow (Sunday) with Fractal Reverb. After that, for the rest of this year is the Oscillator redesign with Spectral Morphing and the Analog Emulator. Early 2019 will be the Sampler, Apreggiator and MPE.
Great synth!-
- KVRAF
- 9543 posts since 6 Jan, 2017 from Outer Space
If there would be MPE support, the need for PB range would be much less urgent, though I am sure its easier to implement and would make sense in other workflows as well...
-
- KVRAF
- Topic Starter
- 1584 posts since 25 Mar, 2017
Go into settings and set the Master Pitch Range to the range you want.
Then add a modulation to the master Pitch dial and select the modulator Pitch Bend.
Set the modulation amount so it covers the entire range of the dial.
Then the pitch bend wheel will have the exact range you want.
In the next release I will make it so the Master Pitch Range setting goes directly to the default pitch bend signal without having to add the modulation, which I thought I had already done but unfortunately I had not done yet.
Then add a modulation to the master Pitch dial and select the modulator Pitch Bend.
Set the modulation amount so it covers the entire range of the dial.
Then the pitch bend wheel will have the exact range you want.
In the next release I will make it so the Master Pitch Range setting goes directly to the default pitch bend signal without having to add the modulation, which I thought I had already done but unfortunately I had not done yet.
-
- KVRAF
- 9543 posts since 6 Jan, 2017 from Outer Space
Thanks...FathomSynth wrote: Sat May 04, 2019 2:55 pm In the next release I will make it so the Master Pitch Range setting goes directly to the default pitch bend signal without having to add the modulation, which I thought I had already done but unfortunately I had not done yet.
I did find that Master Pitch Range, but it did not do anything, that's why I was confused...
-
- KVRAF
- Topic Starter
- 1584 posts since 25 Mar, 2017
Apply an ADSR envelope modulator to the master volume.
Same goes for an ADSR applied to anything such as a filter cutoff frequency.
Decide which segment of each envelope is the sustain segment, usually it's the second segment after the attack segment, but it doesn't have to be.
In the envelope editor, click on the first point of the sustain segment to select it.
Enable the Envelope Glide On toggle.
Set the master Glide dial to Time and the Glide Time dial to the desired glide time.
Now when you play a monophonic lead and notes are adjacent or overlap the envelope will start at the glide on point which is the sustain segment and will skip the attack phase.
But when new notes are played which are not adjacent the attack phase will be played.
You can also get clever by having a small attack phase just before the sustain phase and enabling the Glide On bar at the start of that smaller attack segment which will be used for adjacent notes while the bigger attack phase at the very beginning of the envelope will be played for non adjacent notes.
Also see the setting Mono Note Tap Return if you want the mono oscillator frequency after tapped notes to return to the held note, just like a hardware moog.
Yeah, I'm not sure why I forgot to make the pitch range setting not simply apply to the built in pitch wheel since that is pretty obvious but unfortunately I forgot, so that will be done for sure in 2.31.
Same goes for an ADSR applied to anything such as a filter cutoff frequency.
Decide which segment of each envelope is the sustain segment, usually it's the second segment after the attack segment, but it doesn't have to be.
In the envelope editor, click on the first point of the sustain segment to select it.
Enable the Envelope Glide On toggle.
Set the master Glide dial to Time and the Glide Time dial to the desired glide time.
Now when you play a monophonic lead and notes are adjacent or overlap the envelope will start at the glide on point which is the sustain segment and will skip the attack phase.
But when new notes are played which are not adjacent the attack phase will be played.
You can also get clever by having a small attack phase just before the sustain phase and enabling the Glide On bar at the start of that smaller attack segment which will be used for adjacent notes while the bigger attack phase at the very beginning of the envelope will be played for non adjacent notes.
Also see the setting Mono Note Tap Return if you want the mono oscillator frequency after tapped notes to return to the held note, just like a hardware moog.
Yeah, I'm not sure why I forgot to make the pitch range setting not simply apply to the built in pitch wheel since that is pretty obvious but unfortunately I forgot, so that will be done for sure in 2.31.
-
- KVRAF
- 2034 posts since 30 Mar, 2008 from MN, USA
I love Fathom. I really do. But for a long time, I've been hoping its performance issues would be fixed. But they never are. Even with 2.29, it is barely better than before. Maybe for you Windows users it made a difference. It did little for me.
When I bought Fathom, I had a maxed-out 2016 Macbook Pro i7 model. Now I have a maxed-out 2018 Macbook Pro (2.9Ghz i9, 32G of DDR4 RAM). That didn't help at all. I cannot perform even with a single instance of Fathom, even with patches of no more than medium complexity, in draft quality, with the buffer cranked to max. It starts out fine. As soon I get to a part of the performance with a few chords played in succession, it all falls apart. Crackles and distortion. Even before that, I get audio drop-outs for no apparent reason. I have had this problem on every version of Fathom since I bought it. I have it with or without multi-processing turned on. I have it on all DAWs (Bitwig, Ableton, Hosting AU). I have it with the AU and the VST. I have it with the main build, and the Stereo Performer build. I have it when there's nothing but Fathom running. No other effects in my plugin chain. Nothing on my busses.
Perhaps multi-core does not really work on Mac. I don't see any difference in CPU usage with it on. The Fathom CPU meter regularly hits yellow as distortion city sets in. The system CPU meter barely budges, on a 6-core machine.
Even a patch with 2 wavetable oscillators, one filter, 5 or 6 mod sources (some with a shared ASDR), and the air chorus effect is enough to get audio dropouts, and when playing several chords in succession, the distortion. I don't consider that an especially complex patch. Anything complex, like for example, the Piano Glass Keys patch in the factory Piano bank, is essentially unplayable.
I love the sound of Fathom. I love what it is capable of. I just wish I could use it.
When I bought Fathom, I had a maxed-out 2016 Macbook Pro i7 model. Now I have a maxed-out 2018 Macbook Pro (2.9Ghz i9, 32G of DDR4 RAM). That didn't help at all. I cannot perform even with a single instance of Fathom, even with patches of no more than medium complexity, in draft quality, with the buffer cranked to max. It starts out fine. As soon I get to a part of the performance with a few chords played in succession, it all falls apart. Crackles and distortion. Even before that, I get audio drop-outs for no apparent reason. I have had this problem on every version of Fathom since I bought it. I have it with or without multi-processing turned on. I have it on all DAWs (Bitwig, Ableton, Hosting AU). I have it with the AU and the VST. I have it with the main build, and the Stereo Performer build. I have it when there's nothing but Fathom running. No other effects in my plugin chain. Nothing on my busses.
Perhaps multi-core does not really work on Mac. I don't see any difference in CPU usage with it on. The Fathom CPU meter regularly hits yellow as distortion city sets in. The system CPU meter barely budges, on a 6-core machine.
Even a patch with 2 wavetable oscillators, one filter, 5 or 6 mod sources (some with a shared ASDR), and the air chorus effect is enough to get audio dropouts, and when playing several chords in succession, the distortion. I don't consider that an especially complex patch. Anything complex, like for example, the Piano Glass Keys patch in the factory Piano bank, is essentially unplayable.
I love the sound of Fathom. I love what it is capable of. I just wish I could use it.
CLAP Software Database: https://clapdb.tech. KVR Discussion Topic.
-
- KVRAF
- Topic Starter
- 1584 posts since 25 Mar, 2017
Teilo, CPU efficiency still remains Fathom's big weakness.
There are a several issues at work here.
1. Vector SIMD and GPU Processing
I admit I've been promising people that this will be fixed since approximately a year ago. However, I'm extremely bad at saying "No" and from approximately last August until now, I've been spending 90% of my time adding small user feature requests and fixing bugs.
I promised myself that starting after this release 2.30 that all feature development would stop until the CPU problem is addressed.
In the background I have been working on Fathom 3.0 which uses Intel Vector SIMD which is an 8X speed multiply and NVIDIA GPU processing which is between a 10X and 1024 X multiply depending on the architecture and buffer delay to the Video Card. I have both technologies running perfectly in Fathom's 3.0 code but the main processing code still needs to be converted to SIMD and GPU instructions which is a major project.
2. Reading the Manual
I use Fathom extensively in Ableton on a 5 year old computer with an Intel i7 and 64 GB of RAM. I use Fathom for all the Fathom demo songs and some of them are extremely complex with up to 20 Fathom tracks all playing at the same time. It is very rare that I have to bounce tracks for CPU and if I do it is because the song has over 20 tracks of Fathom with chords on each track.
The reason it is not a problem for me is that I designed and coded Fathom and I know exactly what it is doing under the hood, so I know how to avoid all CPU problems by avoiding the use of excessive Detune Voices, Long ADSR release times, excessive use of Effects that hurt the CPU but make no audible difference, etc, etc.
I often take a look in other user's presets after they complain about the CPU and find 9 oscillators all using 8 detune voices each with ADSR release times over 4 seconds, 53 unused modulators in the Matrix, and it's no surprise they are running out of CPU.
With this in mind I wrote an entire section of the User's Manual on how to manage CPU using Fathom. But sadly people simply don't read it.
For instance solving the problem could be as simple as setting the "Max CPU Per Track" setting appropriately for the number of tracks and CPU cores, but no one would know about it unless they read the manual.
Also, I use Ableton which is not only about twice as efficient as most DAW's but also automatically assign tracks to processor cores. Often when users report problems and I load the project into one of my testing hosts I find out that it is not sent to place multiple tracks on multiple cores and they are trying to run 25 tracks of Fathom all on one core. (Another reason to read the CPU section of the manual which explains this).
I would strongly recommend finding out if your DAW is assigning tracks to processor cores.
Conclusion:
If I can stick to my plan of attacking the Vector SIMD for the next couple months then the CPU problem will be solved but I will have to start saying no to feature requests and all but the most serious bug reports.
Also, the primary reason that Fathom is $32 instead of $132 compared to other synths with the same feature (or less) is precisely this reason, namely CPU, and since I'm aware Fathom is not competitive in the CPU domain the prices is set accordingly.
There are a several issues at work here.
1. Vector SIMD and GPU Processing
I admit I've been promising people that this will be fixed since approximately a year ago. However, I'm extremely bad at saying "No" and from approximately last August until now, I've been spending 90% of my time adding small user feature requests and fixing bugs.
I promised myself that starting after this release 2.30 that all feature development would stop until the CPU problem is addressed.
In the background I have been working on Fathom 3.0 which uses Intel Vector SIMD which is an 8X speed multiply and NVIDIA GPU processing which is between a 10X and 1024 X multiply depending on the architecture and buffer delay to the Video Card. I have both technologies running perfectly in Fathom's 3.0 code but the main processing code still needs to be converted to SIMD and GPU instructions which is a major project.
2. Reading the Manual
I use Fathom extensively in Ableton on a 5 year old computer with an Intel i7 and 64 GB of RAM. I use Fathom for all the Fathom demo songs and some of them are extremely complex with up to 20 Fathom tracks all playing at the same time. It is very rare that I have to bounce tracks for CPU and if I do it is because the song has over 20 tracks of Fathom with chords on each track.
The reason it is not a problem for me is that I designed and coded Fathom and I know exactly what it is doing under the hood, so I know how to avoid all CPU problems by avoiding the use of excessive Detune Voices, Long ADSR release times, excessive use of Effects that hurt the CPU but make no audible difference, etc, etc.
I often take a look in other user's presets after they complain about the CPU and find 9 oscillators all using 8 detune voices each with ADSR release times over 4 seconds, 53 unused modulators in the Matrix, and it's no surprise they are running out of CPU.
With this in mind I wrote an entire section of the User's Manual on how to manage CPU using Fathom. But sadly people simply don't read it.
For instance solving the problem could be as simple as setting the "Max CPU Per Track" setting appropriately for the number of tracks and CPU cores, but no one would know about it unless they read the manual.
Also, I use Ableton which is not only about twice as efficient as most DAW's but also automatically assign tracks to processor cores. Often when users report problems and I load the project into one of my testing hosts I find out that it is not sent to place multiple tracks on multiple cores and they are trying to run 25 tracks of Fathom all on one core. (Another reason to read the CPU section of the manual which explains this).
I would strongly recommend finding out if your DAW is assigning tracks to processor cores.
Conclusion:
If I can stick to my plan of attacking the Vector SIMD for the next couple months then the CPU problem will be solved but I will have to start saying no to feature requests and all but the most serious bug reports.
Also, the primary reason that Fathom is $32 instead of $132 compared to other synths with the same feature (or less) is precisely this reason, namely CPU, and since I'm aware Fathom is not competitive in the CPU domain the prices is set accordingly.
Last edited by FathomSynth on Sat May 04, 2019 11:55 pm, edited 4 times in total.
-
- KVRist
- 378 posts since 8 Sep, 2005 from Seattle
Thank you!FathomSynth wrote: Sat May 04, 2019 7:50 pm Apply an ADSR envelope modulator to the master volume.
Same goes for an ADSR applied to anything such as a filter cutoff frequency.
Decide which segment of each envelope is the sustain segment, usually it's the second segment after the attack segment, but it doesn't have to be.
In the envelope editor, click on the first point of the sustain segment to select it.
Enable the Envelope Glide On toggle.
Set the master Glide dial to Time and the Glide Time dial to the desired glide time.
Now when you play a monophonic lead and notes are adjacent or overlap the envelope will start at the glide on point which is the sustain segment and will skip the attack phase.
But when new notes are played which are not adjacent the attack phase will be played.
You can also get clever by having a small attack phase just before the sustain phase and enabling the Glide On bar at the start of that smaller attack segment which will be used for adjacent notes while the bigger attack phase at the very beginning of the envelope will be played for non adjacent notes.
Also see the setting Mono Note Tap Return if you want the mono oscillator frequency after tapped notes to return to the held note, just like a hardware moog.
Yeah, I'm not sure why I forgot to make the pitch range setting not simply apply to the built in pitch wheel since that is pretty obvious but unfortunately I forgot, so that will be done for sure in 2.31.
-
- KVRAF
- 2034 posts since 30 Mar, 2008 from MN, USA
Ok, let me simplify: I have this problem with a single instance of Fathom on a single track (meaning only that one track loaded in the DAW, and only Fathom on that track, nothing else), with Max CPU set anywhere from 80 to 100, using factory patches, on the best Macbook Pro currently available, with nothing else running. It happens in Ableton, Bitwig (which uses a separate instrument host process per track by default, which means a separately scheduled process in the OS), and Hosting AU (a super-lightweight host that is really only used for performance).FathomSynth wrote: Sat May 04, 2019 10:36 pm 2. Reading the Manual
For instance solving the problem could be as simple as setting the "Max CPU Per Track" setting appropriately for the number of tracks and CPU cores, but no one would know about it unless they read the manual.
…
I would strongly recommend finding out if your DAW is assigning tracks to processor cores.
In any case, I understand the price / performance balance you are presently trying to strike. I will say that I would pay $150 for Fathom its current state, in a heartbeat, and do so gladly, if the CPU load problems were addressed. So I'm happy to hear that's coming with Fathom Elite.
I guess part of the problem is that I want to use Fathom for performance, not just for production. For production, I can be judicious with polyphony, bouncing, etc. But I can't do that with performance.
CLAP Software Database: https://clapdb.tech. KVR Discussion Topic.
-
- KVRAF
- Topic Starter
- 1584 posts since 25 Mar, 2017
Something is either seriously wrong on your system, or seriously wrong with my Mac build.
One track should no way be a problem.
Which build of Fathom are you running? (Such as the Xeon build?)
Which Mac OSX version?
Which preset is it happening for, or if all of them just pick one, so I make sure to use the same preset.
Is there a block size setting in your DAW's?
Small block sizes like from FL Studio will cause this problem.
One track should no way be a problem.
Which build of Fathom are you running? (Such as the Xeon build?)
Which Mac OSX version?
Which preset is it happening for, or if all of them just pick one, so I make sure to use the same preset.
Is there a block size setting in your DAW's?
Small block sizes like from FL Studio will cause this problem.
-
- KVRist
- 64 posts since 8 Mar, 2019
I'll vote for Vector SIMD. Fathom has a lot of features as it stands, and more can be added later. Honestly in my opinion, Fathom has so many detailed features that if you can't get the sound your looking for, your not delving into the depths, and taking the time to understand synthesis combined with this extremely precise and detailed instrument. Just my opinion, but my opinion after delving into the depths.FathomSynth wrote: Sat May 04, 2019 10:36 pm If I can stick to my plan of attacking the Vector SIMD for the next couple months then the CPU problem will be solved but I will have to start saying no to feature requests and all but the most serious bug reports.
Ambient Sound Design & Soundtrack Composition - http://ambietica.lyonsdenmultimedia.com/
-
- KVRist
- 167 posts since 30 Oct, 2009
Just mentioning that I have the same problem as teilo on a Mac system on Ableton. Even one instance. So it's hard to pay for an update when now I'm hearing that even the update doesn't solve the problem. When users report a significant change in this area with the latest update, I'll reconsider. But most of us have so many synths as it is, to have to jump through hoops to get decent performance is just not worth it, and if it's unusable, paying even a minimal sum is not worth it. But I'm happy to hear that not everyone has this problem.
Music you can believe in:
http://rebshaya.com
http://rebshaya.com