Forums > MaxMSP

pattr performance test

March 23, 2007 | 3:36 pm

Hi,

I was running some framerate tests and I discovered that the use of bound pattrs instead of send/receives can have much influence on the performance of a patch.

I send a random value to 300 receives every 1 ms and have a movie running at 100 fps. Then I send the random values to 300 pattrs and the fps of the movie drops to 50 fps.

I’d say that basically the bound pattrs and the receives perform the same task.

I attached the patch I used. I tested on a Mac Pro 4 x 2,6 GHz

Mattijs


March 23, 2007 | 3:46 pm

But in a very, very different way. I don’t dispute that pattr’s
performance couldn’t be improved (although whether it actually _can_
be improved, technically, is another matter). Nevertheless, send/
receive and pattr are not technically comparable.

jb

Am 23.03.2007 um 16:36 schrieb Mattijs Kneppers:

> I’d say that basically the bound pattrs and the receives perform
> the same task.


March 23, 2007 | 4:21 pm

By the way, try your test with pattrforward instead of pattr. It is
probably faster, and if so, points in some directions for the
optimization of some future pattr generation.

jb

Am 23.03.2007 um 16:36 schrieb Mattijs Kneppers:

> Hi,
>
> I was running some framerate tests and I discovered that the use of
> bound pattrs instead of send/receives can have much influence on
> the performance of a patch.
>
> I send a random value to 300 receives every 1 ms and have a movie
> running at 100 fps. Then I send the random values to 300 pattrs and
> the fps of the movie drops to 50 fps.
>
> I’d say that basically the bound pattrs and the receives perform
> the same task.
>
> I attached the patch I used. I tested on a Mac Pro 4 x 2,6 GHz
>
> Mattijs
> –
> SmadSteck – http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>
>


March 23, 2007 | 4:34 pm

Thanks for your reply. I’ll have another look at the pattr sdk to see if I can figure out what the differences are.

I really dig the pattr system and I would love to replace global sends and receives entirely with pattrs that bind relatively. As patches get bigger and need an object oriented approach, this really starts to matter.

Let me state that I would be very very happy if pattrs could be a 100% alternative for global send/receive.

Cheers,
Mattijs

Quote: Jeremy Bernstein wrote on Fri, 23 March 2007 16:46
—————————————————-
> But in a very, very different way. I don’t dispute that pattr’s
> performance couldn’t be improved (although whether it actually _can_
> be improved, technically, is another matter). Nevertheless, send/
> receive and pattr are not technically comparable.
>
> jb
>
> Am 23.03.2007 um 16:36 schrieb Mattijs Kneppers:
>
> > I’d say that basically the bound pattrs and the receives perform
> > the same task.
>
>
—————————————————-



dnz
March 23, 2007 | 4:53 pm

Hallo,

I’m trying to track sensor data through the Arduino running on Maxmsp
4.57 on Os 10.4.8, ibook g4 1,33ghz

I’ve uploaded the firmware onto the board, works fine.

I open Arduino2max and selected the port (b) and click start.

I don’t receive any data. I don’t even get an error message on max
window. The rx and tx on the board blicks and blicks but no data. It
works fine on my friends computer but not mine. Could anyone help? I
hope that my computer not going on strike today!

regards
dennis


March 23, 2007 | 5:07 pm

Quote: Jeremy Bernstein wrote on Fri, 23 March 2007 17:21
—————————————————-
> By the way, try your test with pattrforward instead of pattr. It is
> probably faster, and if so, points in some directions for the
> optimization of some future pattr generation.
>
> jb

To use pattrforward to send a value to 300 pattrs involves setting the destination 300 times with uzi and sprintf or something similar. I tried and this brings down the framerate to 25 fps. It’s not a clean comparison so unfortunately I don’t think we can conclude anything from this test.

A second thing is that the functionality of the pattr system I need most is that it stores a value in one place and all other locations where the value is needed bind to that place. In fact I want to come as close as I can to the behaviour of a standard variable in an OO programming language, which has many practical advantages compared to global send/receives.

Thanks,
Mattijs


March 23, 2007 | 5:54 pm

have you instaled the ftdi drivers?

