TwoNotes GENOME!!!

Has likely been in the works for some time already, but Genome 1.3 (just released) doesn't change anything with load times. Obviously because the thing is still calling home on each "first time in a project" launch.
 
I'm still struggling with the fact it is a resource hog as compared to other plugins. I don't have a dated computer and this plugin is far too taxing. I was hoping this would have been corrected by now.

This is with the oversampling at Max on a very quick computer. S1 Maxed, Genome 100%.
1717774116869.png


1717774132649.png



set at high with no other plugins.
1717774197974.png

1717774205858.png
 
Last edited:
@dean701 Oversampling set to MAX seems a bit... much.

I take it you saw the following warning when you selected MAX ?

Screenshot 2024-06-07 at 17.17.03.png


Why would you need max? It is literally pushing the limits beyond what would be expected for normal use.
 
Last edited:
Fwiw, I can run a NAM (all captures I've tried so far) and cab combination at MAX without issues under 32 samples buffersize. That's on an M3 Macbook Air, though.
 
I've also noticed Genome is resource hungry, even with using a hefty iMac running 64 buffer size. I'll check my settings next time I'm in there, although I'm almost certain it's not even in MAX mode. I really like a lot of the patches but when you start getting random glitches and pops (sometimes 1 instance) it's no fun. FWIW, I don't have that issue running 4-6 instances of HX Native.
 
FWIW, I don't have that issue running 4-6 instances of HX Native.

Yeah, HXN is exceptionally CPU friendly. I'm able to run 4 fully loaded floor-compatible instances (as in not being able to add any block anymore) on Logic's live-thread, hence indeed running things at 32 samples @ 44.1kHz (RTL of 3.5ms). Given the modeling quality, that's quite impressive (but admittedly, that Macbook Air is one little powerful beast to be sure).
 
@dean701 Oversampling set to MAX seems a bit... much.

I take it you saw the following warning when you selected MAX ?

View attachment 23782

Why would you need max? It is literally pushing the limits beyond what would be expected for normal use.
I understand that but if they are going to give the option then I'm going to try it. Regardless, even set on high the cpu is higher than any other amp plug in I use including Helix Native. In fact, I can run 50 Helix native instances. (not that I would ever need that)

1717784391065.png
 
Last edited:
In fact, I can run 50 Helix native instances.

Again, you're not saying *what* you're running inside those instances (same as with your Genome statement). You're also not saying whether you're running all these instances on a live-thread or whether they're just playing back (quite some hosts treat those two kinds of tracks very differently). You're also not saying what computer you're using. "Very quick" in this discussion is of little value. And lastly, you're not telling us at what buffersize and samplerate you're running things.

In a nutshell, these statements are of very little value.
 
Again, you're not saying *what* you're running inside those instances (same as with your Genome statement). You're also not saying whether you're running all these instances on a live-thread or whether they're just playing back (quite some hosts treat those two kinds of tracks very differently). You're also not saying what computer you're using. "Very quick" in this discussion is of little value. And lastly, you're not telling us at what buffersize and samplerate you're running things.

In a nutshell, these statements are of very little value.
I could detail my system stats and bore everyone to death. passmark 32000, yadda, yadda. The fact remains that the plug in is cpu inefficient compared to any of my other amp plugins, which is all of them.
The stats I did provide for the genome cpu was with an amp, IR, reverb preset set at 128 samples. The helix preset was a kitchen sink preset with everything under the sun. I was only able to load 20 instances of Genome with that preset listed above before the CPU needle broke off.
 
I could detail my system stats and bore everyone to death.

It's pretty relevant when discussing CPU loads, though.

Whatever, in general, I at least sort of agree with you - compared to others, this is quite CPU inefficient.

So, to get somewhat more detailed information, I just made a little test, using a NAM capture called "Dumble Overdrive Special #102 Clone OD RockFord ESR 0.0013.nam" (from Tonehunt, I found this to be an incredibly nice one), using all the additional CODEX block features (Tonestack, EQ, Enhancer) and a cab block (ShortStack), running it at the "High" oversampling setting (which seems to be absolutely fine for everything, on this particular patch I'd also get away without oversampling).
At 44.1kHz (and 32 samples buffersizes - which is irrelevant for this test as it's just playback tracks, hence Logic is using a higher buffersize for them), I can pretty much exactly run 50 tracks with one instance each.

Did the same with HXN, using the VitriolCrunch (according to Ben Vesco that's reserving the most CPU ressources of all HX amps) and a dual cab block (btw, duplicating HXN instances is as painful as it gets, possibly the plugin with the slowest opening time ever - at least Genome is only slow on the first instance).
Could run around 105 tracks.

Then I repeated the Genome test without any oversampling, got 71 tracks running.

And finally I did the same test with GR7 (Player edition, so just two amps available, grabbed the Fire Seeker and its matching cab). 96 tracks. Not bad, because that amp is really sounding quite decent.

Ok, this is in no way a scientific test (tons of browser windows open, no idea how demanding NAM captures are in comparison, etc.), but very obviously, this test so far isn't in favour of Genome.
Would as well be interesting to see how NDSP amps and maybe S-Gear would do in any such a test, but I won't install any of their demos for the time being (I've got enough sims at my disposal without them and more often than not record my pedalboard anyway, not using any plugins).

Still, in the end, the main question for me would rather be "can I afford running this or that amp sim?" - and even with Genome, the answer is "yes". There's so much CPU overhead I just don't need to care much (if at all) about it anymore.

In the end, one thing I noticed as well is how slow all these amp sims are regarding load times. GR seems to be a bit faster than Genome and HXN, but it's still slowing down things a lot. I mean, loading Kontakt and, say, the "Brass Ensemble" from the Symphony Essentials library, then duplicating the track is around 5-10 times faster than duplicating an HXN track - and under the hood, there's a LOT going on in these Kontakt patches.
It's becoming even more apparent when loading a synth such as Zebra 2. Which is a *very* complexed synth. And yet, duplicating tracks is almost an instant affair.
Really wondering why these amp sims load so horribly slow (apart from Genome calling home at first launch per song).
 
It's pretty relevant when discussing CPU loads, though.

Whatever, in general, I at least sort of agree with you - compared to others, this is quite CPU inefficient.

So, to get somewhat more detailed information, I just made a little test, using a NAM capture called "Dumble Overdrive Special #102 Clone OD RockFord ESR 0.0013.nam" (from Tonehunt, I found this to be an incredibly nice one), using all the additional CODEX block features (Tonestack, EQ, Enhancer) and a cab block (ShortStack), running it at the "High" oversampling setting (which seems to be absolutely fine for everything, on this particular patch I'd also get away without oversampling).
At 44.1kHz (and 32 samples buffersizes - which is irrelevant for this test as it's just playback tracks, hence Logic is using a higher buffersize for them), I can pretty much exactly run 50 tracks with one instance each.

Did the same with HXN, using the VitriolCrunch (according to Ben Vesco that's reserving the most CPU ressources of all HX amps) and a dual cab block (btw, duplicating HXN instances is as painful as it gets, possibly the plugin with the slowest opening time ever - at least Genome is only slow on the first instance).
Could run around 105 tracks.

Then I repeated the Genome test without any oversampling, got 71 tracks running.

And finally I did the same test with GR7 (Player edition, so just two amps available, grabbed the Fire Seeker and its matching cab). 96 tracks. Not bad, because that amp is really sounding quite decent.

Ok, this is in no way a scientific test (tons of browser windows open, no idea how demanding NAM captures are in comparison, etc.), but very obviously, this test so far isn't in favour of Genome.
Would as well be interesting to see how NDSP amps and maybe S-Gear would do in any such a test, but I won't install any of their demos for the time being (I've got enough sims at my disposal without them and more often than not record my pedalboard anyway, not using any plugins).

Still, in the end, the main question for me would rather be "can I afford running this or that amp sim?" - and even with Genome, the answer is "yes". There's so much CPU overhead I just don't need to care much (if at all) about it anymore.

In the end, one thing I noticed as well is how slow all these amp sims are regarding load times. GR seems to be a bit faster than Genome and HXN, but it's still slowing down things a lot. I mean, loading Kontakt and, say, the "Brass Ensemble" from the Symphony Essentials library, then duplicating the track is around 5-10 times faster than duplicating an HXN track - and under the hood, there's a LOT going on in these Kontakt patches.
It's becoming even more apparent when loading a synth such as Zebra 2. Which is a *very* complexed synth. And yet, duplicating tracks is almost an instant affair.
Really wondering why these amp sims load so horribly slow (apart from Genome calling home at first launch per song).
Aside from the software dependencies like calling home, generally speaking, first load times are longer because of memory allocation. The first time something loads in a Daw, the daw spawns buffer space for that plug in. For the next load, it associates that program to align with the first and enough memory is usually already allocated for a few future added plugins. When it reaches that limit and has to allocate more memory, it may be sluggish on one of the future additions and then be quick again. First time loads happen for everything outside a daw as well, that's why software developers like to inject startup processes when your computer starts to limit the complaining of their load times. Apple does this with iTunes as an example...and don't get me started with Google Chrome.
 
Last edited:
Hi @dean701,

Thanks for getting in touch. Please note that our Ultra and MAX Oversampling modes are designed for offline rendering (bounce). These modes provide slight enhancements to audio quality at the cost of very high CPU usage. They are not fit for playback and for best use in a playing context, we suggest the HIGH and HIGH+ modes. Please note, our team are working on performance enhancements continually so stay tuned for updates on our site and socials!
 
RE: oversampling in Genome..
Another thing to mention here, as far as I'm aware those oversampling modes don't apply to NAM models. This is due to the fact that the vast majority* of NAM models are trained at 48khz sample rate. This is why in the NAM plugin it resamples, but doesn't oversample. So it's always best to simply use no oversampling to save on CPU in Genome when using NAM models in Codex.

* I know that the NAM plugin is now compatible with NAM models that have been trained with data that is non-standard, eg. 96khz training files using the CLI trainer. I can't confirm or deny if those are working correctly or not on Genome, perhaps someone else can.
 
Hi Dom, yes Genome works with other captures frequencies and you are correct on oversampling, the neural network models (NAM, AIDA, Proteus) have to run at the own frequency and cannot be oversampled without altering their response.

Regarding oversampling and when you should use it: some blocks which can generate distortion will create aliasing. Distortion/overdrive pedals, amp sims but also compressors can generate aliasing. You may or may not hear the aliasing and you even may not find it to be a problem, but many people do want an option to get rid of it. It's s subtle effect.

My recommendation: if you are very sensitive to latency, favor latency over removing the aliasing. And use the high levels oversampling values for rendering.

Dean, Some DAWs like Reaper can actually take care of the oversampling and send for example a 768KHz signal instead of the project's 48 (oversampling x16). This would be equivalent to Genome at max OS, try that with Helix using only TSM in Genome (which would be closer to Helix amp sim in terms of modeling) and l will be interested in your results.

Sascha Frank, regarding CPU: you cannot really compare the CPU needed for electronic approximation amp modeling and neural network modeling. If you are aiming at the best audio quality, standard profiles in NAM are incredibly CPU hungry, it's not because of a bad implementation, it's just how the technology is at this point. If you look at the newest hardware units able to do a decent neural network modeling, they pack an incredible amount of power compared to say a Helix or a Kemper.

Look at the TSM amps for example, they only need a fraction of the CPU needed for NAM. Our new TSM-AI format also asks for quite a bit of CPU, since neural networks are used. But you can try several quality options in the TSM-AI (or use lighter captures in NAM called nano or feather) and instantly save on CPU.

Regarding Genome load up times on first launch I 100% agree with you guys and be assured that it's a priority for us to fix this.
 
Last edited:
Hi Dom, yes Genome works with other captures frequencies and you are correct on oversampling, the neural network models (NAM, AIDA, Proteus) have to run at the own frequency and cannot be oversampled without altering their response.

Regarding oversampling and when you should use it: some blocks which can generate distortion will create aliasing. Distortion/overdrive pedals, amp sims but also compressors can generate aliasing. You may or may not hear the aliasing and you even may not find it to be a problem, but many people do want an option to get rid of it. It's s subtle effect.

My recommendation: if you are very sensitive to latency, favor latency over removing the aliasing. And use the high levels oversampling values for rendering.

Dean, Some DAWs like Reaper can actually take care of the oversampling and send for example a 768KHz signal instead of the project's 48 (oversampling x16). This would be equivalent to Genome at max OS, try that with Helix using only TSM in Genome (which would be closer to Helix amp sim in terms of modeling) and l will be interested in your results.

Sascha Frank, regarding CPU: you cannot really compare the CPU needed for electronic approximation amp modeling and neural network modeling. If you are aiming at the best audio quality, standard profiles in NAM are incredibly CPU hungry, it's not because of a bad implementation, it's just how the technology is at this point. If you look at the newest hardware units able to do a decent neural network modeling, they pack an incredible amount of power compared to say a Helix or a Kemper.

Look at the TSM amps for example, they only need a fraction of the CPU needed for NAM. Our new TSM-AI format also asks for quite a bit of CPU, since neural networks are used. But you can try several quality options in the TSM-AI (or use lighter captures in NAM called nano or feather) and instantly save on CPU.

Regarding Genome load up times on first launch I 100% agree with you guys and be assured that it's a priority for us to fix this.

Welcome to the forum, guillaume!

The information and interaction is appreciated!
 
Hi Dom, yes Genome works with other captures frequencies and you are correct on oversampling, the neural network models (NAM, AIDA, Proteus) have to run at the own frequency and cannot be oversampled without altering their response.

Regarding oversampling and when you should use it: some blocks which can generate distortion will create aliasing. Distortion/overdrive pedals, amp sims but also compressors can generate aliasing. You may or may not hear the aliasing and you even may not find it to be a problem, but many people do want an option to get rid of it. It's s subtle effect.

My recommendation: if you are very sensitive to latency, favor latency over removing the aliasing. And use the high levels oversampling values for rendering.

Dean, Some DAWs like Reaper can actually take care of the oversampling and send for example a 768KHz signal instead of the project's 48 (oversampling x16). This would be equivalent to Genome at max OS, try that with Helix using only TSM in Genome (which would be closer to Helix amp sim in terms of modeling) and l will be interested in your results.

Sascha Frank, regarding CPU: you cannot really compare the CPU needed for electronic approximation amp modeling and neural network modeling. If you are aiming at the best audio quality, standard profiles in NAM are incredibly CPU hungry, it's not because of a bad implementation, it's just how the technology is at this point. If you look at the newest hardware units able to do a decent neural network modeling, they pack an incredible amount of power compared to say a Helix or a Kemper.

Look at the TSM amps for example, they only need a fraction of the CPU needed for NAM. Our new TSM-AI format also asks for quite a bit of CPU, since neural networks are used. But you can try several quality options in the TSM-AI (or use lighter captures in NAM called nano or feather) and instantly save on CPU.

Regarding Genome load up times on first launch I 100% agree with you guys and be assured that it's a priority for us to fix this.
Welcome dude!
 
Our new TSM-AI format also asks for quite a bit of CPU, since neural networks are used. But you can try several quality options in the TSM-AI (or use lighter captures in NAM called nano or feather) and instantly save on CPU.
Are you able to share any information about how these TSM-AI models are created?

Is it something closer to liquid profiles (model with algorithmic tonestacks, perhaps pre and post EQ either side of the gain stage model), or is it more like a parametric NAM model (many models blended behind the scenes across different settings). Also, is the preamp modelling seperate from the poweramp modelling? Neural networks are quite good for poweramp modelling because there is less controls, but it also means you have fixed impedance relationships.

It would be cool to know - I have to say that unfortunately I was not impressed with the original TSM amp models in Genome, but this new approach may have me interested.

Thanks for joining, and I appreciate the insights so far!
 
Thank you for the warm welcome guys, I actually did not know this forum until recently and I spend more time on our own forums on socials where most of the action is.

Regarding TSM-AI I can't be too specific, apart from saying it's a mix of several technologies (neural network, electrical modeling, filtering etc) and we use what we think works best to provide flexibility and good tone. You can always try it in Genome for free, also some other TSM amps you may have missed MirrorProfiles and I'm always interested in getting honest opinions.
 
Thank you for the warm welcome guys, I actually did not know this forum until recently and I spend more time on our own forums on socials where most of the action is.

Regarding TSM-AI I can't be too specific, apart from saying it's a mix of several technologies (neural network, electrical modeling, filtering etc) and we use what we think works best to provide flexibility and good tone. You can always try it in Genome for free, also some other TSM amps you may have missed MirrorProfiles and I'm always interested in getting honest opinions.
Do you happen to like pickled vegetables?
 
Back
Top