I have been teaching myself max/msp since jan 2005 (noobie alert). This is my first post to the list so...here goes..

I am creating a GUI to control the panning of multiple channels of audio in an 8 speaker setup. Each channel has a dial which, when triggered by a keystroke, starts/stops rotating through 360 degrees (the speed of this rotation is user defined).

I am using multiple instances of COUNTER to drive the 8 dials. These are located in a subpatch. When just one dial is rotating there are no problems. As soon as I turn on a second dial they both rotate at a slower rate than the speed i have defined. If I then turn on a third dial, all three rotate at an even slower rate. Also, the dials no longer rotate 'smoothly'.

i have tested the counter objects in a new patch window and it seems that I simply can't run multiple instances of counter in the same patch without them disrupting each others rate/'smoothness'. Is this the case? If so, what are my alternatives?

I have included a copy of the GUI patch below so you can see the problem for yourselves. If you need further info let me know.

Any help you can give me is greatly appreciated.

multiple-instances-of-counter

Try turning Overdrive on, in the options menu. The GUI updates are 

likely interfering with the computation of data; enabling Overdrive 

Am 18.10.2006 um 14:26 schrieb nick williams:

> I am using multiple instances of COUNTER to drive the 8 dials. 

> These are located in a subpatch. When just one dial is rotating 

> there are no problems. As soon as I turn on a second dial they both 

> rotate at a slower rate than the speed i have defined. If I then 

> turn on a third dial, all three rotate at an even slower rate. 

> Also, the dials no longer rotate 'smoothly'.

Try turning Overdrive on, in the options menu. The GUI updates are  
likely interfering with the computation of data; enabling Overdrive  
should fix this.

> I am using multiple instances of COUNTER to drive the 8 dials.  
> These are located in a subpatch. When just one dial is rotating  
> there are no problems. As soon as I turn on a second dial they both  
> rotate at a slower rate than the speed i have defined. If I then  
> turn on a third dial, all three rotate at an even slower rate.  
> Also, the dials no longer rotate 'smoothly'.


>i have tested the counter objects in a new patch window and it seems 

>that I simply can't run multiple instances of counter in the same 

>patch without them disrupting each others rate/'smoothness'. Is this 

>the case? If so, what are my alternatives?

after a really short look at it, i don't seem to have this problem - 

the most obvious answer would be to check it your metro's are OK 

(there was a lot of discusions about it recently) and change it to a 

