Simone

I could swear that there was a substantial thread a while a back on ways to improve the efficiency of ones patch (mainly in the msp realm)... I have been trying various google searches and have only come up with tips/comments regarding the efficiency of specific objects. Anyone out there share my recollection? or know where I can find this information.

Bring words and photos together (easily) with

PhotoMail - it's free and works with Yahoo! Mail.

I could swear that there was a substantial thread a while a back on ways to improve the efficiency of ones patch (mainly in the msp realm)...  I have been trying various google searches and have only come up with tips/comments regarding the efficiency of specific objects.  Anyone out there share my recollection?  or know where I can find this information.

---------------------------------
Bring words and photos together (easily) with
 PhotoMail  - it's free and works with Yahoo! Mail.


patch-efficiency

Depends what your doing with the patch really, but a good tip is to hide your hefty audio processors in patchers then plug in a mute~ to them, this will mean that when they are not in use they are not using any processing at all. Hope this helps

There was this very recent thread on using send~ & receive~ vs. using regular send & receive objects that is worth a good read-

https://cycling74.com/forums/index.php?t=msg&th=18043

 &start=0&rid=0&S=4938276267d0b11125605eef81787a1 c

The basic idea is that regular sends & receives do not add any significant overhead to your patch, whereas send~ & receive~ can. So if you've got a few hundred send~ objects in your patch, you may want to try cutting back.

No doubt there are many more threads on similar topics though..

 https://cycling74.com/forums/index.php?t=msg&th=18043 &start=0&rid=0&S=4938276267d0b11125605eef81787a1 c

The basic idea is that regular sends & receives do not add any significant overhead to your patch, whereas send~ & receive~ can. So if you've got a few hundred send~ objects in your patch, you may want to try cutting back. 

Quote: Trum wrote on Mon, 06 February 2006 22:24

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

> Depends what your doing with the patch really, but a good tip is to hide your hefty audio processors in patchers then plug in a mute~ to them, this will mean that when they are not in use they are not using any processing at all. Hope this helps

do i need to use the "selector~" with this mute~ in a sub patcher ??? Where do I exactly put the mute~ to ???

Last time when I used the selector~+mute~, it really screwed up and didn't work like it was supposed to. I'm very interested in this.

Quote: Trum wrote on Mon, 06 February 2006 22:24
----------------------------------------------------
> Depends what your doing with the patch really, but a good tip is to hide your hefty audio processors in patchers then plug in a mute~ to them, this will mean that when they are not in use they are not using any processing at all. Hope this helps
>
----------------------------------------------------

do i need to use the "selector~" with this mute~ in a sub patcher ??? Where do I exactly put the mute~ to ???
Last time when I used the selector~+mute~, it really screwed up and didn't work like it was supposed to.  I'm very interested in this.


selector~ works with begin~ to turn off and on DSP chains.

look at the mute~ helpfile and the turorials- it has an example.

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I 

You will not be saved by the Holy Ghost. You will not be saved by the 

I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I LIVE! I  
LIVE! I LIVE! I LIVE! I LIVE!

You will not be saved by the Holy Ghost. You will not be saved by the  
God Plutonium.

Hey, the help file isnt the best in the world, but all you need to do is to bury your audio processors inside the patches, and put pass~ before the audio output. Then if you connect a mute~ to the patch and turn a toggle on (or send a 1), it'll turn off any audio coming out of the patch and stop it using any processing. Can still send the audio out anywhere you like into a selector~ or whatever, but you dont need to combine mute~ and selector to stop it using up processing. Any more questions dont worry bout asking.

Hey, the help file isnt the best in the world, but all you need to do is to bury your audio processors inside the patches, and put pass~ before the audio output. Then if you connect a mute~ to the patch and turn a toggle on (or send a 1), it'll turn off any audio coming out of the patch and stop it using any processing. Can still send the audio out anywhere you like into a selector~ or whatever, but you dont need to combine mute~ and selector to stop it using up processing. Any more questions dont worry bout asking.
Tristram


