Chad

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.

Do any of you have any methods you'd like to share?

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?

aesthetics-in-pluggo-building

I don't know how I missed that object before...

> 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 

when it comes to speed [s] and [r] should be like

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 

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.

> Do any of you have any methods you'd like to share?

IMO using named objects for making GUIs might sound 

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

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,

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 

> 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.


> 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 

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...

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 Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


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~

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

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 ...

Has anyone noticed the use of Multisliders in scroll mode is very laggy once built into a Pluggo?

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?


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 :-)

http://www.wildfrontear.co.uk/d16 screenshot.jpg
http://www.wildfrontear.co.uk/msmod screenshot.jpg

 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


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?

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X

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?

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com
http://www.jackosx.com


Not a new feature, but one that's somehow escaped documentation for some

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 ..?

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


Thanks Roger - I also just found something searching through the old 

Max/MSP list archives, this one from jhno:

> >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

>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.

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

>> 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 

well i just tried it on my incredible OS 9 setup

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 

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? 


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

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

Most of the graphics were originally done by a guy

called Fernando Covett, so I can't claim much of the

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


> 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 

i also noticed that the frame limit of matrix is 

100 ... not enough for some of my long sliders.

>  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.


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...

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


aesthetics in pluggo building