personal_username

these days i'm trying to clean-up my big patch, and since it takes a while to load due to the big number or repetitive patchers, I'm trying to see if substituting those with a poly~ might make sense at all.

To be clear, those patchers are not carrying any signal. With this redesign I just want the patch to load quicker, I'm not looking to save CPU cycles.

I was nonetheless expecting to see a major advantage to that method (since i guess poly can be very flexible).

To my surprise patch with [poly~ mytest 500] opened just a *very* little earlier than the patch with 500 of the same subpatchers. Talking about not more than a ~10% speed gain.

Any considerations, tips, resource I can look into to optimize it a bit more?

these days i'm trying to clean-up my big patch, and since it takes a while to load due to the big number or repetitive patchers, I'm trying to see if substituting those with a poly~ might make sense at all. 

To be clear, those patchers are not carrying any signal. With this redesign I just want the patch to load quicker, I'm not looking to save CPU cycles. 

I was nonetheless expecting to see a major advantage to that method  (since i guess poly can be very flexible).

Any considerations, tips, resource I can look into to optimize it a bit more?
Thanks!

Hi guys ,
these days i'm trying to clean-up my big patch, and since it takes a while to load due to the big number or repetitive patchers, I

multiple-patchers-vs-one-poly~

hm i guess it really depends on the patch. there could be a way you make each mytest patch more efficient and whatever gain you get from this should be 500 fold.

a poly will also load (or copy) all instances of the patch, one by one.

a poly will also load (or copy)  all instances of the patch, one by one.

do you know for sure that it is not quicker? it is obvious that it loads the patches in that fashion but compared to having the patches embedded in the main patch via some other method i'd be curious to know if it was actually slightly better, even if op doesn't notice much difference.

how long is the load time? there's a chance something in each of the patches is taking up too much time that could be expressed in a more efficient fashion

do you know for sure that it is not quicker? it is obvious that it loads the patches in that fashion but compared to having the patches embedded in the main patch via some other method i'd be curious to know if it was actually slightly better, even if op doesn't notice much difference. 

how long is the load time? there's a chance something in each of the patches is taking up too much time that could be expressed in a more efficient fashion 

@kparagraphic the patch is quite big, and i have a few externals and abstractions, so might be a nightmare to post.

Anyway, in my experience poly~ was indeed quicker, but not by far.

Actually I came out with an idea which i like, but not sure how feasible and solid.

It's about a dynamic association of inputs and target voice (using poly~, again).

The cool thing is that since I don't need *at once* all the subpatchers/poly, I might load less voices into poly~, thus resulting in a decidedly quicker loading time.

I will post another on a new topic, since it is not coherent with this post name.

@kparagraphic the patch is quite big, and i have a few externals and abstractions, so might be a nightmare to post. 

Anyway, in my experience poly~ was indeed quicker, but not by far.

Actually I came out with an idea which i like, but not sure how feasible and solid.
It's about a dynamic association of inputs and target voice (using poly~, again).

The cool thing is that since I don't need *at once* all the subpatchers/poly, I might load less voices into poly~, thus resulting in a decidedly quicker loading time.
 
I will post another on a new topic, since it is not coherent with this post name.

Multiple patchers vs one poly~