Forums > MaxMSP

patch efficiency

January 31, 2006 | 10:50 pm

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.

Thank you,

sg

———————————
Bring words and photos together (easily) with
PhotoMail – it’s free and works with Yahoo! Mail.


February 6, 2006 | 1:24 pm

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


February 6, 2006 | 11:36 pm

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

http://www.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..

- DL


February 12, 2006 | 7:16 pm

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.


February 12, 2006 | 7:50 pm

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

v a d e //

http://www.vade.info
abstrakt.vade.info

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.

In fact, YOU WILL NOT BE SAVED!


February 12, 2006 | 9:15 pm

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


February 12, 2006 | 9:26 pm

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~.


February 12, 2006 | 9:30 pm

@Tristram

Thank you so much for your kindness, Tristram

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.

again, thank you.

snif


February 12, 2006 | 9:46 pm

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

v a d e //

http://www.vade.info
abstrakt.vade.info

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.

In fact, YOU WILL NOT BE SAVED!


February 12, 2006 | 9:52 pm

thx for the tip, vade.
will do.


February 13, 2006 | 3:23 am

>> 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 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.


February 14, 2006 | 8:46 pm

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~]
>

—————————————————-

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.

mzed


February 15, 2006 | 1:11 pm

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.


February 15, 2006 | 3:07 pm

"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.

sg


February 15, 2006 | 4:24 pm

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~ …
:)


February 15, 2006 | 4:39 pm

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


February 15, 2006 | 4:58 pm

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?

sg


February 15, 2006 | 11:34 pm

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.


February 17, 2006 | 6:24 am

>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 :)

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

>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.


February 17, 2006 | 7:12 am

Hi Roman,

> 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.

Hi Dan,

> 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.

Ben


February 17, 2006 | 7:29 am

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~.

max v2;
#N vpatcher 30 89 767 785;
#P window setfont "Sans Serif" 9.;
#P number 406 295 35 9 1 8 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 406 322 38 196617 sig~ 2;
#P user scope~ 406 395 536 525 2 3 128 -1. 1. 0 0. 0 0. 102 255 51 135
135 135 0;
#P newex 406 345 57 196617 index~ foo;
#P newex 326 147 78 196617 loadmess 4000;
#P number 270 295 35 9 1 8 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 79 281 35 196617 sqrt~;
#P newex 79 258 31 196617 abs~;
#P number 373 188 35 9 1 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 326 188 35 9 1 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 279 204 15 0;
#P newex 279 221 104 196617 pack rampsmooth 1 1;
#P newex 270 322 38 196617 sig~ 1;
#P user scope~ 270 395 400 525 2 3 128 -1. 1. 0 0. 0 0. 102 255 51 135
135 135 0;
#P newex 270 345 57 196617 index~ foo;
#P message 253 67 73 196617 sizeinsamps 8;
#P newex 253 93 61 196617 buffer~ foo;
#P newex 34 349 53 196617 poke~ foo;
#P user ezdac~ 55 412 99 445 0;
#P newex 80 55 76 196617 count~ 1 8 1 1;
#P newex 80 238 119 196617 selector~ 8;
#P newex 35 308 58 196617 vectral~ 8;
#P newex 185 215 58 196617 cycle~ 0.8;
#P newex 171 196 58 196617 cycle~ 0.7;
#P newex 158 177 58 196617 cycle~ 0.6;
#P newex 145 158 58 196617 cycle~ 0.5;
#P newex 132 139 58 196617 cycle~ 0.4;
#P newex 119 120 58 196617 cycle~ 0.3;
#P newex 106 101 58 196617 cycle~ 0.2;
#P newex 93 82 58 196617 cycle~ 0.1;
#P connect 8 0 12 0;
#P connect 10 0 8 0;
#P connect 18 0 8 0;
#P connect 10 0 12 1;
#P connect 10 0 8 1;
#P connect 9 0 22 0;
#P connect 22 0 23 0;
#P connect 10 0 9 0;
#P connect 23 0 8 2;
#P connect 0 0 9 1;
#P connect 1 0 9 2;
#P connect 2 0 9 3;
#P connect 3 0 9 4;
#P connect 4 0 9 5;
#P connect 5 0 9 6;
#P connect 6 0 9 7;
#P connect 7 0 9 8;
#P connect 14 0 13 0;
#P connect 24 0 17 0;
#P connect 17 0 15 0;
#P connect 15 0 16 0;
#P connect 21 0 19 0;
#P connect 20 0 19 0;
#P connect 19 0 18 0;
#P connect 25 0 20 0;
#P connect 20 0 18 1;
#P connect 25 0 21 0;
#P connect 21 0 18 2;
#P connect 29 0 28 0;
#P connect 28 0 26 0;
#P connect 26 0 27 0;
#P pop;


