Optimizing cpu work

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

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

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

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

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

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