Quote: vade wrote on Mon, 13 February 2006 04:50

> selector~ works with begin~ to turn off and on DSP chains.

> look at the mute~ helpfile and the turorials- it has an example.

oops, you are right. It was begin~ that went with the selector~.

Quote: vade wrote on Mon, 13 February 2006 04:50
----------------------------------------------------
> selector~ works with begin~ to turn off and on DSP chains.
>
> look at the mute~ helpfile and the turorials- it has an example.
>
> mute~ or send enable 0 -> pcontrol

thxx.
oops, you are right.  It was begin~ that went with the selector~.


Thank you so much for your kindness, Tristram

I'm still not sure whether the mute goes outside the subpatch or not.

Will post any patches if it is necessary.

I'm still not sure whether the mute goes outside the subpatch or not.
So I'll try them as soon as I get home.
Will post any patches if it is necessary.

mute~ goes outside of the subpatch, which should then 'kill' any 

mute~ goes outside of the subpatch, which should then 'kill' any  
audio processing in there

>> do i need to use the "selector~" with this mute~ in a sub patcher ???

with [selector~] you can in some situation even 

turn off a subcircuit as soon as it is started 

i never got mute~ to work the way i wanted so my 

preferred method remains making subpatchers and setting

the processing off to the stuff inside with messages

of course that can produce clicks or interrupts.

with [selector~] you can in some situation even 
turn off a subcircuit as soon as it is started 
by a [begin~]

i never got mute~ to work the way i wanted so my 
preferred method remains making subpatchers and setting
the processing off to the stuff inside with messages
to universal. :)  
of course that can produce clicks or interrupts.


Quote: Roman Thilenius wrote on Sun, 12 February 2006 19:23

> >> do i need to use the "selector~" with this mute~ in a sub patcher ???

> with [selector~] you can in some situation even 

> turn off a subcircuit as soon as it is started 

My experience is that begin~ is obsolete, and that the mute~ / pass~ method is hard to deal with, and isn't very effective.

I make a practice of encasing any processing you might want to mute inside a poly~ object, and then dealing with the mute message to thispoly~. This shuts things down much more effectively.

On thing to worry about, send~'s inside of the poly~ need to be zero-ed before you mute them.

Quote: Roman Thilenius wrote on Sun, 12 February 2006 19:23
----------------------------------------------------
>
> >> do i need to use the "selector~" with this mute~ in a sub patcher ???
>
>
> with [selector~] you can in some situation even 
> turn off a subcircuit as soon as it is started 
> by a [begin~]
>

I make a practice of encasing any processing you might want to mute inside a poly~ object, and then dealing with the mute message to thispoly~.  This shuts things down much more effectively.

Quote: simoneghetti@yahoo.co wrote on Tue, 31 January 2006 15:50

> I could swear that there was a substantial thread a while a back on ways to improve the efficiency of ones patch (mainly in the msp realm)

an idea i always try to sell to people is to downsample

specific objects or small arrays of only a few things.

if i build a compressor for example, i put objects

like avg~ or average~ into subpatchers and make them

a poly~ foo down 8, because it simply doesnt matter

for the sound quality if you run power analysis at 

5khz or at 40khz, but it saves 7/8 CPU cycles.

Quote: simoneghetti@yahoo.co wrote on Tue, 31 January 2006 15:50
----------------------------------------------------
> I could swear that there was a substantial thread a while a back on ways to improve the efficiency of ones patch (mainly in the msp realm)

an idea i always try to sell to people is to downsample
specific objects or small arrays of only a few things.

if i build a compressor for example, i put objects
like avg~ or average~ into subpatchers and make them
a poly~ foo down 8, because it simply doesnt matter
for the sound quality if you run power analysis at 
5khz or at 40khz, but it saves 7/8 CPU cycles.


"an idea i always try to sell to people is to downsample

specific objects or small arrays of only a few things."