February 17, 2006 | 9:05 am

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?

– P.

————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html


February 17, 2006 | 12:55 pm

>Hi Dan,
>
>> 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.
>
>Ben

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

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


February 17, 2006 | 5:30 pm

> > if i build a compressor for example, i put objects
> > like avg~ or average~ into subpatchers and make them
> > a poly~ foo down 8

> 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)

wow your example is valid, i have not been thinging
about that. i was only aware that there is a slightly
inaccurate analysis result on very high frequencies
which i decided to ignore. :)

in real life the chance that a piece of music contains
a moment of pure 6 khz sinewave sound tends to zero though.
and if there is one, the sinewave will probably be of
only a very low volume.

hmm. but now …
how is that with 44.1 khz? …

you could as well have a 6 khz pulsetrain-like waveform
coming from an 88.2 khz oscillator, and when you average
it in 44.1 khz mode the problem appears again; in
exactly the same manner like you described it, and with
the same deviation, leading to a 100% wrong result.


February 17, 2006 | 5:37 pm

> Is upsampling linear interp, or are you just
> repeating samples?

in poly its repeating.
not a big deal to apply interpolation when needed. :)

it was worth the thread. i learned here it that
mute~ works with poly~ better than with patches
and i will handle this knowledge with care.

-110 (yet more efficient)


February 17, 2006 | 5:47 pm

guys, ben, peter,

does the fact that slide~ isnt linear matter …

[rampsmooth~ 8. 8.] — [poly~ down foo 8] —>

[slide~ 2. 2.] — [poly~ down foo 2] —>

… when you interpolate only between 2 samples?


February 17, 2006 | 5:51 pm

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. It is also susceptible to the sampling problem
that Ben mentioned, but my guess would be that this is more of an issue
with synthetic signals.

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~.

Peter McCulloch

max v2;
#N vpatcher 30 89 767 785;
#P window setfont "Sans Serif" 9.;
#P number 406 295 35 9 1 8 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 406 322 38 196617 sig~ 2;
#P user scope~ 406 395 536 525 2 3 128 -1. 1. 0 0. 0 0. 102 255 51 135
135 135 0;
#P newex 406 345 57 196617 index~ foo;
#P newex 326 147 78 196617 loadmess 4000;
#P number 270 295 35 9 1 8 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 79 281 35 196617 sqrt~;
#P newex 79 258 31 196617 abs~;
#P number 373 188 35 9 1 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P number 326 188 35 9 1 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 279 204 15 0;
#P newex 279 221 104 196617 pack rampsmooth 1 1;
#P newex 270 322 38 196617 sig~ 1;
#P user scope~ 270 395 400 525 2 3 128 -1. 1. 0 0. 0 0. 102 255 51 135
135 135 0;
#P newex 270 345 57 196617 index~ foo;
#P message 253 67 73 196617 sizeinsamps 8;
#P newex 253 93 61 196617 buffer~ foo;
#P newex 34 349 53 196617 poke~ foo;
#P user ezdac~ 55 412 99 445 0;
#P newex 80 55 76 196617 count~ 1 8 1 1;
#P newex 80 238 119 196617 selector~ 8;
#P newex 35 308 58 196617 vectral~ 8;
#P newex 185 215 58 196617 cycle~ 0.8;
#P newex 171 196 58 196617 cycle~ 0.7;
#P newex 158 177 58 196617 cycle~ 0.6;
#P newex 145 158 58 196617 cycle~ 0.5;
#P newex 132 139 58 196617 cycle~ 0.4;
#P newex 119 120 58 196617 cycle~ 0.3;
#P newex 106 101 58 196617 cycle~ 0.2;
#P newex 93 82 58 196617 cycle~ 0.1;
#P connect 8 0 12 0;
#P connect 10 0 8 0;
#P connect 18 0 8 0;
#P connect 10 0 12 1;
#P connect 10 0 8 1;
#P connect 9 0 22 0;
#P connect 22 0 23 0;
#P connect 10 0 9 0;
#P connect 23 0 8 2;
#P connect 0 0 9 1;
#P connect 1 0 9 2;
#P connect 2 0 9 3;
#P connect 3 0 9 4;
#P connect 4 0 9 5;
#P connect 5 0 9 6;
#P connect 6 0 9 7;
#P connect 7 0 9 8;
#P connect 14 0 13 0;
#P connect 24 0 17 0;
#P connect 17 0 15 0;
#P connect 15 0 16 0;
#P connect 21 0 19 0;
#P connect 20 0 19 0;
#P connect 19 0 18 0;
#P connect 25 0 20 0;
#P connect 20 0 18 1;
#P connect 25 0 21 0;
#P connect 21 0 18 2;
#P connect 29 0 28 0;
#P connect 28 0 26 0;
#P connect 26 0 27 0;
#P pop;


