personal_username

Following discussions I read here i tried to do some tests to discover how much CPU does poly~ save on an audio-related patch.

I did a couple of test with a simple vst~ object which is / or is not inside a poly~.

Then a simple metro 100 + makenote + long notes would do the rest.

What I discovered is somehow obscure and what I found (discalimer: spolier alert!) is that without poly~ my patch works more efficiently!

I'm attaching both patches for you to see.

1.zip is plain simple one; 2.zip has a poly~ with 3 instances of the same vst~.

1) how come is the poly less efficient than the implementation without it?

I read that from the second instance on, poly does allocate horsepower on the other cores (with message parallel 1)

But what i see is that with (parallel 1) it actually requires more CPU!

2) the only situation in which poly is as efficient as the patch without poly is when I do not *prepend note* on it.

If my understanding is right this would only use one instance, thus delivering no poly~ at all. Hence using roughly the same CPU as the other method.

3) I discovered another downside of allocating a vst~ inside a poly, namely RAM usage.

Plugging a sampler like Kontakt to a vst~ inside a poly~ can get you some panic alert if you go too far with instances, because you will literally drain all your RAM caveau.

4) Am I getting anything wrong? Please, let me know what you think, any voice would be greatly appreciated! ;-)

Following discussions I read here i tried to do some tests to discover how much CPU does poly~ save on an audio-related patch.
I did a couple of test with a simple vst~ object which is / or is not inside a poly~.
Then a simple metro 100 + makenote + long notes would do the rest.

I'm attaching both patches for you to see.
1.zip is plain simple one; 2.zip has a poly~ with 3 instances of the same vst~.

1) how come is the poly less efficient than the implementation without it?
I read that from the second instance on, poly does allocate horsepower on the other cores (with message parallel 1)
But what i see is that with (parallel 1) it actually requires more CPU!

2) the only situation in which poly is as efficient as the patch without poly is when I do not *prepend note* on it.
If my understanding is right this would only use one instance, thus delivering no poly~ at all. Hence using roughly the same CPU as the other method. 

3) I discovered another downside of allocating a vst~ inside a poly, namely RAM usage.
Plugging a sampler like Kontakt to a vst~ inside a poly~ can get you some panic alert if you go too far with instances, because you will literally drain all your RAM caveau.

strange-finding-with-poly

I've been considering running a bunch of vsts from within poly to distribute them among cores, so if this does not work, I'd like to know about it.

How were you measuring cpu? Did you look at individual cores? Did the poly object seem to distribute load, or merely increase it?

In a related question (for me) I'm wondering if I put multiple instances of vsts in top level patchers (can they all be opened with one command via the new workspace concept? I'm still trying to figure that out) will they get their own memory spaces as well? Then I probably wouldn't need to run 64-bit, which means I could use externals that haven't been ported to 64 bit. Of course, the externals that I'm most missing right now are the CNMAT poly ones, which wouldn't matter if I wasn't using poly :/

Still if the top-level patches each get a core and a memory space, that seems like a good tradeoff. If you can use javascript to open multiple identical objects (can I do this for top-level patches? I'm not sure that's possible....) it seems like you don't really need poly unless you want to dynamically allocate midi voices.

Unless, of course, it actually saves CPU.

How were you measuring cpu?  Did you look at individual cores?  Did the poly object seem to distribute load, or merely increase it?

In a related question (for me) I'm wondering if I put multiple instances of vsts in top level patchers (can they all be opened with one command via the new workspace concept?  I'm still trying to figure that out) will they get their own memory spaces as well?  Then I probably wouldn't need to run 64-bit, which means I could use externals that haven't been ported to 64 bit.  Of course, the externals that I'm most missing right now are the CNMAT poly ones, which wouldn't matter if I wasn't using poly :/

Still if the top-level patches each get a core and a memory space, that seems like a good tradeoff.  If you can use javascript to open multiple identical objects (can I do this for top-level patches?  I'm not sure that's possible....) it seems like you don't really need poly unless you want to dynamically allocate midi voices.  

The "parallel" feature of poly~ has been a great deception for me but maybe my expectation were too high: I hoped it could help to distribute power use on cores for single-voice poly~.

My latest solution for that matter is to run two instances of Max simultaneously and connect them through hardware (one instance sends two channels on two analog outputs and these outputs go back to two inputs on the same soundcard, feeding the second instance of Max). This solution has the advantage to allow different values for audio and scheduler settings on each instance, such as signal vector size.

The second instance is mostly used to run a vst~ reverberation.

I suppose one could run more instances (there are so many connections on current soundcards...)

One could also achieve this with Jack Router but I suspect this would be a bit more unstable and would introduce more latency.

My latest solution for that matter is to run two instances of Max simultaneously and connect them through hardware (one instance sends two channels on two analog outputs and these outputs go back to two inputs on the same soundcard, feeding the second instance of Max). This solution has the advantage to allow different values for audio and scheduler settings on each instance, such as signal vector size. 

One could also achieve this with Jack Router but I suspect this would be a bit more unstable and would introduce more latency.


Oh, I never expected a poly of 1 to get distributed among cores. But higher numbers of voices will reliably do so? I'm currently running 13 vsts (5 kontakt, 5 Reaktor, 2 Massive and 2 gtr rig) on the same machine using another host, and that works reliably at 256 samples. I would hope in porting it to Max I could get similar results. It seems to me if you made a poly vst host patch, like I'm thinking of doing, you could run the reverb on a different voice and save all that inter-app stuff. There's a forum post about someone doing that sort of thing....

