Optimizing cpu work

Aug 30, 2006 at 9:00am

Optimizing cpu work

Dear all, I’m looking for some technique besides “poly~” that allows to temporary freeze the cpu work in a patch.
Some questions:

1-Does “mute~” object help to optimize cpu work? Or does it just mute the signal output while cpu still continues to work?

2-And “enable $1+pcontrol” technique?

3-Does exist something to temporary freeze everything (audio+video+graphics) that is contained in a bpatcher?
For instance, if I have a bpatcher that contains a big cpu-expensive sonogram and I want to freeze it, what should I do?

Thanks for help,
Bruno

#27380
Aug 30, 2006 at 10:06am

mute~ and enable $1 + pcontrol both disable audio processing in a patch and decrease cpu load.

But there is one drawback I experienced: biquad~s tend to get unstable while muted. In other words: muting and unmuting a patch with biquads gave me huge dc offsets and clicks (also when using mute~ in combination with pass~).

The solution that I use now is to convert the patchers that have to be muted to vst’s and use the bypass message. This descreases cpu as well and doesn’t have the problem with the filters.

Regards,
Mattijs

#82759
Aug 30, 2006 at 11:05am

Hello

I would like to know, if it’s possible to use a Mac Mini (the Core Duo version
with additional RAM) and a good Firewire sound card (eg Fireface 400) for
serious professional audio and live concerts. One example application is to run
a maxmsp polyphonic sampler that is played with a MIDI keyboard. Number of
polyphonic voices can be tuned in function of the available power so the most
crucial questions here are low latency and no sound drop.

The Mac mini is quite inexpensive (less than 1000 euros) compared to a Mac Book
Pro (about 3000 euros). Besides the screen, keyboard, wifi, iSight, 2 GHz CPU
and 7200 rpm HD that you find on the Mac Book, where does this price difference
comes from ? If the Mac Book was 1.66 GHz, would they have similar performance ?

Also (if you know it) how does the Mac Mini compares to a Pentium M Centrino 1.7
GHz laptop PC or to a Pentium 2.4 GHz Desktop PC ? The Mac Mini is attractive
but I have no idea about its performances.

Best regards
Julien

#82760
Aug 30, 2006 at 12:26pm

#82761
Aug 30, 2006 at 1:44pm

#82762
Aug 30, 2006 at 3:44pm

#82763
Aug 30, 2006 at 8:53pm

#82764
Aug 30, 2006 at 9:44pm

#82765
Aug 30, 2006 at 9:59pm

keith:

>> Do you all always use poly~ instead of bpatcher when using audio?

when patching audio DSP, i am very anal about “where is a
module, and where is an interface”, which means when i
have a dozen objects which do blabla, i put them into a
[p blabla] patcher.

later it ends up on disk as patch, so that i can call it as
[blabla].

when i then find out i might want to mute it, i make it a
[poly~ blabla] by adding [in~]s, [out~]s, and a thispatcher.

usually they are turned off by default/by loadbang.

> Does poly~ freeze everything in the patch, or just the audio elements?

when needed you can control that individually.
i dont do it for midi and messages, only for audio.

turning a poly~ off by sending “mute 1″ to its thispatcher,
turns only the audio off – and that includes the signal connections going to the poly patcher.

messages still work. (if they wouldnt, you could not turn
it on again!)

vade:

i was referring to the “enable 0″ messages most msp objects
accept. see alt-command-menu. i hate it because you can never
see the status of the object, and there are some dumb objects
which go on and off regardless you send them 0 or 1. :)

#82766
Aug 30, 2006 at 10:17pm

Perfect, thanks for responses.
So, poly~ and mute~ seem to be anyway the better solutions.

And what about graphic objects (like sonograms or audio meters)?
If I have a bpatcher that contains for instance a big cpu-expensive sonogram, how can I temporary freeze it?
Now I’m using a script that deletes and creates it again, but of course this solution provokes galling audio clicks.
And if I use a gate~, sonogram continues to work…

Thanks
Bruno

#82767
Sep 2, 2006 at 7:40am

Bruno Zamborlin wrote:
> 1-Does “mute~” object help to optimize cpu work? Or does it just mute
> the signal output while cpu still continues to work?

it will release the CPU load

> 2-And “enable $1+pcontrol” technique?

It does CPU wise even more, as it also stops the normal Max processing
for that patcher

> 3-Does exist something to temporary freeze everything
> (audio+video+graphics) that is contained in a bpatcher? For instance,
> if I have a bpatcher that contains a big cpu-expensive sonogram and I
> want to freeze it, how should I do?

Did you try it? a via pcontrol stoped bpatcher does freeze the sonogram
for me…

(A lot of questions can easily be answered by just trying it. I didn’t
know the answer and tried, it works… ;-)

Stefan


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

#82768
Sep 4, 2006 at 5:47am

Trond Lossius wrote:
> A third way of dynamically turning of DSP processing is using begin~
> with selector~, but according to the documentation this is not
> recommended, and might not be supported at some point in the future.

though I think it would be good if it remains, as its a different way of
thinking and for a selector~/matrix~ construction more appropriate. I’d
vote for unlimited support…

Stefan


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

#82769
Sep 5, 2006 at 4:37pm

> And what about graphic objects (like sonograms or audio meters)?
> If I have a bpatcher that contains for instance a big cpu-expensive sonogram, how can I temporary freeze it?

good question.

meter~ can be put into a poly~ and therefore muted but
then we cant see it.

