multiple instances of COUNTER


    Oct 18 2006 | 12:26 pm
    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

    • Oct 18 2006 | 12:40 pm
      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'.
    • Oct 18 2006 | 1:01 pm
      > > >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
    • Oct 18 2006 | 7:24 pm
      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.
    • Oct 18 2006 | 8:57 pm
      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
    • Oct 18 2006 | 9:20 pm
      > >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
    • Oct 19 2006 | 9:17 am
      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
    • Oct 19 2006 | 9:50 am
    • Oct 19 2006 | 12:00 pm
      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
    • Oct 19 2006 | 1:01 pm
      >> 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.
    • Oct 19 2006 | 1:05 pm
      ah, the speed.
      well same speed at different incremental steps = different velocity.
    • Oct 19 2006 | 2:24 pm
      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
    • Oct 19 2006 | 3:56 pm
      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 > >
    • Oct 19 2006 | 10:31 pm
      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
    • Oct 20 2006 | 5:08 pm
      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