Oh, I never expected a poly of 1 to get distributed among cores.  But higher numbers of voices will reliably do so?   I'm currently running 13 vsts (5 kontakt, 5 Reaktor, 2 Massive and 2 gtr rig) on the same machine using another host, and that works reliably at 256 samples.  I would hope in porting it to Max I could get similar results.  It seems to me if you made a poly vst host patch, like I'm thinking of doing, you could run the reverb on a different voice and save all that inter-app stuff.  There's a forum post about someone doing that sort of thing....


I posted my VST hosting patcher sussystrm a few months ago and that design allows you to quite easily create and allocate VSTs in any combination you like (e.g., 1 VsT per poly~, 3 VSTs in one poly~ and 5 VSTs in another poly~ and so forth). There are also abstractions so you can route audio through multiple VSTs regardless of in which poly~ each one lives.

Just wondering if that approach might be helpful.

https://cycling74.com/forums/easy-way-to-createedituse-vsts-in-return-can-you-help-me-reproduce-bugs/

I posted my VST hosting patcher sussystrm a few months ago and that design allows you to quite easily create and allocate VSTs in any combination you like (e.g., 1 VsT per poly~, 3 VSTs in one poly~ and 5 VSTs in another poly~ and so forth). There are also abstractions so you can route audio through multiple VSTs regardless of in which poly~ each one lives.
Just wondering if that approach might be helpful.

https://cycling74.com/forums/easy-way-to-createedituse-vsts-in-return-can-you-help-me-reproduce-bugs/


I'm going to check this out. I'm looking to port my setup from another host, now that Max's subscription model will allow me to see if it's all going to work without shelling out all the $$ up front.

Did you ever get your crash problem figured out? It looks like your patch was running under 32-bit, (the version of quebec you included seems to be 32 bit only?) so I'm wondering if you were running out of memory. Maybe the slightly larger footprint of max 6 was enough to push it over the edge. That's was a problem for me in the past running multiple vsts in a modular hosting environment until my host (usine) moved to 64 bit.

I'm assuming that while poly gives you separate threads, it's not going to give you multiple memory spaces ;)

I'm going to check this out.  I'm looking to port my setup from another host, now that Max's subscription model will allow me to see if it's all going to work without shelling out all the $$ up front.  

Did you ever get your crash problem figured out?  It looks like your patch was running under 32-bit, (the version of quebec you included seems to be 32 bit only?) so I'm wondering if you were running out of memory.  Maybe the slightly larger footprint of max 6 was enough to push it over the edge.  That's was a problem for me in the past running multiple vsts in a modular hosting environment until my host (usine) moved to 64 bit.

I'm assuming that while poly gives you separate threads, it's not going to give you multiple memory spaces ;)


No --- for a start I don't think too many people even tried it. The couple of people I know did try it were not able to crash it and Cycling74 support hasn't been able to crash it. This suggests that the problem has to be my machine but I've been able to make it crash on three very differently configured systems so I don't even know how to proceed. I doubt very much it's a RAM problem ---- crashing is completely intermittent and seems to be related to loading (or unloading) VSTs. When the problem happens, there can be just one VST loaded and I've made it happen with a trivial patcher.

By the way, one of the (successful) goals of this system is to support dynamic muting so as to reduce CPU cycle usage. The idea is to be able to have a lot of VSTs loaded but if they're not being used at particular times, the containing poly will automatically mute. Makes it feasible to have a lot of VSTs available for a single song.

I'm not surprised that few people have tried your patch. I do NOT get the sense many people are using Max as a VST host, beyond maybe sticking a reverb on the output.

I have no idea how difficult it would be to recompile quebec for 64 bit windows.... I'm not versed in C. What do you use it for? Do you know if ejies would work for your purposes?

I'm not surprised that few people have tried your patch.  I do NOT get the sense many people are using Max as a VST host, beyond maybe sticking a reverb on the output.

I have no idea how difficult it would be to recompile quebec for 64 bit windows.... I'm not versed in C.  What do you use it for?  Do you know if ejies would work for your purposes?


Hey, I am back to the forum just now and i find this old topic quite active after a month of lethargy ;-)

On the go right now, but tomorrow will follow-up the discussion!

I'm still trying to optimize the vst section of my patch, so maybe we'll figure out something

Hey, I am back to the forum just now and i find this old topic quite active after a month of lethargy ;-)
On the go right now, but tomorrow will follow-up the discussion!
I'm still trying to optimize the vst section of my patch, so maybe we'll figure out something
Ciao!


Quecbec is just used to set the color of an abstraction automatically. That turned out to be useful to highlight certain objects if MIDI was enabled in them or to make certain abstractions always have the same color. In my larger system, for example, all MIDI sources (I'm not talking about raw [midiin] stuff) are green (when enabled)' all VST targets are red (when enabled) and transformers such as transpose operators, keyboard splits, velocity modifiers and so forth are cyan.

It's not necessary to use it at all if you just want to use the VST system...I probably should have removed it but I forgot.

As for few people trying it, the reason I was surprised was because I've seen many (often unanswered) questions about how to use VSTs, poly~ together in the past

As for me I was looking at global memory used by max on activity report.

And as said poly~ did seem to increase or not decrease at all (depending on note handling’s methods) CPU load.

In my tests it was running on more instancies of poly, with parallel enabled.

And again, no CPU advantage, quite the opposite.

So, looks like that under these conditions (vst~ with Kontakt loaded) poly~ *may* not be the way to go. More downsides than “Yahoos”.

ok, a few answers.
As for me I was looking at global memory used by max on activity report.
And as said poly~ did seem to increase or not decrease at all (depending on note handling’s methods) CPU load.

In my tests it was running on more instancies of poly, with parallel enabled.
And again, no CPU advantage, quite the opposite.

So, looks like that under these conditions (vst~ with Kontakt loaded) poly~ *may* not be the way to go. More downsides than “Yahoos”.
(I Hope to be wrong, btw)


Strange finding with Poly~