:(

but you can put a meter inside a poly and then let it control
a custom pictureslider-based “meter”.

this way it can be muted inside the poly~.
(inside a poly~ inside a bpatcher if you want)

if you are as crazy as i am you can also run the meter~
object as poly~ down 8 to save 87.5% of its CPU requirement.

#82770
Sep 5, 2006 at 6:08pm

#82771
Sep 5, 2006 at 6:40pm

Quote: Roman Thilenius wrote on Tue, 05 September 2006 10:37
—————————————————-
> if you are as crazy as i am you can also run the meter~
> object as poly~ down 8 to save 87.5% of its CPU requirement.
—————————————————-
Thank you both for good ideas.
Roman sorry but I can’t understand this last sentence :-)

Bruno

#82772
Sep 5, 2006 at 6:51pm

Quote: Bruno Zamborlin wrote on Tue, 05 September 2006 12:40
—————————————————-
> Quote: Roman Thilenius wrote on Tue, 05 September 2006 10:37
> —————————————————-
> > if you are as crazy as i am you can also run the meter~
> > object as poly~ down 8 to save 87.5% of its CPU requirement.
> —————————————————-
> Thank you both for good ideas.
> Roman sorry but I can’t understand this last sentence :-)
>
> Bruno
>
—————————————————-

[poly~ mymeterpatch down 8] makes it run at only 5.7 khz, which
is enough to drive a GUI.

#82773
Sep 7, 2006 at 8:45am

julien breval wrote:
> I would like to know, if it’s possible to use a Mac Mini (the Core
> Duo version with additional RAM) and a good Firewire sound card (eg
> Fireface 400) for serious professional audio and live concerts.

Why not, I’d consider it a good choice, as its quiet and very transportable.

> so the most crucial questions here are low latency and no sound drop.
>
>
mainly dependent on the interface, not so much on the computer…

> If the Mac Book was 1.66 GHz, would they have similar performance ?

yes, its basically notebook technology built into a small box. One
difference is the graphics card, its not made for gaming or highly
demanding Jitter patches…

> The Mac Mini is attractive but I have no idea about its performances.

There are Ali Momenis Max benchmarks, don’t know if the new Macbooks and
Mac Minintels are listed yet…

Stefan


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

#82774
Sep 8, 2006 at 7:04pm

Bruno Zamborlin wrote:
> And what about graphic objects (like sonograms or audio meters)? If I
> have a bpatcher that contains for instance a big cpu-expensive
> sonogram, how can I temporary freeze it?

This works for me:

Stefan

#P toggle 195 32 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P message 52 65 50 196617 loop 1;
#P user ezdac~ 86 282 130 315 0;
#P toggle 102 46 15 0;
#P message 130 35 50 196617 open;
#P message 183 59 50 196617 enable $1;
#N sfplay~ 1 120960 0 ;
#P newobj 126 85 43 196617 sfplay~;
#P newex 184 88 50 196617 pcontrol;
#P bpatcher 152 140 127 99 -8 -26 SonoBpatch.pat 2;
#N vpatcher 40 104 640 504;
#P hidden inlet 10 8 15 0;
#P user spectroscope~ 10 28 123 95 20 0 1 0 0 1 0 0 0 0 0 0;
#X frgb 224 224 224;
#X brgb 255 255 255;
#X rgb2 0 0 0;
#X rgb3 243 204 204;
#X rgb4 255 0 0;
#X rgb5 184 184 184;
#X rgb6 0 0 0;
#X rgb7 0 0 0;
#X rgb8 255 255 255;
#X rgb9 255 0 0;
#X rgb10 255 191 0;
#X rgb11 0 191 127;
#X rgb12 127 0 127;
#X rgb13 0 0 0;
#X range 0. 1.;
#X domain 0. 22050.;
#X done;
#P hidden connect 1 0 0 0;
#P pop;
#BP pop 0;
#P connect 8 0 3 0;
#P connect 7 0 2 0;
#P connect 2 0 0 0;
#P connect 5 0 2 0;
#P connect 4 0 2 0;
#P connect 1 0 0 0;
#P connect 3 0 1 0;
#P window clipboard copycount 9;


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

#82775
Sep 10, 2006 at 4:01pm

Quote: Stefan Tiedje wrote on Fri, 08 September 2006 21:04
—————————————————-
> Bruno Zamborlin wrote:
> > And what about graphic objects (like sonograms or audio meters)? If I
> > have a bpatcher that contains for instance a big cpu-expensive
> > sonogram, how can I temporary freeze it?
>
> This works for me:
>
> Stefan
—————————————————-

It seems a good solution. Thank you very much :)

Bruno

http://www.brunozamborlin.com

#82776
Jan 11, 2007 at 3:32pm

Sorry everyone, I’ll have to add something to this thread.

I recently found out that vst~ doesn’t work together with hi priority (scheduler) events. Incoming hi-priority events are automatically deferred before being processed inside vst~. This means you can’t use the method I described below for timing-sensitive operations, which of course is the most probable use.

Mattijs

Quote: Mattijs wrote on Wed, 30 August 2006 12:06
—————————————————-
> mute~ and enable $1 + pcontrol both disable audio processing in a patch and decrease cpu load.
>
> But there is one drawback I experienced: biquad~s tend to get unstable while muted. In other words: muting and unmuting a patch with biquads gave me huge dc offsets and clicks (also when using mute~ in combination with pass~).
>
> The solution that I use now is to convert the patchers that have to be muted to vst’s and use the bypass message. This descreases cpu as well and doesn’t have the problem with the filters.
>
> Regards,
> Mattijs
—————————————————-

#82777

You must be logged in to reply to this topic.