On 3/23/07, Sonic Kooking wrote:
> Hallo,
>
> I’m trying to track sensor data through the Arduino running on Maxmsp
> 4.57 on Os 10.4.8, ibook g4 1,33ghz
>
> I’ve uploaded the firmware onto the board, works fine.
>
> I open Arduino2max and selected the port (b) and click start.
>
> I don’t receive any data. I don’t even get an error message on max
> window. The rx and tx on the board blicks and blicks but no data. It
> works fine on my friends computer but not mine. Could anyone help? I
> hope that my computer not going on strike today!
>
> regards
> dennis
>



dnz
March 23, 2007 | 6:16 pm

yes.
ah!!! i’ve downloaded the wrong version of arduino2max! stupid me…

thanks anyway..

dennis

Am 23.03.2007 um 18:54 schrieb Scott Fitzgerald:

> have you instaled the ftdi drivers?
>
> On 3/23/07, Sonic Kooking wrote:
>> Hallo,
>>
>> I’m trying to track sensor data through the Arduino running on Maxmsp
>> 4.57 on Os 10.4.8, ibook g4 1,33ghz
>>
>> I’ve uploaded the firmware onto the board, works fine.
>>
>> I open Arduino2max and selected the port (b) and click start.
>>
>> I don’t receive any data. I don’t even get an error message on max
>> window. The rx and tx on the board blicks and blicks but no data. It
>> works fine on my friends computer but not mine. Could anyone help? I
>> hope that my computer not going on strike today!
>>
>> regards
>> dennis
>>


March 23, 2007 | 10:24 pm

> I really dig the pattr system and I would love to replace global
> sends and receives entirely with pattrs that bind relatively.

My understanding of pattr is that it is "limited" to UI objects, correct?

Is there any chance that selected data objects, such as value and coll,
could become pattrfied?


March 23, 2007 | 10:28 pm

> it stores a value in one place and all other locations
> where the value is needed bind to that place. In fact I want to
> come as close as I can to the behaviour of a standard variable in
> an OO programming language, which has many practical
advantages
> compared to global send/receives.

Perhaps I’m misreading you, but isn’t this what value does?


March 23, 2007 | 10:33 pm

On 23 mars 07, at 23:24, Arne Eigenfeldt wrote:

> Is there any chance that selected data objects, such as value and
> coll,
> could become pattrfied?

The @bindto attribute (or the middle outlet connection) is limited to
pattrfied objects, but the pattr object itself is not. You can send
whatever you want to it (int/float/list/symbols). For coll, it’s
another story though.

ej


March 23, 2007 | 11:43 pm

Not exactly, unless you count js and any object with attributes as a
UI object. There’s nothing exceptional about UI objects which makes
them compatible with pattr — they were simply the most sensible
objects to change to support the system. 3rd party developers could
add pattrification easily to their objects using the step-by-step
instructions in the SDK.

coll doesn’t lend itself so well to pattr: what is the value of a
coll object?

Other objects might. In that case, I would use pattr in its unbound
mode (make a loop with the object you want to track data for and
pattr — don’t worry – it won’t feed back). Whatever comes out of the
object’s outlet (say, the count of a counter, for instance), is the
value stored/recalled by pattr. Easy enough.

jb

Am 23.03.2007 um 23:24 schrieb Arne Eigenfeldt:

> My understanding of pattr is that it is "limited" to UI objects,
> correct?


March 24, 2007 | 1:32 pm

Quote: Jeremy Bernstein wrote on Sat, 24 March 2007 00:43
—————————————————-
> Not exactly, unless you count js and any object with attributes as a
> UI object. There’s nothing exceptional about UI objects which makes
> them compatible with pattr — they were simply the most sensible
> objects to change to support the system. 3rd party developers could
> add pattrification easily to their objects using the step-by-step
> instructions in the SDK.

Perhaps the reason why pattrification started with UI objects is that an object can currently expose only one value/list/symbol as its pattr. Pattrstorage etc can bind to ‘the object’, not to ‘one of the attributes of the object’. UI elements tend to have only one main value as opposed to for example [split]. You can’t choose one value to be -the- value of split.

Please correct me if I’m wrong..

Mattijs

> (don’t worry – it won’t feed back).

Which is truly a terrific feature.

