UVI Falcon 3

[Jac459]

In any case, if Diva doesn't kill my CPU, then nothing I make in HALion or Falcon will. That's my point.

But that also depends on what type of computer you have.

Diva and HALion7 both support using multiple cores. Falcon doesn't, so yes it's quite possible for Diva to use multiple cores and not choke your CPU while Falcon can and will because it can only use a single core

If all you are doing is simple single timbres Falcon is fine, complex layered sounds it struggles even with an I9 and 32gb of RAM. That's why I sample it playing a single note at a time

I have Falcon 3 and many soundware of UVI and they run easily on my M2 Pro (quadra, whoosh, meteor, world suite 2, drum designer and many more).

I guess the time you will accept only one instance of one instrument choke fully one of your CPU are very very rare and unlikely. At least it never happened to me. Even less with Falcon.

I am not sure if multi-core support is interesting most of the times for synths as the DAW will generally work on distributing the different VSTs over the various cores.

[PAK]

Diva and HALion7 both support using multiple cores. Falcon doesn't, so yes it's quite possible for Diva to use multiple cores and not choke your CPU while Falcon can and will because it can only use a single core

I just tested Falcon there by stacking a 6 channel sound in one instance, and Cubase appears to be distributing it across multiple cores with Apple Silicon. However it appears the realtime Peak will overload well before it reaches an actual CPU limit, so it's not distributing as well as individual instances would.

[Jac459]

Diva and HALion7 both support using multiple cores. Falcon doesn't, so yes it's quite possible for Diva to use multiple cores and not choke your CPU while Falcon can and will because it can only use a single core

I just tested Falcon there by stacking a 6 channel sound in one instance, and Cubase appears to be distributing it across multiple cores with Apple Silicon. However it appears the realtime Peak will overload well before it reaches an actual CPU limit, so it's not distributing as well as individual instances would.

In a normal DAW session, I guess you have about 45-50 plugins playing together... I really don't get the need of one plugin managing multicore...
Better let that duty to the DAW...

[IvyBirds]

In a normal DAW session, I guess you have about 45-50 plugins playing together... I really don't get the need of one plugin managing multicore...
Better let that duty to the DAW...

In a normal DAW session when you have 40-50 plugins playing together the DAW can do a decent job of of managing multicore but it's more efficient to let plugins do it.

Rather than have my DAW guess at what is the best way to allocate resources I prefer to control that myself and I get better results

Again if all you are doing is rather simple patches that are not layered and playing them back in isolation you will never notice an issue

When you start making complex layered patches that's a lot of processing on a single core. Then run multiple instruments playing complex layered patches at the same time, then add effects like reverb and delays, then add the fact that your DAW is trying to guess at how to manage all of that and it's very possible that it guesses wrong over loads a core and you can get crackle and pops, latency, even crashes. It won't happen all the time, but it can and will happen, which can and will ruin your session

I choose to use an I9 with a bunch of RAM because it is significantly faster and has more cores and threads than anything else. It has 16 more threads than the M2 and those threads run significantly faster

Maybe that is not important to you, maybe you don't notice it when running a single patch

But when you are running a DAW session with 40-50 plugins, many of which are pushing things to the bleeding edge running at minimum buffer and high sample rates it can and will become an issue

But I get it someone ran a single patch in isolation and found no issues so obviously that applies to everyone all the time no matter the situation

[Jac459]

In a normal DAW session, I guess you have about 45-50 plugins playing together... I really don't get the need of one plugin managing multicore...
Better let that duty to the DAW...

In a normal DAW session when you have 40-50 plugins playing together the DAW can do a decent job of of managing multicore but it's more efficient to let plugins do it.

Rather than have my DAW guess at what is the best way to allocate resources I prefer to control that myself and I get better results

Again if all you are doing is rather simple patches that are not layered and playing them back in isolation you will never notice an issue

When you start making complex layered patches that's a lot of processing on a single core. Then run multiple instruments playing complex layered patches at the same time, then add effects like reverb and delays, then add the fact that your DAW is trying to guess at how to manage all of that and it's very possible that it guesses wrong over loads a core and you can get crackle and pops, latency, even crashes. It won't happen all the time, but it can and will happen, which can and will ruin your session

