Dan Nigrin

I have a patcher that is used many times in my application - the relevant part is reproduced below. My problem is that the CPU consumption of my patch is huge, probably because I'm sending zero signals through all of the gate~ outlets that are closed.

I was thinking about putting each send~ in it's own poly~, and then sending "mute 1" or "mute 0" messages to each one when the gate switches it off/on... Is that the best approach?

[img]index.php?t=getfile&id=776&private=0[/img]

I have a patcher that is used many times in my application - the relevant part is reproduced below.  My problem is that the CPU consumption of my patch is huge, probably because I'm sending zero signals through all of the gate~ outlets that are closed.

saving-cpu-with-poly

Quote: Dan Nigrin wrote on Wed, 01 August 2007 04:41

----------------------------------------------------

> I have a patcher that is used many times in my application - the relevant part is reproduced below. My problem is that the CPU consumption of my patch is huge, probably because I'm sending zero signals through all of the gate~ outlets that are closed.

> I was thinking about putting each send~ in it's own poly~, and then sending "mute 1" or "mute 0" messages to each one when the gate switches it off/on... Is that the best approach?

It's been a while since I ran these experiments, so YMMV.

One idea: when doing a 14 channel piece with much poly~ use, I found that scripting the patch cords I need (and not the ones I don't) saved me a lot of overhead. That might not fit your situation.

Second idea: I found that manging signal routing with matrix~ was pretty efficient... probably more so than a number of small gate~'s.

A comment: make sure you "zero" any sends before you mute them. If I recall, send~ holds the last signal vector it has gotten when it gets muted.

Quote: Dan Nigrin wrote on Wed, 01 August 2007 04:41
----------------------------------------------------
> I have a patcher that is used many times in my application - the relevant part is reproduced below.  My problem is that the CPU consumption of my patch is huge, probably because I'm sending zero signals through all of the gate~ outlets that are closed.
>
> I was thinking about putting each send~ in it's own poly~, and then sending "mute 1" or "mute 0" messages to each one when the gate switches it off/on... Is that the best approach?
>

One idea: when doing a 14 channel piece with much poly~ use, I found that scripting the patch cords I need (and not the ones I don't) saved me a lot of overhead.  That might not fit your situation.

A comment: make sure you "zero" any sends before you mute them.  If I recall, send~ holds the last signal vector it has gotten when it gets muted.

In my application, the signal connections (basically, the input into 

the gate~) is changing very frequently (on the order of tens to 

hundreds of milliseconds), so I'm not sure if the scripting approach 

>One idea: when doing a 14 channel piece with much poly~ use, I found 

>that scripting the patch cords I need (and not the ones I don't) 

>saved me a lot of overhead. That might not fit your situation.

>Second idea: I found that manging signal routing with matrix~ was 

>pretty efficient... probably more so than a number of small gate~'s.

>A comment: make sure you "zero" any sends before you mute them. If 

>I recall, send~ holds the last signal vector it has gotten when it 

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 

In my application, the signal connections (basically, the input into 
the gate~) is changing very frequently (on the order of tens to 
hundreds of milliseconds), so I'm not sure if the scripting approach 
will work...

>One idea: when doing a 14 channel piece with much poly~ use, I found 
>that scripting the patch cords I need (and not the ones I don't) 
>saved me a lot of overhead.  That might not fit your situation.
>
>Second idea: I found that manging signal routing with matrix~ was 
>pretty efficient... probably more so than a number of small gate~'s.
>
>A comment: make sure you "zero" any sends before you mute them.  If 
>I recall, send~ holds the last signal vector it has gotten when it 
>gets muted.

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X / Major 
Malfunction
http://www.defectiverecords.com
http://www.jackosx.com


I have had excellent results using poly~ to curb CPU-usage. Just put each block of DSP that can be turned on and off as a unit into a 1-voice poly~ and then organize your DSP economy in the main patch, such that every poly~ subpatch is only turned on when you need it. I recommend to avoid using send~/receive~ inside of poly~ to communicate with the outside world, as this can introduce noticeable timing discrepancies. Best to use in~ and out~ instead.

Thanks Eric - that was my original inclination, and I will give it a 

try. Also thanks re: the send~ inside the poly~ - I'll be sure to 

get the audio out of the poly~ first with out~, then send~ after that.

>I have had excellent results using poly~ to curb CPU-usage. Just put 

>each block of DSP that can be turned on and off as a unit into a 

>1-voice poly~ and then organize your DSP economy in the main patch, 

>such that every poly~ subpatch is only turned on when you need it. I 

>recommend to avoid using send~/receive~ inside of poly~ to 

>communicate with the outside world, as this can introduce noticeable 

>timing discrepancies. Best to use in~ and out~ instead.

Thanks Eric - that was my original inclination, and I will give it a 
try.  Also thanks re: the send~ inside the poly~ - I'll be sure to 
get the audio out of the poly~ first with out~, then send~ after that.

>I have had excellent results using poly~ to curb CPU-usage. Just put 
>each block of DSP that can be turned on and off as a unit into a 
>1-voice poly~ and then organize your DSP economy in the main patch, 
>such that every poly~ subpatch is only turned on when you need it. I 
>recommend to avoid using send~/receive~ inside of poly~ to 
>communicate with the outside world, as this can introduce noticeable 
>timing discrepancies. Best to use in~ and out~ instead.
>

> One idea: when doing a 14 channel piece with much poly~ use, I found

> that scripting the patch cords I need (and not the ones I don't)

> saved me a lot of overhead. That might not fit your situation.

Each time you script audio patch cords, audio will be switched off/on, 

which will lead to sound interuption/clicks if your patch is big.

> Second idea: I found that manging signal routing with matrix~ was

> pretty efficient... probably more so than a number of small gate~'s.

In the example code, there are send~ objects. If you don't create 

feedback, you could replace them with send/receive (no tilde~). Would be 

mzed schrieb:
> One idea: when doing a 14 channel piece with much poly~ use, I found
> that scripting the patch cords I need (and not the ones I don't)
> saved me a lot of overhead.  That might not fit your situation.

Each time you script audio patch cords, audio will be switched off/on, 
which will lead to sound interuption/clicks if your patch is big.
A very bad idea...

> Second idea: I found that manging signal routing with matrix~ was
> pretty efficient... probably more so than a number of small gate~'s.

In the example code, there are send~ objects. If you don't create 
feedback, you could replace them with send/receive (no tilde~). Would be 
a little bit more effective as well...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


always try the secret 110 method first, which is codenamed

"turning the cable off to turn the connected object off".

always try the secret 110 method first, which is codenamed
"turning the cable off to turn the connected object off".

Quote: Stefan Tiedje wrote on Tue, 07 August 2007 01:28

> In the example code, there are send~ objects. If you don't create 

> feedback, you could replace them with send/receive (no tilde~). Would be 

Thanks Stefan - but I got into trouble with using just plain send/receive's in this patch already (see this thread: 

https://cycling74.com/forums/index.php?t=msg&goto=111611

 ), so I have reverted to using the ~ versions...

Quote: Stefan Tiedje wrote on Tue, 07 August 2007 01:28
----------------------------------------------------
> In the example code, there are send~ objects. If you don't create 
> feedback, you could replace them with send/receive (no tilde~). Would be 
> a little bit more effective as well...

Thanks Stefan - but I got into trouble with using just plain send/receive's in this patch already (see this thread: https://cycling74.com/forums/index.php?t=msg&goto=111611 ), so I have reverted to using the ~ versions...

What I ended up doing though was rethinking my routing, and I got 

much more efficient using matrix~ as Michael had suggested earlier in 

the thread. Still, this is a good trick for future use!

At 2:03 AM -0600 8/7/07, Roman Thilenius wrote:

>always try the secret 100 method first, which is codenamed

>"turning the cable off to turn the connected object off".

What I ended up doing though was rethinking my routing, and I got 
much more efficient using matrix~ as Michael had suggested earlier in 
the thread.  Still, this is a good trick for future use!

At 2:03 AM -0600 8/7/07, Roman Thilenius wrote:
>hi guys,
>
>always try the secret 100 method first, which is codenamed
>"turning the cable off to turn the connected object off".
>
>p.s. i havent tried it with send~ yet.

Quote: Stefan Tiedje wrote on Mon, 06 August 2007 22:28

> > One idea: when doing a 14 channel piece with much poly~ use, I found

> > that scripting the patch cords I need (and not the ones I don't)

> > saved me a lot of overhead. That might not fit your situation.

> Each time you script audio patch cords, audio will be switched off/on, 

> which will lead to sound interuption/clicks if your patch is big.

I script them at startup, not while audio is on. A very good idea!

Quote: Stefan Tiedje wrote on Mon, 06 August 2007 22:28
----------------------------------------------------
> mzed schrieb:
> > One idea: when doing a 14 channel piece with much poly~ use, I found
> > that scripting the patch cords I need (and not the ones I don't)
> > saved me a lot of overhead.  That might not fit your situation.
>
> Each time you script audio patch cords, audio will be switched off/on, 
> which will lead to sound interuption/clicks if your patch is big.
> A very bad idea...
>

I script them at startup, not while audio is on.  A very good idea!

saving CPU with poly~