> Whatever comes out of the
> object’s outlet (say, the count of a counter, for instance), is the
> value stored/recalled by pattr. Easy enough.
>
> jb
>
> Am 23.03.2007 um 23:24 schrieb Arne Eigenfeldt:
>
> > My understanding of pattr is that it is "limited" to UI objects,
> > correct?
>
>
—————————————————-


March 24, 2007 | 2:33 pm

Quote: arne wrote on Fri, 23 March 2007 23:28
—————————————————-
> > it stores a value in one place and all other locations
> > where the value is needed bind to that place. In fact I want to
> > come as close as I can to the behaviour of a standard variable in
> > an OO programming language, which has many practical
> advantages
> > compared to global send/receives.
>
> Perhaps I’m misreading you, but isn’t this what value does?
>
—————————————————-

No, value is always global. To use it in an object oriented way a variable needs a clearly defined scope.

But thinking about this a bit more it suddenly hit me that all along I’ve been talking about pattr as a variable whereas maybe [pv] is much more appropriate. Maybe [pattr] represents the function, not the variable.

The functionality pv lacks to fulfill the task of the object oriented variable is to be referenced from ‘outside’, meaning a level higher than the scope of the pv. But strictly speaking a variable should never be referenced directly from outside its scope. Reading and writing the variable should be done by means of a function. Hmm, interesting.

So let’s get back to the equivalent of an OO function in Max. It has to be an object that triggers an action if it receives input remotely or in its inlet. This cancels out pv and value. It needs to be bound to a scope (I assume that a subpatcher defines a new level of scope). So send/receive don’t work because they are global. Then there must be a way to reference it cross-level (cross-subpatcher). Which rules out pvar. I think that leaves us with pattr.

This sounds like pattr comes as close as currently possible to a function. It is a function with one argument. Heh, nice. I didn’t think about it like this before.

It looks like the time is getting near for "the big oo and max comparison" document. Idea for vade’s wiki, perhaps?

Best,
Mattijs

Btw the reason why I leave in- and outlets and patch cords out of the whole thing is that I can’t rely on them when patches get bigger. For small routines they are perfect, for macro connections they are close to useless (which is of course the reason that cycling introduced the send/receives).


March 24, 2007 | 5:29 pm


March 24, 2007 | 7:39 pm

Quote: jeanfrancois.charles wrote on Sat, 24 March 2007 18:29
—————————————————-
> Sorry for nearly hijacking the thread,

So let’s start a new thread :)

Mattijs


March 24, 2007 | 11:48 pm

> coll doesn’t lend itself so well to pattr: what is the value of a
> coll object?

It might be the name of the collection to which it is currently refering. I set up my data colls separately, and use the refer message quite a bit to change active data sets on the fly. It might be interesting to let pattr help with this.

mz


March 25, 2007 | 3:57 am

mzed wrote:
>> coll doesn’t lend itself so well to pattr: what is the value of a
>> coll object?
>
> It might be the name of the collection to which it is currently refering. I set up my data colls separately, and use the refer message quite a bit to change active data sets on the fly. It might be interesting to let pattr help with this.

Coll may not lend itself well to pattr, but I suspect pattrstorage might
lend itself well to coll… anyone tried making a coll-compatibility
wrapper abstraction yet? Anyone able to assess how possible this is?
Seems like a terribly useful project if it can be done. (Anyone done it
already?)

I’m guessing that with a sort of specification/data separation model
(shades of XML – what a coincidence), some very interesting things could
be done. Unfortunately I’m still getting acquainted with the pattr
family, so I don’t know if this is a dead end.


March 26, 2007 | 9:24 pm

Jeremy Bernstein schrieb:
> coll doesn’t lend itself so well to pattr: what is the value of a coll
> object?

Too bad, I was recently thinking there is a demand for a pattrcoll which
would just place the content of a coll inside the pattrstorage xml
strukture. This would be really handy…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


March 26, 2007 | 10:38 pm

Stefan Tiedje wrote:
> Too bad, I was recently thinking there is a demand for a pattrcoll which
> would just place the content of a coll inside the pattrstorage xml
> strukture. This would be really handy…

And *I* was thinking that you should create an abHaXion to do just
that… ;)