February 17, 2006 | 7:08 pm

Unlike rampsmooth~, I believe that slide~’s arguments are in ms. Note,
however, because of its logarithmic nature, it feels like it gets there
a little early.

It depends also on what you’re smoothing. slide~ is great for
amplitude envelopes, but since it behaves differently going up or down,
it might be a bit weird on bipolar~ signals… (i.e. if you were using
it smooth out some wave, it’s going to distort it. But that could be
interesting…)

Peter


February 17, 2006 | 8:46 pm

Quote: peter.mcculloch@gmail.com

the other peter, but that does not matter.

> Unlike rampsmooth~, I believe that slide~’s arguments are in ms.

nah its samples, too. at least thats what i hope.

> It depends also on what you’re smoothing.

well, basically between number 1 and number 2 in the
signal. :)

> but since it behaves differently going up or down,
> it might be a bit weird on bipolar~ signals…

right i forgot about that; so it is useless for
interpolating audio …

(i.e. if you were using
> it smooth out some wave, it’s going to distort it.

… unless we focus on the given case, [slide~ 2. 2.].

since there is no "curve" in a way from sample 1 to
sample 2, i can not get the picture if it matters to
interpolate between 2 samples log or lin …


February 17, 2006 | 9:59 pm

okay, i found it out, it matters.

so we use rampsmooth for interpolated downsampling
from today on.
it needs about 4-5 % more CPU compared to slide.

that is about 0.0001% on a dual G5, what a waste!


February 17, 2006 | 11:43 pm

> 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.

Well, that was just a silly example to prove that downsampling is in
fact not "safe". Beyond the silly example though, consider carefully
what is happening when you use poly~ to downsample a signal at a
sample rate of 2pi by a factor of n: all frequencies above (pi / n)
are FOLDED into the new baseband. In the example I outlined earlier
the sine wave was exactly a multiple of this new lower sampling rate,
so the frequency folded over from pi /4 to exactly 0 – this is another
way of saying the downsampling will "select" the same sample value
every time.

So yes it’s true that this frequency is extremely unlikely to occur by
itself in a real world signal. But consider all frequencies close to
this one… say, instead of pi/4, maybe (pi/4 + d) where d is some
small value. After downsampling this frequency folds to d. A
compression algorithm necessarily has some sort of threshold below
which the amplitude of a signal can’t be tracked. Let’s say it’s 20Hz
(or C in radians). So by downsampling, instead of missing frequencies
that are below 20Hz (C), you’ll miss all frequencies (k pi / n) +/- C
where k is an integer less than n. And if you don’t put a high-pass
filter in the downsampled poly~ it’s much worse, because you might
experience all kinds of audible beating from frequencies close to (k
pi / n).

So under ideal conditions you might have an amplitude tracker that
simply has some holes in the frequency spectrum. But since we’re not
in math world where cutoffs can be ideally brickwall, a more accurate
picture is that there are deep holes in the amplitude spectrum, with
fairly flat peaks in between. Depends on your filter. And I think he
said he’s using average~, which is basically a low pass filter, so
he’s attenuating the upper portion of his downsampled frequency band.
When unfolded, this portion of the spectrum he’s attenuating covers a
lot more ground. (Actually, now that I think about it, in some ways
using average~ inside a poly~ is actually better than using average~
outside!!)

Anyway, whatever. If the programming sounds good enough for whatever
the user wants to use it for, forget the anal ysis.

> 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.

Assuming standard signal levels I think it would take a LONG time to
accumulate enough error in average~ to affect a compression algorithm.
If it is a real concern one can always use buffir~.

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

Yeah, staircase. In a future version of MSP poly~ will have some nice
interpolation features.

Ben


February 17, 2006 | 11:52 pm

> so we use rampsmooth for interpolated downsampling
> from today on.
> it needs about 4-5 % more CPU compared to slide.

Something that I think will do a better job at upsampling than
rampsmooth~: try multiplying your 8 times downsampled signal with the
signal coming out from a [count~ 0 7 1 1] connected to a [==~ 0] -
this should leave the value of every eighth sample intact and set the
rest to zero. Then multiply that signal by 8 and send the result
through a lowpass biquad~ whose cutoff frequency is close to your
sampling frequency divided by 8. You can mess with the filter to see
what gives you the best result. Cascading two or more filters will
create a steeper cutoff curve, allowing you to let in more frequencies
below the cutoff before the aliased frequencies above the cutoff
audibly creep in.

Ben


February 18, 2006 | 1:32 am

You’re right; it is samples and not ms.

The equation for slide~

y(n) = y(n-1) + ((x(n) – y(n-1))/slide).

I’m assuming that the logarithmic nature has something to do with power
of 2 land, so maybe it might be better at up or downsampling? (just
curious…)

Peter


February 18, 2006 | 1:31 pm

> Something that I think will do a better job at upsampling than
> rampsmooth~: try multiplying your 8 times downsampled signal with the
> signal coming out from a [count~ 0 7 1 1] connected to a [==~ 0] -
> this should leave the value of every eighth sample intact and set the
> rest to zero. Then multiply that signal by 8 and send the result
> through a lowpass biquad~ whose cutoff frequency is close to your
> sampling frequency divided by 8.

whoa you would even involve a biquad~ instance to save
CPU when downsampling a biquad~ :P

somehow i think using just some lowpass filter is even
more inaccurate than the thing with the rampsmooth in
front of the poly patcher.

at this point i have to add that i was posting a wrong
example above when i gpot confused with upsampling vs
downsamping.
like you said, interpolation is required for upsampling,
but we ve originally been discussing downsampling.

ok does not matter, we are interested in both anway.

my example

[rampsmooth~ 8.8.] – [poly~ foo down 8]

should have read "up" instead of "down" and it would be
a correct algo.
the interpolation before downsampling has to look slightly
different, i just dont know how.
like making predelay for 0.5 samples before interpolation
… something in that direction.

any takers?


February 18, 2006 | 1:42 pm

> y(n) = y(n-1) + ((x(n) – y(n-1))/slide).
>
> I’m assuming that the logarithmic nature has something to do with power
> of 2 land, so maybe it might be better at up or downsampling? (just
> curious…)
>
>
> Peter

the thing with upsampling is that any interpolation
will change the sound in a way you might not want it
in the effect.

example:
lets say you want to make a ringmod or AM
effect which runs at 88 in your 44 runtime.
you will upsample the cycle~ and the *~ to create
an 88 khz process.
that in the incoming signal (of also 88 khz inside the
poly~ up 2) samaple 1 and sample 2 are identical because
they are only copied when upsampling, is irrelevant for
the result.


February 18, 2006 | 5:16 pm

Better simply meaning more CPU Efficient. (not having anything to do
with accuracy.) I was speculating on the effect that upsampling vs
downsampling would have on slide~ vs. rampsmooth~ in terms of CPU
usage.

Peter McCulloch


February 20, 2006 | 3:18 pm

Quote: Ben Nevile wrote on Fri, 17 February 2006 16:43
—————————————————-
In a future version of MSP poly~ will have some nice
> interpolation features.
>
> Ben
>
—————————————————-

Yeah ? Got my attention now :-)
Will there also be polyphase filtering ?

Salvator


Viewing 37 posts - 1 through 37 (of 37 total)