How to have less cpu usage with my patch

[joffo78]

Hi everyboby.
As you know i work on a big patch to make sound perform for dance and theatre.
as mesure to develop and create new functionnality it become loud for my cpu .
however compared to ableton live i do the same type of treatments not more.
why does it take so much ressources ?
I test it on to computer
first a toshiba with core 2 duo T8; it work but the cpu is over 50%
second a tablet pc HP tx 2870ef : the cpu is over 70% but i have a lot of clipping and cut.
do you know if i can optimise the patch ( for example replacing all the wires to similar input with a send bus or changing all the "architecture") ?

[joffo78]

I think i won 20% cpu usage putting all my patch in a sub patch !
good to know if it's true

[gurulogic]

I'm not so sure that splitting a patch into more small patches should save cpu, but it is usually a better way to work in Usine.
If you don't use all parts of your patch at once you could use the patch active module to disable any sub patches that are not immediately in use. Also if you have any many pieces that do the same thing maybe you can find a way to unify the function?

[senso]

Usine modularity has a cost in CPU. You can't compare to Ableton-Live where all is fixed.

Normally a sub patch take a little more than a normal patch but unused subpatches can easily disabled.

[joffo78]

Yes is that i did.
but it wasn't so easy because a patch begun inactive can't be answer when you need it.
what do you heard by "where all is fixed " ?

[23fx23]

i guess all is fixed mean a track or any item in ableton is locked to it's specialized function and don't have N parameters inputs/outputs, not as modular as usine. the sideffect it cost more ram/cpu, for an "equivalent", but the interest of usine is allowing much deeper control..

the trick is usually subpatch independantly some sub parts and tracking when do they need to be actives,
it's often when some inputs have changed, so can use a "has chgd" linked to the patch active.
also can use the mouse down object to active a subpatch only if you are tweaking with mouse.
if get some pb usually need to make active for a longer time and with stategic triggerz, can use a ramp that swich on the patch for ie 1s, then disable it, when you clic, or every 100ms,.ect
try to reduce multiple single operations that could be grouped, ie using arrays.
and more complex but using iml or/and script to set directly the values intead of wires can highly reduce cpu in some cases.
also increasing bloc size induces more latency but reduces cpu, as well as refresh speed in global setup.

[joffo78]

Hello and thank you for your advices.
The one that interest me the more is about array.
In my patch (perform seq in the addons page) i can't see when i can use there.
if (when you get time) you want to see my work to say me if i could use there your welcome !
I'm not sure someone could understand my patch but who knows !

[23fx23]

well i opened your patch, it indeed a big town hehe. a big heavy patch! lot of great work here. hard to swich off patchs as quasi all have audio.
but there are certainly parts where you could reduce b of wires or maye get rid of some passifcgh if not needed.
as example you got a hi nb of "count ms", and you generally don't need all output infos, just a trigger, so could replace top by botto:.


try to think every little optimisation is repercuted when using lot of instances . x20 it can make somedifferences.

but for me this is normal with this kind of patch and can't be compared with ableton. for example each single supatch that diplay time in ms,s ect we ve done is quite hard wired for a simple timer, think it's cool to have lot of options but sometimes better save cpu for stable performances, know it's hard... It's so easy in usine to subpatch and create complex biger patch in a bigger city, but don't expect a full chosen options sampler as the one we usually build to be as low cpu as a dedicaced hardcoded one, ie
kontakt/ableton, so it's all in the options/performances ratio. Audio Wires are cpu consumming, if can reduce the audio transports/operations, will gain more than reducing all "data" subpatchs. The players are very nice but cost too much cpu.
I would repick one, make a clone, try to reduce cpu, compare, when ok reclone it.

note sometimes it's not good to subpatch too much. A bigg Array or audio wire going in a subpatch and again in a subpatch ect
cost more than a direct wire. worth subpatching if plan to use the swich off patch feature, and be more clear, but this cost more cpu, not less.

didn't have really time to study all, maybe can't be much optimized with arrays, but
as an example all the complex timers could be replaced by a script that would computes all results strings, only when input changes. probably not so high cpu reducing but this applies for many things.,

try to track every subpatch if they can't be reduced in nb of wire as msexemple. also feel there are lot of eventflow, probably most are needed, but if can get rid of some, this uses cpu. also find a way to swich off all the audio chain when a device is not used.

[joffo78]

Ok 23fx23 Thank you for your explainations.
Peharps you right about reducing the number of option but i don't want make any concessions about what can i do with my patch !
i'd like to make a script to replace a lot of functions like timers but i tried to understand how there is working with the manual "usine_scripting_tutorial". But it's very very hard for me. I don't know nothing about programming.
could you give me an exemple of script (like get the time of my sample and display it in min,sec) ?
i made a lot of progress but i feel that i touch my limits with learning alone !

[23fx23]

