multiple instances of COUNTER
Hello all,
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).
It all works except...
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.
bests,
nick
Try turning Overdrive on, in the options menu. The GUI updates are
likely interfering with the computation of data; enabling Overdrive
should fix this.
jb
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'.
>
>
>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?
>
hi
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)
the usual max problem...
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)
best
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,
should be enough to control dials.
Thankyou all for your responses.
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?
bests,
nick
>
>Could my computer (powerbook G4/1.25 GHz/512 RAM) be too slow to
>process this amount of data on the fly?
NO
not sure where the problem is , but it' s not there
what does the "activity monitor" say???
best
kasper
--
Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com
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.
> any further suggestions?
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
Hi,
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.
bests,
Nick
>> 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
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.
ah, the speed.
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 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 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:
rather than
metro 2 -> counter -> dial/numbox/flonnum etc -> patch logic
do
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.
hope my lame ascii is still formatted.
v a d e //
www.vade.info
abstrakt.vade.info
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
>> 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
>
>
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
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
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.
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?
nick