Bruno Zamborlin

Dear all, I'm looking for some technique besides "poly~" that allows to temporary freeze the cpu work in a patch. 

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

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?

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

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?

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.

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

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.

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.

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

later it ends up on disk as patch, so that i can call it as

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 

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

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.

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

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


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

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

> 1-Does "mute~" object help to optimize cpu work? Or does it just mute

> the signal output while cpu still continues to work?

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

> 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

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

(A lot of questions can easily be answered by just trying it. I didn't 

know the answer and tried, it works... ;-)

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 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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> 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 

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

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

meter~ can be put into a poly~ and therefore muted but 

but you can put a meter inside a poly and then let it control

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.

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

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.


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.

Roman sorry but I can't understand this last sentence :-)

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

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.

> Roman sorry but I can't understand this last sentence :-)

[poly~ mymeterpatch down 8] makes it run at only 5.7 khz, which

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.


> 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

> 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 

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.

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

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

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

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

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?

Quote: Stefan Tiedje wrote on Fri, 08 September 2006 21:04

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

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

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

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.

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.

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

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


Optimizing cpu work