This sounds likes what I need to do. The patch I have built attempts to emulate an analog synth and will eventually become a pluggo. it includes 2 oscillators (I am using the non aliasing objects tri~ saw~ etc. which take a little more CPU), 2 envelopes, 2 lfos, and a filter section (two biquads). I am thinking that the LFOs could be one target for downsampling as well as the envelopes. Currently the patch takes about 10% CPU... which kills my chances at making the synth usefully polyphonic. I am not using and send~ receive~ pairs... and can't think of what else to look for to make the patch more efficient.

"an idea i always try to sell to people is to downsample
specific objects or small arrays of only a few things."

This sounds likes what I need to do. The patch I have built attempts to emulate an analog synth and will eventually become a pluggo. it includes 2 oscillators (I am using the non aliasing objects tri~ saw~ etc. which take a little more CPU), 2 envelopes, 2 lfos, and a filter section (two biquads).  I am thinking that the LFOs could be one target for downsampling as well as the envelopes.  Currently the patch takes about 10% CPU... which kills my chances at making the synth usefully polyphonic.  I am not using and send~ receive~ pairs... and can't think of what else to look for to make the patch more efficient.

yeah, custom adsr and LFO is a good example, i?ve also been doing it in FM synths, or to objects like line~ and meter~

it frees up the CPU you need to upsample biquad~ and comb~ ...

it frees up the CPU you need to upsample biquad~ and comb~ ...
:)


At 6:11 AM -0700 2/15/06, Roman Thilenius wrote:

>Quote: simoneghetti@yahoo.co wrote on Tue, 31 January 2006 15:50

>----------------------------------------------------

>> I could swear that there was a substantial thread a while a back 

>>on ways to improve the efficiency of ones patch (mainly in the msp 

>an idea i always try to sell to people is to downsample

>specific objects or small arrays of only a few things.

>if i build a compressor for example, i put objects

>like avg~ or average~ into subpatchers and make them

>a poly~ foo down 8, because it simply doesnt matter

>for the sound quality if you run power analysis at

>5khz or at 40khz, but it saves 7/8 CPU cycles.

Good approach Roman - a question though; does the downsampling action 

in the poly~ eat any resources itself? I'm presuming it does, but 

perhaps less than the gains you are getting from operating at the 

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

At 6:11 AM -0700 2/15/06, Roman Thilenius wrote:
>Quote: simoneghetti@yahoo.co wrote on Tue, 31 January 2006 15:50
>----------------------------------------------------
>>  I could swear that there was a substantial thread a while a back 
>>on ways to improve the efficiency of ones patch (mainly in the msp 
>>realm)
>
>
>an idea i always try to sell to people is to downsample
>specific objects or small arrays of only a few things.
>
>if i build a compressor for example, i put objects
>like avg~ or average~ into subpatchers and make them
>a poly~ foo down 8, because it simply doesnt matter
>for the sound quality if you run power analysis at
>5khz or at 40khz, but it saves 7/8 CPU cycles.

Good approach Roman - a question though; does the downsampling action 
in the poly~ eat any resources itself?  I'm presuming it does, but 
perhaps less than the gains you are getting from operating at the 
lower sample rate...

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


Quote: Roman Thilenius wrote on Wed, 15 February 2006 09:24

> yeah, custom adsr and LFO is a good example, i?ve also been doing it in FM synths, or to objects like line~ and meter~

> it frees up the CPU you need to upsample biquad~ and comb~ ...

what sorts of things do you down sample in FM synths?

Quote: Roman Thilenius wrote on Wed, 15 February 2006 09:24
----------------------------------------------------
>
> yeah, custom adsr and LFO is a good example, i?ve also been doing it in FM synths, or to objects like line~ and meter~
>
> it frees up the CPU you need to upsample biquad~ and comb~ ...
> :)
----------------------------------------------------

would this help if I downsampled at the last end of my master-dac??

Or do i have to use this downsample-method on every adc-inputs ?? 7/8-cpu-save sounds amazing.

would this help if I downsampled at the last end of my master-dac??
Or do i have to use this downsample-method on every adc-inputs ?? 7/8-cpu-save sounds amazing.


>Good approach Roman - a question though; does the downsampling >action 