Well in fact im not sure it will use less cpu, but here is the script, note im not a master too so it might be better ways of doing.
for me it seems it will uses cpu if direct linked, cause it computes each time position has changed, wich is very, very often, not to say always, so put a 'trunc' after pos of sampler before entering the script to reduce the refresh speed, but maybe patching is lower cpu, have to compare, at least got much less wiring,and you can tweak a bit...

///////////////////////////////////////////////////////////////////////////////////////
//Converts sampler position to HH: MN : Sec : Ms.
///////////////////////////////////////////////////////////////////////////////////////
VAR pTimeOut, pPos, pDur : tParameter; // parameters (in-ouputs declaration)
VAR Msin, Ms, Sec, Min, Hr : Integer; // Variables
VAR Pos, Dur : Single;
VAR StHr, StMs, StSec, StMin : string;

PROCEDURE Init;
BEGIN

pPos := CreateParam('Position', ptDataField); SetIsOutput(pPos, FALSE); //creation of in-outs
pDur := CreateParam('Len ms', ptDataField); SetIsOutput(pDur, FALSE);
pTimeOut := CreateParam('Time', ptTextfield); SetIsInput(pTimeOut, FALSE);
END; // Init


PROCEDURE Callback(n : Integer);
BEGIN
IF n = 0 then Begin // if input 0 has chg (position)
Pos:= GetValue(pPos); // assign the variables from input
Dur:= GetValue(pDur);

Msin:= round((Pos*Dur)/100); // math equivalent of the patch converts duration and pos to ms

Sec:= (Msin div 1000) mod 60; // ms to second
StSec:= IntToStr(Sec); // convert nb to string
if Sec < 10 then
StSec:= '0'+IntToStr(Sec); // add 0 before if <10

Min:= (Msin div 60000) mod 60;
StMin:= IntToStr(min);
if Min < 10 then
StMin:= '0'+IntToStr(min);

Hr:= (Msin div 3600000) mod 24;
StHr:= IntToStr(hr);
if Hr < 10 then
StHr:= '0'+IntToStr(hr);

Ms:= Msin mod 1000;
StMs:= IntToStr(Ms);
if Ms < 10 then
StMs:= '0'+IntToStr(Ms);
if Ms < 100 then
StMs:= '0'+IntToStr(Ms);

SetStringValue(pTimeOut, StHr + ':' + StMin + ':' + StSec + ':' + StMs); // set out string with all strings separated by points


END; // Callback
end;

[joffo78]

Thank you very much for your job. I'll try to learn your method not only apply it.
the unity that i use after second is not Ms but Fps (frame per second) like video post production (25frames by second).
does it means i have to change Ms:= Msin mod 40; by
Ms:= Msin (Msin div 40) mod 10
it's look working but i lost my remain option

[23fx23]

mm shouldn't it be ms:=(Msin div 40) mod 25 as it can display up to 24 and not 9?

for the remain mode you can try to make your hand recreate a ptparameter swich "ptswich". called mode.
and add something like
if GetValue(PMode):= 1 then
Msin:= GetValue(Pdur) - Msin
else
Msin:= Msin;
the line after Msin:= round....

[joffo78]

Sorry i try to do that but when i compil it give me :
"then" expected but ":=" found
Line 27 : if GetValue(PMode):= 1 then

[bsork]

A typical programming typo: The semi-colon shouldn't be there:
[c]
IF GetValue(PMode) = 1 THEN
...
[/c]

[senso]

for info, the 5.15 will be 20% faster.

[joffo78]

Hi Olivier
What a great new !
How it's possible ?

[senso]

with reprogramming of few strategic part of the main engine.

[joffo78]

I'm hurry to compare with my big patch !

[23fx23]

yup that's a great news cool!

[joffo78]

23fx23 please i'm sinking with your script !
i don't manage to make the good synthax for my remaining time

[loveandelectrik]

awesome news about the upcoming update,,
my current workspace takes about a minute to add a module or wire something,, lots of cpu usage and this is only for a midi control surface, one thing that helps me with v5.13 is the ability of changing process priority from task manager,,
can now use my setup without needing to crank up the buffer now,, (thanks senso!)
any eta on when we can expect this upcoming version?

[gurulogic]

loveandelectrik,
it sounds to me that if it is taking a minute to add a module or a wire you need to upgrade to Usine Pro, or spread your patch over more tracks. The problem is that when any patch gets too big without breaking it into sub patches, every time you create a wire or add a module, the entire patch is being stored for undo.This can get quite slow. When you work with a sup patch, only the contents of the sub patch are stored for undo when you do an action.

[senso]

@loveandelectrik
the V5.15 will be out this week but will not solve your pb.
the gurulogic suggestion is the solution.

[loveandelectrik]

awesome,, didnt think of spreading it out over tracks,,problem gone, still excited about 5.15 regardless