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

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

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

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

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

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

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

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.

Bruno

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

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

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

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

Bruno

http://www.brunozamborlin.com

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