I choose to use an I9 with a bunch of RAM because it is significantly faster and has more cores and threads than anything else. It has 16 more threads than the M2 and those threads run significantly faster

Maybe that is not important to you, maybe you don't notice it when running a single patch

But when you are running a DAW session with 40-50 plugins, many of which are pushing things to the bleeding edge running at minimum buffer and high sample rates it can and will become an issue

But I get it someone ran a single patch in isolation and found no issues so obviously that applies to everyone all the time no matter the situation

Thanks for taking the time of a long answer.

Well there is a lot lot lot of parameters that will make a processing faster than a CPU. I am not an expert anymore but I remember optimizing code and struggling with drop of performance "after" optimizing to finally discovering that my slightly bigger algorithm was not anymore run on the L2 memory...
The fact that you have a lot of RAM for example has about 0 effect to your session of Falcon... Falcon run comfortably on a 8gb MacBook Air (with no swap nothing and 2gb not used).

Then this :

...together the DAW can do a decent job of of managing multicore but it's more efficient to let plugins do it.

Rather than have my DAW guess at what is the best way to allocate resources I prefer to control that myself and I get better results

I have very high doubt on this. I am not an expert on DAW management but the general rule of thumb for ressource managers is that the one having the global view is the one having the best view.

Most of the case (to not say 100% of the case), multicore management comes with an overhead in your algorithm. So instead of costing 100, your treatment cost 120 (because you need to reconcilisate and share a lot of resources, it isn't magical). But as you are using 2 cores, the cost is in fact 60 and 60 so that's fine.
When your DAW, distribute, your overhead is 0. Because you are distributing totally independent processes.


Finally, I am very curious of a usable preset that will maxout a modern CPU. Please share one preset if you can.
At least there is none crossing even 10% of usage in ANY of UVI libraries...

[IvyBirds]

Finally, I am very curious of a usable preset that will maxout a modern CPU. Please share one preset if you can.
At least there is none crossing even 10% of usage in ANY of UVI libraries...

No offense, but your thinking is to small. You want to focus on a single patch in a single plugin, rather than how that patch is working in a typical DAW session along side of dozens of other plugins all at the same time

You are also failing to understand how DAWs and Plugins allocate resources. With Falcon if you run a layered patch with say 6 elements all six of those elements are going to hit the same core, your DAW and other components of your OS and even the CPU itself can determine what tricks to use to manage that better but that takes CPU power also it's not a zero sum game

With HALion7 if I create a layered patch with 6 elements each element is assigned to a different core at the plugin level, it doesn't really require any processing power from the DAW or the OS or the CPU to pull that off, and the DAW, OS, and CPU doesn't have to guess. It's similar to loading 6 different instances of the plugin to spread CPU load over 6 cores only since it's a single instance it uses less resources

As for RAM allocation modern sample libraries are often GB in size for a single element in a single patch, if you create a layered patch with multiple large sample sets for those patches you quickly can run into a bottleneck and run out of RAM, HALion7 lets you balance this and lets you determine how much resources to allocate to preloading those sample libraries relative to streaming the data as needed from a fast SSD

Again not everyone will care about this or see any impact depending on how they use them

As for me I own and use plugins with multiple synth engines and multi timbrality because I want to create layered patches that use them. It's why I own Falcon, Omnisphere, and HALion7. I like to layer a sample based timbres with a Wavetable, and FM, and VA, maybe throw in some granular. Have one layer be focused on the attack phase of a sound, another the sustain and another the release. There are so many options when you start thinking that way, and for me I find HALion7 to be the perfect tool for that

As for Falcon I got it on sale. It has a pretty weird UI but I can live with that. When played in isolation it sounds and works awesome, so I just sample it. It's basically a sample library for me. If it's a basic sound using only a single element or two I can also just use it as is, but I will usually just sample it and then run it inside of HALion. Once there it's in a central location and easy to find again and I can use it in a layered patch with other elements made with other plugins or create a layered patch using the original sample, along with a Wavetable made from that sample and something else made from using the spectral oscillator again using that same sample

[Jac459]

Finally, I am very curious of a usable preset that will maxout a modern CPU. Please share one preset if you can.
At least there is none crossing even 10% of usage in ANY of UVI libraries...

No offense, but your thinking is to small. You want to focus on a single patch in a single plugin, rather than how that patch is working in a typical DAW session along side of dozens of other plugins all at the same time

You are also failing to understand how DAWs and Plugins allocate resources. With Falcon if you run a layered patch with say 6 elements all six of those elements are going to hit the same core, your DAW and other components of your OS and even the CPU itself can determine what tricks to use to manage that better but that takes CPU power also it's not a zero sum game

With HALion7 if I create a layered patch with 6 elements each element is assigned to a different core at the plugin level, it doesn't really require any processing power from the DAW or the OS or the CPU to pull that off, and the DAW, OS, and CPU doesn't have to guess. It's similar to loading 6 different instances of the plugin to spread CPU load over 6 cores only since it's a single instance it uses less resources

As for RAM allocation modern sample libraries are often GB in size for a single element in a single patch, if you create a layered patch with multiple large sample sets for those patches you quickly can run into a bottleneck and run out of RAM, HALion7 lets you balance this and lets you determine how much resources to allocate to preloading those sample libraries relative to streaming the data as needed from a fast SSD

Again not everyone will care about this or see any impact depending on how they use them

As for me I own and use plugins with multiple synth engines and multi timbrality because I want to create layered patches that use them. It's why I own Falcon, Omnisphere, and HALion7. I like to layer a sample based timbres with a Wavetable, and FM, and VA, maybe throw in some granular. Have one layer be focused on the attack phase of a sound, another the sustain and another the release. There are so many options when you start thinking that way, and for me I find HALion7 to be the perfect tool for that

As for Falcon I got it on sale. It has a pretty weird UI but I can live with that. When played in isolation it sounds and works awesome, so I just sample it. It's basically a sample library for me. If it's a basic sound using only a single element or two I can also just use it as is, but I will usually just sample it and then run it inside of HALion. Once there it's in a central location and easy to find again and I can use it in a layered patch with other elements made with other plugins or create a layered patch using the original sample, along with a Wavetable made from that sample and something else made from using the spectral oscillator again using that same sample

Ok mate, no offence taken.
I still disagree and you didn't answer my points, but good if you are happy.
Also, if you have 50 vst distributed on all your cores, you would have to explain me the advantage of splitting one of the 50 process in multiple cores.

But anyway, let's agree to disagree. This isn't a software engineering forum.
Cheers.

[PAK]

I have very high doubt on this. I am not an expert on DAW management but the general rule of thumb for ressource managers is that theone having the global view is the one having the best view.

You’re correct to doubt. As soon as you use two instances of anything neither has any awareness of what the other is doing. Whilst the OS will manage this a host can step in between and attempt to “intelligently” allocate resources based on its wider picture.

Obviously, how well hosts do this varies greatly. That’s what leads to such huge variations in the number of plugins different hosts can run. This is not a trivial task. It’s complex to the extent that some hosts will actually ruin your systems performance.

A single management approach also tends towards more consistent results Vs if a bunch of individual things (each subject to their own quality of implementation) attempt to do it. Besides which HALion and Falcon both tend to be heavier on resources than some of the alternatives like Kontakt

[IvyBirds]

Ok mate, no offence taken.
I still disagree and you didn't answer my points, but good if you are happy.
Also, if you have 50 vst distributed on all your cores, you would have to explain me the advantage of splitting one of the 50 process in multiple cores.

But anyway, let's agree to disagree. This isn't a software engineering forum.
Cheers.

What points didn't I answer?

As for splitting the cores let me explain it this way.

Imagine a warehouse with an 8 lane highway attached to it on one side of a town. That highway runs all the way to the other side of the town where it is attached to another warehouse

The first warehouse is filled with data that needs to be sent to the CPU for processing which is in the other warehouse. The highway represents the 8 cores of a modern CPU

If you are just running a single plugin that plugin can send a lot of traffic down a single lane/core with no issues

Now add a second plugin and you have two lanes, three plugins three lanes etc. Now imagine you have 50 to use your example. Each lane on the highway is now full of heavy traffic and your DAW, OS, and CPU is trying very hard to balance everything and all the lanes are full of traffic

Now you reach the climax of your song and you want to introduce a big pad using 6 elements in a layered patch

If you are using Falcon all of that is going to slam the already loaded lane at one time. Since it's already at the breaking point you could get artifacts, latency, etc

Using something like HALion7 that traffic is going to be spread over 6 cores with no effort by your DAW or OS since there is still space on each lane the likelihood of artifacts and/latency is greatly reduced

[IvyBirds]

You’re correct to doubt. As soon as you use two instances of anything neither has any awareness of what the other is doing. Whilst the OS will manage this a host can step in between and attempt to “intelligently” allocate resources based on its wider picture.

Sure and if you a smart plugin that allocates each element to a different core what does your DAW see?

You could have a huge patch running in Falcon with 6 layers, your DAW is going to see a huge data stream and has to manage that. Falcon doesn't care and can't see what the other stuff is doing all it doing is dumping a single huge data stream at your DAW. If you DAW is going to allocate that across several cores it will have to use CPU cycles to process how to allocate, how to break it down, how to send it down the pipe, and how to put it back together again

If you were running a plugin like HALion7 running 6 elements instead of seeing a single giant data stream your DAW would see 6 smaller ones which are then easy to allocate and just send the down the pipe

Depending on your usage this may or may not be an advantage to you

[PAK]

Sure and if you a smart plugin that allocates each element to a different core what does your DAW see?

You could have a huge patch running in Falcon with 6 layers, your DAW is going to see a huge data stream and has to manage that.

It’ll still see the same usage. The difference is whether the host retains control or whether the plugin takes a more direct role in its own resource allocation. The issue with that is, rather than work with the host, the plugin is now competing with it directly for CPU resources, even if the host can see what it’s doing. This has implications.

EG If a single-threaded application is so CPU heavy that it will overload a single core (The obvious example would be Diva, set to 16 note poly in Divine mode), then it requires multiple cores to achieve its full polyphony. Both HALion and Diva implemented this about 13 years back, when you really couldn’t count on hosts handling things - never mind well. Many users were still on Pentium / Core 2 Duo etc.

However things have really been changing lately. What do you think such implementations know about efficiency and performance cores? Or how they should load balance in a scenario where there’s dozens of cores? If they spread things as much as they can, rather than attempt to keep things confined to less cores, now they’re taking small chunks out of many cores.

Now say you have a very single threaded plugin where one core is only just enough to contain it? You’ve now impacted your ability to run that plugin Vs a host which may attempt to load balance into less cores because it has a better awareness of the current CPU situation. BTW, in Diva’s case, I think I've seen it mentioned that the CLAP version contains changes in how some of this stuff is able to be handled, though I haven’t used it to know details and if / how this results in any performance differences.

Anyway, I think that’s enough off-topic from me for about this. Suffice to say it is a complex issue which many hosts struggle with, and the main take away is to be aware that your host may be severely limiting your performance because of these factors.

[pekbro]

Multi-core processing is not necessarily gonna improve performance unfortunately. Since 2
cores share the same bus and mem, you can actually degrade performance in some situations. There are other issues
in maintaining balance and scheduling. System thread limits etc. Just to name a couple.

[Jac459]

Ok mate, no offence taken.
I still disagree and you didn't answer my points, but good if you are happy.
Also, if you have 50 vst distributed on all your cores, you would have to explain me the advantage of splitting one of the 50 process in multiple cores.

But anyway, let's agree to disagree. This isn't a software engineering forum.
Cheers.

What points didn't I answer?

As for splitting the cores let me explain it this way.

Imagine a warehouse with an 8 lane highway attached to it on one side of a town. That highway runs all the way to the other side of the town where it is attached to another warehouse

The first warehouse is filled with data that needs to be sent to the CPU for processing which is in the other warehouse. The highway represents the 8 cores of a modern CPU

If you are just running a single plugin that plugin can send a lot of traffic down a single lane/core with no issues

Now add a second plugin and you have two lanes, three plugins three lanes etc. Now imagine you have 50 to use your example. Each lane on the highway is now full of heavy traffic and your DAW, OS, and CPU is trying very hard to balance everything and all the lanes are full of traffic

Now you reach the climax of your song and you want to introduce a big pad using 6 elements in a layered patch

If you are using Falcon all of that is going to slam the already loaded lane at one time. Since it's already at the breaking point you could get artifacts, latency, etc

Using something like HALion7 that traffic is going to be spread over 6 cores with no effort by your DAW or OS since there is still space on each lane the likelihood of artifacts and/latency is greatly reduced

I don't know exactly what you want to prove by your story with the highways.
But I am doing IT for a living, I am currently managing a very large project for a bank with Spark, Kafka, Flink, K8s, 20 nodes and 3 data centres and we process about 1Billions messages per hour (1/3 of French economy). Earlier in my career, I was coding C for drone realtime guiding where we had to count the number of CPU cycle in order to make sure the process was done just in time. So I know a bit about resource management.

Yet, that doesn't make me an expert on the current discussion because like you, I have no f**king idea how Falcon is coded and I have no idea how a specific DAW is coded. And we are talking about very complex behaviours on which even Falcon, diva or Bitwig developers may be wrong (I have seen so many mistake and counter-optimisations in my career).

BUT, again, intuitively, if your VST is distributing the processes on multiple cores, there is still a big chance that some processes are centralised and some processes are distributed. Even without talking about memory bandwidth, algorithmically, you will have processes that are here to synchronise the calculation based on 2 cores. This process will necessarily wait at one moment because the cores will NEVER finish their processes at the same time. Then, as PAK is saying, the host or the OS will have to manage the few CPU cycles not used by the plugin.
This is an additional burden I am pretty convince is not interesting for the host because switching context is NOT free. It will again waste resources.

Now we could talk about memory bandwidth, what you say about the trucks is ok, but basically, it we are talking about traffic, I am curious to know how you consider that a VST which has a partial view of the global traffic will do a better job at distributing than the DAW.
(Again, very much agree with PAK here).

So finally, to summarise the discussion, knowing that a host is already managing the resources (CPU, memory, bandwidth and others), why do we need a more fine grained approach at the vst level?
Maybe for Diva, used as standalone to be able to run on older systems. But on general use cases?
I am not convinced at all.

[Jac459]

Multi-core processing is not necessarily gonna improve performance unfortunately. Since 2
cores share the same bus and mem, you can actually degrade performance in some situations. There are other issues
in maintaining balance and scheduling. System thread limits etc. Just to name a couple.

Absolutely

[Jac459]

Sure and if you a smart plugin that allocates each element to a different core what does your DAW see?

You could have a huge patch running in Falcon with 6 layers, your DAW is going to see a huge data stream and has to manage that.

It’ll still see the same usage. The difference is whether the host retains control or whether the plugin takes a more direct role in its own resource allocation. The issue with that is, rather than work with the host, the plugin is now competing with it directly for CPU resources, even if the host can see what it’s doing. This has implications.

EG If a single-threaded application is so CPU heavy that it will overload a single core (The obvious example would be Diva, set to 16 note poly in Divine mode), then it requires multiple cores to achieve its full polyphony. Both HALion and Diva implemented this about 13 years back, when you really couldn’t count on hosts handling things - never mind well. Many users were still on Pentium / Core 2 Duo etc.

However things have really been changing lately. What do you think such implementations know about efficiency and performance cores? Or how they should load balance in a scenario where there’s dozens of cores? If they spread things as much as they can, rather than attempt to keep things confined to less cores, now they’re taking small chunks out of many cores.

Now say you have a very single threaded plugin where one core is only just enough to contain it? You’ve now impacted your ability to run that plugin Vs a host which may attempt to load balance into less cores because it has a better awareness of the current CPU situation. BTW, in Diva’s case, I think I've seen it mentioned that the CLAP version contains changes in how some of this stuff is able to be handled, though I haven’t used it to know details and if / how this results in any performance differences.

Anyway, I think that’s enough off-topic from me for about this. Suffice to say it is a complex issue which many hosts struggle with, and the main take away is to be aware that your host may be severely limiting your performance because of these factors.

Fully agree, .... And also agree on enough off topic (for which I am very much guilty)