>in the poly~ eat any resources itself? I'm presuming it does, >but 

>perhaps less than the gains you are getting from operating at >the 

100 copies of [poly~ 110.polyavg~ down 8] need 12,5% of

what i worry more is the messages priority inside vs. 

outside, i have no clue about that. for smaller subpatches 

>what sorts of things do you down sample in FM synths?

the whole operator section for example, or an operator

section which is to be used as suboscillator.

it would contain phasor, cycle, kink, line, +, -, *, /,

you might want to use not less than 22 khz though.

>would this help if I downsampled at the last end of my >master-dac??

>Or do i have to use this downsample-method on every adc-inputs >?? 7/8-cpu-save sounds amazing.

adc and dac belong to the few signal objects which you 

if you want a 5.7 khz recording system you should get 

a macintosh performa 5300 with built-in headphone jack

and system 7.0; it has that samplingrate by default.

>Dan Nigrin
>Good approach Roman - a question though; does the downsampling >action 
>in the poly~ eat any resources itself? I'm presuming it does, >but 
>perhaps less than the gains you are getting from operating at >the 
>lower sample rate...

100 copies of [poly~ 110.polyavg~ down 8] need 12,5% of
what [avg~] would need.
what i worry more is the messages priority inside vs. 
outside, i have no clue about that. for smaller subpatches 
it does not really matter of course.

>simone
>what sorts of things do you down sample in FM synths?

the whole operator section for example, or an operator
section which is to be used as suboscillator.

it would contain phasor, cycle, kink, line, +, -, *, /,
delta, whatever you wish :)

>sniffio
>would this help if I downsampled at the last end of my >master-dac??
>Or do i have to use this downsample-method on every adc-inputs >?? 7/8-cpu-save sounds amazing. 

adc and dac belong to the few signal objects which you 
can not downsample.
if you want a 5.7 khz recording system you should get 
a macintosh performa 5300 with built-in headphone jack
and system 7.0; it has that samplingrate by default.


> if i build a compressor for example, i put objects

> like avg~ or average~ into subpatchers and make them

> a poly~ foo down 8, because it simply doesnt matter

> for the sound quality if you run power analysis at

> 5khz or at 40khz, but it saves 7/8 CPU cycles.

I disagree that it simply doesn't matter. Imagine you are analysing

the output of a sine wave with the frequency set to pi/4 radians (or

6k if your sampling rate is 48k) so that the period is exactly eight

samples. Your downsampling poly~ would then select a sample from this

sine wave at exactly the same place in the cycle every time. The

value of that selected sample depends on the phase of the sine wave -

it could be zero, it could be the full amplitude of the sine wave, or

it could be anything in between. So by placing your amplitude

analysis in a downsampled poly~ you have introduced a phase-dependence

into your compression algorithm, and in extreme cases the algorithm

could badly fail to properly analyze the amplitude of the incoming

> Good approach Roman - a question though; does the downsampling action

Currently the downsampling in poly~ is very cheap - it just selects

every Nth sample. Upsampling is similarly cheap.

> if i build a compressor for example, i put objects
> like avg~ or average~ into subpatchers and make them
> a poly~ foo down 8, because it simply doesnt matter
> for the sound quality if you run power analysis at
> 5khz or at 40khz, but it saves 7/8 CPU cycles.

I disagree that it simply doesn't matter.  Imagine you are analysing
the output of a sine wave with the frequency set to pi/4 radians (or
6k if your sampling rate is 48k) so that the period is exactly eight
samples.  Your downsampling poly~ would then select a sample from this
sine wave at exactly the same place in the cycle every time.  The
value of that selected sample depends on the phase of the sine wave -
it could be zero, it could be the full amplitude of the sine wave, or
it could be anything in between.  So by placing your amplitude
analysis in a downsampled poly~ you have introduced a phase-dependence
into your compression algorithm, and in extreme cases the algorithm
could badly fail to properly analyze the amplitude of the incoming
signals.

> Good approach Roman - a question though; does the downsampling action
> in the poly~ eat any resources itself?

