aesthetics in pluggo building


    Mar 31 2006 | 2:02 pm
    Hey everyone,
    I've been trying to make my pluggo skills a little more efficient these days. . .
    I've just started to utilize the "send ---param" "receive ---param" objects to help clean things up a bit. I've always tried a minimalistic approach to my patches, avoiding unnecessary objects such as "send/receives".... blah blah blah. After the patches start growing I'm walking the thin line between an "efficient" patch or a hairy ball of spider webs.
    I've always wondered if the excessive use of send/recieves type objects will lower the CPU efficiency of a patch.
    My pluggos have always turned out with the guts/internal-workings completely separated from the pluggo interface.
    Thoughts?
    Do any of you have any methods you'd like to share?
    -Chad

    • Apr 01 2006 | 11:06 am
      pvar is what I like :
      Salvator
    • Apr 01 2006 | 1:06 pm
      No strings attached, I love it. Thanks.
      I don't know how I missed that object before...
    • Apr 01 2006 | 9:27 pm
      > I've always wondered if the excessive use of send/recieves type objects will lower the CPU efficiency of a patch.
      in a MAX patch with auudio signals there is no
      reason to worry about CPU effeciency for sending
      messages :)
      when it comes to speed [s] and [r] should be like
      making connections.
      the harder part is to find out where you want speed
      priority for messages .. think of a multislider of 50
      sliders connected to 50 audio filters, to 50 numboxes,
      and to 50 parameters. sometimes it can be tricky
      to set up the right-to-left order for such things.
      where is it more important to have fast messages?
      in the audio process? in the recorded automation?
      in the visual feedback the numberboxes give you? hmmm ...
      > My pluggos have always turned out with the guts/internal-workings completely separated from the pluggo interface.
      yea i do that too but i do not see why this would
      work better without connections.
      if you make a connection to a send object or if
      you make a connection to a subpatcher it remains
      one connection in the GUI area of the patch layout.
      > Thoughts?
      > Do any of you have any methods you'd like to share?
      IMO using named objects for making GUIs might sound
      superb but in practice it is terrible.
      not only that you do not see an objects unique name
      in the layout, you can also no longer copy it.
      what i started to a while ago is using bpatchers
      of GUI objects which contain all the math shit and
      things like that.
      what should i say .. when i was trapped by my first
      bigger spiderweb a friend told me about the existance
      of [p stuff] and that solved my problems completely,
      no need to go any further.
      did i mention that i run dual 21" since 1997 ... ?
      if it wouldnt be about the additional GUI section
      i would be okay with a 15" powerbook for 99% of
      what i do in MAX.
    • Apr 03 2006 | 5:44 pm
      Chad Beckwith wrote:
      > I've always wondered if the excessive use of send/recieves type
      > objects will lower the CPU efficiency of a patch.
      A send/receive is exactly the same CPU wise and internally translates to
      the same thing, it just looks different.
      A send~/receive~ has some overhead but probably not really noticable.
      Its always more efficient to have a patch more clear, even if it would
      cost some overhead, but thats turning into philosophical perspectives...
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09
    • Apr 03 2006 | 6:14 pm
      btw : as mentionned in a previous thread, it the regular max "send" and "receive" (without the ~) can also transmit signal, and without the CPU overhead of send~/receive~
      Very cool !
      Salvator
    • Apr 04 2006 | 1:40 pm
      Quote: Roman Thilenius wrote on Sat, 01 April 2006 16:27
      ----------------------------------------------------
      >
      > what i started to a while ago is using bpatchers
      > of GUI objects which contain all the math shit and
      > things like that.
      Yes, I've just started to utilize prototypes and bpatchers! I'm making a habit now of building all of my max patches as if they are going to become a Pluggo, that way I never have to go back and add the "pp" objects in.
      >the harder part is to find out where you want speed
      >priority for messages .. think of a multislider of 50
      >sliders connected to 50 audio filters, to 50 numboxes,
      >and to 50 parameters. sometimes it can be tricky
      >to set up the right-to-left order for such things.
      >where is it more important to have fast messages?
      >in the audio process? in the recorded automation?
      >in the visual feedback the numberboxes give you? hmmm ...
      Priority
      For me it is always:
      1 - Audio
      2 - GUI display
      Has anyone noticed the use of Multisliders in scroll mode is very laggy once built into a Pluggo?
    • Apr 05 2006 | 8:21 pm
    • Apr 07 2006 | 10:53 am
      I know I keep raving about it, but matrixctrls in dial mode are a great time & space saver. Take a look at these two screen shots:
      http://www.wildfrontear.co.uk/d16 screenshot.jpg
      The rows of multi-state buttons on the left and the bank of sliders on the rh side of the first screen shot, and the routing matrix in the second one are all done with matrixctrls (in dial mode, of course). That's an awful lot of patch cords saved compared to if I'd used individual dials & sliders.
      And although I don't think this is nearly as much of an issue now as it was a while back, at one time using matrixctrl's to replace the equivalent no. of pictcntrls produced noticeably faster screen refreshes, so I'm guessing there's still some performance advantage in doing this.
      Note also in the first screen shot, I've used Roby's rs.textbutton a lot; having the text on the button instead of having to label each button also saves a lot of space and imho, produces a less cluttered interface.
      OK, I know I'm probably guilty of building interfaces that are still way too busy, but every little helps :-)
      cheers
      Roger
    • Apr 08 2006 | 8:50 pm
      Roger:
      I realized I didn't know what you were referring to when you spoke of
      dialmode for matrixctrl, and I can't see anything about it in the
      docs. (I'm still on Max 4.5.6). I can see that it can receive a
      dialmode [int] message, but would love some more comprehensive
      documentation about this mode? Is this a new feature?
      Thanks,
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Apr 08 2006 | 10:08 pm
      Not a new feature, but one that's somehow escaped documentation for some
      time.
      Sending a dialmode 1 message to a matrixctrl put's it in dial mode; a
      dailtracking [int] message sets the, er, dial tracking, ie. How many pixels
      you have to move the cursor to move the move the dial.
      I've been championing dialmode for some time and saying that it's light
      needs to be removed from the under the bushel, but the docs & help file stay
      curiously mute on the subject. Someone ..?
      Cheers
      Roger
    • Apr 08 2006 | 11:43 pm
      Thanks Roger - I also just found something searching through the old
      Max/MSP list archives, this one from jhno:
      At 1:31 AM -0700 10/27/04, jhno wrote:
      > >A anyone know what dialmode does on matrix ctrl?
      >
      >ja. in matrixctrl.help, double-click on 'pictureFormat' to see how to
      >arrange your bitmap. note that you can include images for a range of
      >values, not just 0 and 1. you specify the number of values in the inspector.
      >
      >by default, consecutive clicks on a matrixctrl will cycle through these
      >values, one step at a time.
      >
      >however, if you send the message, 'dialmode 1', matrixctrl treats each cell
      >as an independent knob. click on a cell and drag changes the value.
      >
      >'dialmode 0' reverts to the default behavior.
      >
      >jhno
      Agree this is useful!
      Cycling, this needs to go in the docs!!
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Apr 10 2006 | 9:24 am
      >> And although I don't think this is nearly as much of an issue now as it was a while back, at one time using matrixctrl's to replace the equivalent no. of pictcntrls produced noticeably faster screen refreshes, so I'm guessing there's still some performance advantage in doing this.
      thanks for this, nice idea .. i knew about
      the dialmode option but i ve never tried to
      use it bc i didn t trust it.
      well i just tried it on my incredible OS 9 setup
      and somehow it seems unkonfi.
      it _works, but sometimes when you drag down it
      changes the values of cells in the neighbourhood
      or the mouse seems to loose the cell you started
      completely. maybe i am doing something wrong.
      you say it can be even faster than using single
      picturecontrol objects?
    • Apr 10 2006 | 1:43 pm
      I don't know if matrixcntrls are any faster than
      pictcontrols, on a 1 for 1 basis , but if you
      replaced, say 100 pictcntrls with one 10 x 10 matrix,
      there might be some small performance gain.
      Sometime ago when Max v.4 was very young, there was a
      problem with screen updates in patches that used a lot
      of graphic objects, and then you could definitely see
      the difference, but I'm not sure it would be
      detectable with current versions.
      But then if you're still using 'incredible OS 9',
      Roman, this might still be an issue for you ;-)
      I've posted some graphics with an example patch at
      www.wildfrontear.co.uk/mctl stuff.zip .
      Most of the graphics were originally done by a guy
      called Fernando Covett, so I can't claim much of the
      credit - i just tweaked 'em a bit.
      cheers
      Roger
    • Apr 11 2006 | 1:14 pm
      > I've posted some graphics with an example patch at
      > www.wildfrontear.co.uk/mctl stuff.zip .
      aha there we have it. so it is like that ... it
      does not work in 4.1 ... you could think it works
      when you have a picture of 2-3 frames but with
      your pictures i can see clearly now that dialmode
      doesnt work.
      i also noticed that the frame limit of matrix is
      100 ... not enough for some of my long sliders.
    • Apr 11 2006 | 2:35 pm
      Thanks for the examples Roger, very helpful!
      One drawback I see for sliders used in this mode is that you can't
      click and jump to a position - the slider has to be slid, so to speak.
      On the other hand, nice to see that both vertical tracking, and
      horizontal tracking seem to work for the dials...
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com