Mattijs

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

pattr-performance-test

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.

Am 23.03.2007 um 16:36 schrieb Mattijs Kneppers:

> I'd say that basically the bound pattrs and the receives perform 

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.

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


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.

> I was running some framerate tests and I discovered that the use of 

> bound pattrs instead of send/receives can have much influence on 

> 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 

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

> Interactive audiovisual sampling soft- and hardware

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.

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


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.

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.

> Am 23.03.2007 um 16:36 schrieb Mattijs Kneppers:

> > I'd say that basically the bound pattrs and the receives perform 

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. 

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


I'm trying to track sensor data through the Arduino running on Maxmsp 

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!

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

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.

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.

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

> I'm trying to track sensor data through the Arduino running on Maxmsp

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

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
>


ah!!! i've downloaded the wrong version of arduino2max! stupid me...

Am 23.03.2007 um 18:54 schrieb Scott Fitzgerald:

>> I'm trying to track sensor data through the Arduino running on Maxmsp

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

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

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


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

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

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


> 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 

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

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


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

> Is there any chance that selected data objects, such as value and 

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 

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

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 

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

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.

Am 23.03.2007 um 23:24 schrieb Arne Eigenfeldt:

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

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.

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


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 

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.

> object's outlet (say, the count of a counter, for instance), is the 

> value stored/recalled by pattr. Easy enough.

> Am 23.03.2007 um 23:24 schrieb Arne Eigenfeldt:

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

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.

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


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 

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

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

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. 

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. 

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


Quote: jeanfrancois.charles wrote on Sat, 24 March 2007 18:29

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

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

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 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 doesn't lend itself so well to pattr: what is the value of a 

> 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 

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.

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.


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

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 

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> 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 

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

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.


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

> 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 

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 

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

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?

pattr performance test