metro driven by audio (I belive i did send such a patch recenlty, 

other have done so as well, and i think there is a metro~ object in 

to have a smooth visual report of what is going on, i also suggest, 

to change, in yoyur dial's inspectors, the display change to 360 -- 

oops, it shows only 359!!!! (which is normal!!)

since you use teh GMEM's miltiouts~ you could as well use their 

"panpot" gui object (but now, dial does it all as well)

>
>
>i have tested the counter objects in a new patch window and it seems 
>that I simply can't run multiple instances of counter in the same 
>patch without them disrupting each others rate/'smoothness'. Is this 
>the case? If so, what are my alternatives?
>

after a really short look at it, i  don't seem to have this problem - 
which does not mean you don't have it.

the most obvious answer would be to check it your metro's are OK 
(there was a lot of discusions about it recently) and change it to a 
metro driven by audio (I belive i did send such a patch recenlty, 
other have done so as well, and i think there is a metro~ object in 
ST.objects)

to have a smooth visual report of what is going on, i also suggest, 
to change, in yoyur dial's inspectors, the display change to 360 -- 
oops, it shows only 359!!!! (which is normal!!)

since you use teh GMEM's miltiouts~ you could as well use their 
"panpot" gui object (but now, dial does it all as well)

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

Quote: nick williams wrote on Wed, 18 October 2006 06:26

> I am using multiple instances of COUNTER to drive the 8 dials.

why? the actions +1 and -1 driven by the main metro, 

why? the actions +1 and -1 driven by the main metro, 
should be enough to control dials.


When I turn overdrive on, the problem remains eg.the dials rotate slower with every additional dial that is turned on. It also appears that the 'top speed' of the dials is less than with overdrive off.

I replaced the METTRO objects with sig driven METRO~ but when I ran eight simultaeously it brought the patch to it's knees with the leftmost two dials actually stopping.

Romans '+1/-1' method for driving the dials makes much more sense than all the COUNTER objects but it still requires running 8 METRO objects simultaneously..and my patch doesn't seem to like that.

Could my computer (powerbook G4/1.25 GHz/512 RAM) be too slow to process this amount of data on the fly?

I will keep banging my head against it....any further suggestions?

>Could my computer (powerbook G4/1.25 GHz/512 RAM) be too slow to 

not sure where the problem is , but it' s not there

>
>Could my computer (powerbook G4/1.25 GHz/512 RAM) be too slow to 
>process this amount of data on the fly?

Counter is highly unlikely to be the problem, the calculations it's 

Conceptually, I would drive the patch with a single metro and gate 

the individual dials (or the counters) to turn them on or off.

The only thing that's at all computationally expensive in your patch 

are the dials. Redrawing uses more CPU than most people imagine, 

You can't make the dials less expensive, but you can probably tweak 

performance parameters (Options -> Performance Options...). Experiment.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

Counter is highly unlikely to be the problem, the calculations it's  
performing are light weight.

Conceptually, I would drive the patch with a single metro and gate  
the individual dials (or the counters) to turn them on or off.

The only thing that's at all computationally expensive in your patch  
are the dials. Redrawing uses more CPU than most people imagine,  
particularly with lots of colors.

You can't make the dials less expensive, but you can probably tweak  
performance parameters (Options -> Performance Options...). Experiment.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

Yes the dials can all be set rotating at different speeds. This is a function I'd like to keep so I guess the Metro objects have to stay.

The dials only function is to display the pan position so I can easily replace them with number boxes. I will be interested to see if this improves performance as Peter suggests.

I will also experiment with Performance options. I'm at work at the mo' so I'll report back later today.

Thanks for all the help guys, I'm learning a lot.

>> Romans '+1/-1' method for driving the dials makes much more >sense than all the COUNTER objects but it still requires >running 8 METRO objects simultaneously..and my patch doesn't >seem to like that.

maybe use send/recieve and connect the dial-control 

patches to a main metro somewhere outside.

you could even close the connection from the metro to those

dials which a are currently not to be remoted.

> Could my computer (powerbook G4/1.25 GHz/512 RAM) be too slow > to process this amount of data on the fly?

not at all, but a metro with 8 connections (or 8 metros)

means 8 bangs in a row as fast as possible (think uzi)

and that is always a bit problematic with realtime

performance patches. it probably gets worse if sent

what about running the metro at only 50 miliseconds

and then interpolating the data for GUI and/or audio?

there is an older version of [110.ATC] at maxobject.com

maybe use send/recieve and connect the dial-control 
patches to a main metro somewhere outside.
you could even close the connection from the metro to those
dials which a are currently not to be remoted.

not at all, but a metro with 8 connections (or 8 metros)
means 8 bangs in a row as fast as possible (think uzi)
and that is always a bit problematic with realtime
performance patches. it probably gets worse if sent
to bpatchers.

what about running the metro at only 50 miliseconds
and then interpolating the data for GUI and/or audio?

there is an older version of [110.ATC] at maxobject.com
which deals with a similar problem.


well same speed at different incremental steps 

well same speed at different incremental steps 
= different velocity.


On 19-Oct-2006, at 14:00, nick williams wrote:

> Yes the dials can all be set rotating at different speeds. This is 

> a function I'd like to keep so I guess the Metro objects have to stay.

Sorry, missed that. Then it makes sense to have individual metros.

> The dials only function is to display the pan position so I can 

> easily replace them with number boxes. I will be interested to see 

> if this improves performance as Peter suggests.

I don't know that numbox will buy you a whole lot over dial. It's 

still a UI object that draws. But sure, try it.

Basically, you're making three different kinds of demands on your 

computer: you have timed events (bangs, incrementing counters, 

whatever) that you presumably want to have as precise as possible; a 

user interface (dials, numboxs, whatever) to help you visualize 

what's happening with the timed events; and audio to deal with.

If your audio processing is making sufficient demands on the computer 

that Max doesn't have time to do everything your patch demands, it 

first tries to cope by drawing less often. So your dial animation is 

less smooth. <>. If Max still can't keep up, it may start 

skipping timer events (ie, metro bangs), which will be a problem with 

Your multiout~s are probably the CPU hog, particularly if you're 

doing something like smooth panning with cosine functions controlling 

the crossfade. Who knows, we've not seen them, have we? But that's 

probably what you have to look at for optimization.

On 19-Oct-2006, at 14:00, nick williams wrote:
> Yes the dials can all be set rotating at different speeds. This is  
> a function I'd like to keep so I guess the Metro objects have to stay.

> The dials only function is to display the pan position so I can  
> easily replace them with number boxes. I will be interested to see  
> if this improves performance as Peter suggests.

I don't know that numbox will buy you a whole lot over dial. It's  
still a UI object that draws. But sure, try it.

Basically, you're making three different kinds of demands on your  
computer: you have timed events (bangs, incrementing counters,  
whatever) that you presumably want to have as precise as possible; a  
user interface (dials, numboxs, whatever) to help you visualize  
what's happening with the timed events; and audio to deal with.

If your audio processing is making sufficient demands on the computer  
that Max doesn't have time to do everything your patch demands, it  
first tries to cope by drawing less often. So your dial animation is  
less smooth. <>. If Max still can't keep up, it may start  
skipping timer events (ie, metro bangs), which will be a problem with  
your patch logic.

Your multiout~s are probably the CPU hog, particularly if you're  
doing something like smooth panning with cosine functions controlling  
the crossfade. Who knows, we've not seen them, have we? But that's  
probably what you have to look at for optimization.

if the counter is feeding the GUI object, and the GUI object is 

feeding some logic, and the GUI object is being updated A LOT, which 

slows your patch down, do something like this:

metro 2 -> counter -> dial/numbox/flonnum etc -> patch logic

prepend set will update the position, but not send a message out , 

and the qlim will 'slow down' the updating, so max can keep up. note 

that you stil get your 'full speed' messages, and if you use the 

dial, it WILL output, just not the counters messages, which the patch 

On Oct 19, 2006, at 10:24 AM, Peter Castine wrote:

> On 19-Oct-2006, at 14:00, nick williams wrote:

>> Yes the dials can all be set rotating at different speeds. This is 

>> a function I'd like to keep so I guess the Metro objects have to 

> Sorry, missed that. Then it makes sense to have individual metros.

>> The dials only function is to display the pan position so I can 

>> easily replace them with number boxes. I will be interested to see 

>> if this improves performance as Peter suggests.

> I don't know that numbox will buy you a whole lot over dial. It's 

> still a UI object that draws. But sure, try it.

> Basically, you're making three different kinds of demands on your 

> computer: you have timed events (bangs, incrementing counters, 

> whatever) that you presumably want to have as precise as possible; 

> a user interface (dials, numboxs, whatever) to help you visualize 

> what's happening with the timed events; and audio to deal with.

> If your audio processing is making sufficient demands on the 

> computer that Max doesn't have time to do everything your patch 

> demands, it first tries to cope by drawing less often. So your dial 

> animation is less smooth. <>. If Max still can't keep up, it 

> may start skipping timer events (ie, metro bangs), which will be a 

> Your multiout~s are probably the CPU hog, particularly if you're 

> doing something like smooth panning with cosine functions 

> controlling the crossfade. Who knows, we've not seen them, have we? 

> But that's probably what you have to look at for optimization.

> Peter Castine +--> Litter Power & Litter Bundle for Jitter

> Interface Building for |home | chez nous|

> Max/MSP Extremely cool |bei uns | i nostri|

if the counter is feeding the GUI object, and the GUI object is  
feeding some logic, and the GUI object is being updated A LOT, which  
slows your patch down, do something like this:

metro 2 -> counter -> patch logic
                                 - > qlim 100 -> prepend set -> dial/ 
numbox/flonum -> patch logic

prepend set will update the position, but not send a message out ,  
and the qlim will 'slow down' the updating, so max can keep up. note  
that you stil get your 'full speed' messages, and if you use the  
dial, it WILL output, just not the counters messages, which the patch  
is getting anyway.

> On 19-Oct-2006, at 14:00, nick williams wrote:
>> Yes the dials can all be set rotating at different speeds. This is  
>> a function I'd like to keep so I guess the Metro objects have to  
>> stay.
>
> Sorry, missed that. Then it makes sense to have individual metros.
>
>> The dials only function is to display the pan position so I can  
>> easily replace them with number boxes. I will be interested to see  
>> if this improves performance as Peter suggests.
>
> I don't know that numbox will buy you a whole lot over dial. It's  
> still a UI object that draws. But sure, try it.
>
> Basically, you're making three different kinds of demands on your  
> computer: you have timed events (bangs, incrementing counters,  
> whatever) that you presumably want to have as precise as possible;  
> a user interface (dials, numboxs, whatever) to help you visualize  
> what's happening with the timed events; and audio to deal with.
>
> If your audio processing is making sufficient demands on the  
> computer that Max doesn't have time to do everything your patch  
> demands, it first tries to cope by drawing less often. So your dial  
> animation is less smooth. <>. If Max still can't keep up, it  
> may start skipping timer events (ie, metro bangs), which will be a  
> problem with your patch logic.
>
> Your multiout~s are probably the CPU hog, particularly if you're  
> doing something like smooth panning with cosine functions  
> controlling the crossfade. Who knows, we've not seen them, have we?  
> But that's probably what you have to look at for optimization.
>
> -- P.
>
> --------------    http://www.bek.no/~pcastine/Litter/    -------------
> Peter Castine             +--> Litter Power & Litter Bundle for Jitter
>                                Universal Binaries on the way
> iCE:  Sequencing,  Recording &
>       Interface  Building  for                   |home    | chez nous|
>       Max/MSP   Extremely cool                   |bei uns |  i nostri|
>       http://www.dspaudio.com/                   http://www.castine.de
>
>


> If I remember that patch well, it was possible to set a different speed 

> for each channel, so you need as many [metro] (or whatever timer used) 

> as channels. Btw, [line] could be an option too.

I agree - the amount of bangs out of metro is much much higher than the 

pixel resolution. Instead of counting to 360, a count to 72 seems more 

than enough, but the idea to do it with line seems the most clear one, 

as you can tweak the grain duration just for the performance and the 

parameter to control it is the time for one circle. This is also much 

Multiouts has a fade parameter which could be set to exactly the same 

time as the line grain. All fits together.

But I must say on my Powerbook 1.5 GHz the patch has no problem at all, 

the speed of all pots is the same even if I set the metro to 1 ms...

Patrick Delges wrote:
> If I remember that patch well, it was possible to set a different speed 
> for each channel, so you need as many [metro] (or whatever timer used) 
> as channels. Btw, [line] could be an option too.

I agree - the amount of bangs out of metro is much much higher than the 
pixel resolution. Instead of counting to 360, a count to 72 seems more 
than enough, but the idea to do it with line seems the most clear one, 
as you can tweak the grain duration just for the performance and the 
parameter to control it is the time for one circle. This is also much 
more intuitive.
Multiouts has a fade parameter which could be set to exactly the same 
time as the line grain. All fits together.

But I must say on my Powerbook 1.5 GHz the patch has no problem at all, 
the speed of all pots is the same even if I set the metro to 1 ms...

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


Quote: Stefan Tiedje wrote on Thu, 19 October 2006 23:31

----------------------------------------------------

> the idea to do it with line seems the most clear one, 

> as you can tweak the grain duration just for the performance and the 

> parameter to control it is the time for one circle. This is also much 

> Multiouts has a fade parameter which could be set to exactly the same 

> time as the line grain. All fits together.

I'll try doing it with Line. Vades idea to re-arrange the patch didn't solve the initial problem but improves functionality so I'll use that model.

> But I must say on my Powerbook 1.5 GHz the patch has no problem at all,

The activity monitor shows no indication that my computer is struggling with the exception of the odd CPU peak. Hmm?

Quote: Stefan Tiedje wrote on Thu, 19 October 2006 23:31
----------------------------------------------------
> > Btw, [line] could be an option too. 

> the idea to do it with line seems the most clear one, 
> as you can tweak the grain duration just for the performance and the 
> parameter to control it is the time for one circle. This is also much 
> more intuitive.
> Multiouts has a fade parameter which could be set to exactly the same 
> time as the line grain. All fits together.

> But I must say on my Powerbook 1.5 GHz the patch has no problem at all, 