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

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.

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

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

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

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

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
>

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

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?

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

> 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

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?

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

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

So let’s start a new thread :)

Mattijs

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

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.

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

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.

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

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

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.

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)”
>
>
—————————————————-