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:
      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 http://www.jackosx.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 http://www.jackosx.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 http://www.jackosx.com