Currently the downsampling in poly~ is very cheap - it just selects
every Nth sample.  Upsampling is similarly cheap.

Here's another way of implementing a LOT of envelope followers at once 

using vectral~. Note that it's not as useful if you want to read them 

all, as you have to do the demuxing, which would either require a lot 

of sample and holds, or a lot of sig~ + index~, but it's very efficient 

because it requires a small amount of objects. (and note that you only 

have to have one abs~ -> sqrt~ !) Depends on how much flexibility 

and resolution you need, but this is pretty good, especially if you 

want to track the envelope of a lot of signals, but only use the values 

Though not perhaps applicable here, I'd also recommend slide~. As far 

as signal-rate envelope following objects go, it's more CPU efficient 

than rampsmooth~, and scads better than average~.

Here's another way of implementing a LOT of envelope followers at once 
using vectral~.  Note that it's not as useful if you want to read them 
all, as you have to do the demuxing, which would either require a lot 
of sample and holds, or a lot of sig~ + index~, but it's very efficient 
because it requires a small amount of objects.  (and note that you only 
have to have one abs~  ->  sqrt~ !)  Depends on how much flexibility 
and resolution you need, but this is pretty good, especially if you 
want to track the envelope of a lot of signals, but only use the values 
for a few at a time.

Though not perhaps applicable here, I'd also recommend slide~.  As far 
as signal-rate envelope following objects go, it's more CPU efficient 
than rampsmooth~, and scads better than average~.

On around Feb 17, 2006, at 8:12, Ben Nevile said something like:

> I disagree that it simply doesn't matter. Imagine you are analysing

> the output of a sine wave with the frequency set to pi/4 radians (or

> 6k if your sampling rate is 48k) so that the period is exactly eight

> samples. Your downsampling poly~ would then select a sample from this

> sine wave at exactly the same place in the cycle every time.

Mathematically you're right. From an engineering perspective, you're 

talking about an extremely unlikely occurence, one that can happen with 

carefully (perversely) constructed generator signals and almost never 

If you know you have a cycle~ at pi/4 you don't normally need to take 

Downsampling a signal before passing it through average~ has the add'l 

advantage that you extend the (real) time before average~'s propensity 

You're absolutely right that people should be aware of the traps 

involved in downsampling. It ain't a cure for all ills. But it can be 

> Currently the downsampling in poly~ is very cheap - it just selects

> every Nth sample. Upsampling is similarly cheap.

This is good to know. Is upsampling linear interp, or are you just 

| Litter Power & Litter Bundle for Jitter

pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building

http://www.dspaudio.com/software/software.html

On around Feb 17, 2006, at 8:12, Ben Nevile said something like:
> I disagree that it simply doesn't matter.  Imagine you are analysing
> the output of a sine wave with the frequency set to pi/4 radians (or
> 6k if your sampling rate is 48k) so that the period is exactly eight
> samples.  Your downsampling poly~ would then select a sample from this
> sine wave at exactly the same place in the cycle every time.

Mathematically you're right. From an engineering perspective, you're 
talking about an extremely unlikely occurence, one that can happen with 
carefully (perversely) constructed generator signals and almost never 
with real world signals.

If you know you have a cycle~ at pi/4 you don't normally need to take 
its average~ .-)

Downsampling a signal before passing it through average~ has the add'l 
advantage that you extend the (real) time before average~'s propensity 
to cumulate errors becomes an problem.

You're absolutely right that people should be aware of the traps 
involved in downsampling. It ain't a cure for all ills. But it can be 
very useful.

> Currently the downsampling in poly~ is very cheap - it just selects
> every Nth sample.  Upsampling is similarly cheap.

This is good to know. Is upsampling linear interp, or are you just 
repeating samples?

>> Good approach Roman - a question though; does the downsampling action

>> in the poly~ eat any resources itself?

>Currently the downsampling in poly~ is very cheap - it just selects

>every Nth sample. Upsampling is similarly cheap.

thanks Ben, good to know what I presumed is in fact correct.

patch efficiency