…who knows, you might even be able to earn a bounty for a project like
that.


March 27, 2007 | 8:40 am


March 27, 2007 | 9:19 pm

mzed schrieb:
>> coll doesn’t lend itself so well to pattr: what is the value of a
>> coll object?
>
> It might be the name of the collection to which it is currently
> refering. I set up my data colls separately, and use the refer
> message quite a bit to change active data sets on the fly. It might
> be interesting to let pattr help with this.

But thats possible already, just connect a umenu/ubumenu to the coll and
let this be remembered.
I’d rather like to have the content of the coll being pattrified… It
shouldn’t be too hard to embed the content of a coll into the
pattrstorage XML file and pass it back and forth. But it should not be
included automatically, thus I imagine an extra pattrcoll object which
would refer to a named coll… But within a preset system, there might
not be a need to communicate for each preset number the complete coll
content (which could be expensive), therefore there should be some
mechanism to control the storage/recall of the coll within a preset…

I would like to have the possibility to exclude some elements out of a
preset, in a way that they would not be written into the XML file. If
they are missing they would not be updated, and the file would not carry
unnecessary data… Maybe according to a kind of storage groups, group 0
store all, and a message like "group groupname list of pattrnames
anotherpattrname[1...16]" would set storage spaces… a store groupname
presetnumber would only store the elements of that group… Only
groupnames which are different than client names should be allowed to
not mix it up with the existing possibility to store a single client
value…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


March 27, 2007 | 10:40 pm

following this and the oo thread (and the "Managing Complex Patches in Max" article) i keep running into the notion that send/receive pairs are to be avoided. is this simply because of unpredictable message order/flow or is there a deeper reason (something i might have missed along the way) for this tactic?

andrew

http://www.miscellanea.com

> Or a tutorial "how to apply oo within Max". With advices, such as "don’t
> ever use a send/receive pair (except within the same level, with #0- at the
> beginning of the name, and only if you really really need it)"


March 28, 2007 | 8:04 am

Sentences like this are funny.

jb

Am 27.03.2007 um 23:19 schrieb Stefan Tiedje:

> It shouldn’t be too hard to embed the content of a coll into the
> pattrstorage XML file and pass it back and forth.


March 28, 2007 | 8:53 am

Ah, no it is not a technical issue, it’s only about managing your patch. But this only gets relevant when your patch gets really big. Let’s say from about 10,000 lines of code (in text format) ;)

For smaller patches I don’t see a reason to avoid send/receives. I guess the limit is when you stop knowing all of them by heart.

Mattijs

Quote: miscellanea wrote on Wed, 28 March 2007 00:40
—————————————————-
> following this and the oo thread (and the "Managing Complex Patches in Max" article) i keep running into the notion that send/receive pairs are to be avoided. is this simply because of unpredictable message order/flow or is there a deeper reason (something i might have missed along the way) for this tactic?
>
>
> andrew
> http://www.miscellanea.com
>
>
> > Or a tutorial "how to apply oo within Max". With advices, such as "don’t
> > ever use a send/receive pair (except within the same level, with #0- at the
> > beginning of the name, and only if you really really need it)"
>
>
—————————————————-


March 28, 2007 | 10:47 am

Andrew schrieb:
> following this and the oo thread (and the "Managing Complex Patches
> in Max" article) i keep running into the notion that send/receive
> pairs are to be avoided. is this simply because of unpredictable
> message order/flow or is there a deeper reason (something i might
> have missed along the way) for this tactic?

I don’t think they should be avoided completely. Its just better to
avoid send/receive pairs within abstractions which are loaded multiple
times within a main patcher for the simple reason they are global and if
you want a local communication you might run into unexpected results and
nameclashing…
But in general they are useful as global objects. What I do usually,
give them not so simple names like prepending with the name of the
project or something like that.
But if you use names like "start" or "stop" you might have a subpatcher
with the same receive object but differently intended use of the sent
messages…

But for example I use a global send object [s loadbang] I correctly
assume this is a loadbang like init receiver, if I send a bang to it,
the objects which carry it will reset to their loadbang status…
Simple, easy to remember and dangerous uahh…
(that’s why I love it… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


Viewing 26 posts - 1 through 26 (of 26 total)