Here's a first speed test patch that should compare the 3 methods for 

I'm quite suprised: the 3rd method seems to give the best result, but 

display this result far later after the 2 first methods...

PS: I'm trying to figure out what max data control system is the 

faster, to control sound looping in real time, even very short loops 

(grains). I'm not satisfied with preset, which don't allow me to 

control precisely the order of parameter launching.

Here's a first speed test patch that should compare the 3 methods for  
pattr system.
I'm quite suprised: the 3rd method seems to give the best result, but  
display this result far later after the 2 first methods...
Someone could explain?

PS: I'm trying to figure out what max data control system is the  
faster, to control sound looping in real time, even very short loops  
(grains). I'm not satisfied with preset, which don't allow me to  
control precisely the order of parameter launching.

actual-speed-of-max-data-control-systems

I don't know why, but it made me wonder about the way that my patches work.

I always use autopattr and talk directly to pattrstorage. I added it to your

testpatch. Surprisingly it slows down the other methods, but does turn out

I don't know why, but it made me wonder about the way that my patches work.
I always use autopattr and talk directly to pattrstorage. I added it to your
testpatch. Surprisingly it slows down the other methods, but does turn out
to be the fastest one of them all.

Almost same effect here (ibook G4 933, OSX10.4.5, MaxMSP4.5.6): it 

slows down the other methods, except that pattrhub goes on displaying 

the best result, three times faster as pattrstorage... Are your 

Almost same effect here (ibook G4 933, OSX10.4.5, MaxMSP4.5.6): it  
slows down the other methods, except that pattrhub goes on displaying  
the best result, three times faster as pattrstorage... Are your  
computer/OS/MaxMSP very different?

Thanks for your patch. I was astonished to learn that pattrhub was the 

fastest and, after taking a look at the patch and the object code, found 

a problem which was causing this weird result. I've posted an 

https://cycling74.com/twiki/bin/view/IncrementalDownloads

Note that this version of the object is likely only compatible with Max 

4.5.7 and higher, due to a change in the patcher-resolution code 

introduced for that release, but it might work for earlier versions, too.

Thanks for your patch. I was astonished to learn that pattrhub was the 
fastest and, after taking a look at the patch and the object code, found 
a problem which was causing this weird result. I've posted an 
incremental update to pattrhub to:

  https://cycling74.com/twiki/bin/view/IncrementalDownloads

Note that this version of the object is likely only compatible with Max 
4.5.7 and higher, due to a change in the patcher-resolution code 
introduced for that release, but it might work for earlier versions, too.

Pattrhub shows the lowest timer value, but I don't think this is a good

performance indication, because besides the long delay there is also a big

hit on my cpu, compared to the other methods (about 30 to

40% against a hardly noticeable amount for the others). I'm mystified. Maybe

Jeremy can explain? I'm using a pentium M1,86 / max 4.5.7. The results I get

Pattrhub shows the lowest timer value, but I don't think this is a good
performance indication, because besides the long delay there is also a big
hit on my cpu, compared to the other methods (about 30 to
40% against a hardly noticeable amount for the others). I'm mystified. Maybe
Jeremy can explain? I'm using a pentium M1,86 / max 4.5.7. The results I get
from the timers are 57 / 42 / 5 / 21.

Presumably you saw the message about the new pattrhub (it took a while 

to show up on the list/forum). The problem was a bug in pattrhub, which 

As to why adding an autopattr to the patch slows the other objects down, 

Presumably you saw the message about the new pattrhub (it took a while 
to show up on the list/forum). The problem was a bug in pattrhub, which 
is _not_ the fastest variant after all.

As to why adding an autopattr to the patch slows the other objects down, 
that's a puzzle I will look into.

Ok. I'll write back as soon as I'll have updated my maxmsp to the 

4.5.7 version, and test your new pattrhub.

I'll also take a look at the amount of cpu for each method...

Ok. I'll write back as soon as I'll have updated my maxmsp to the  
4.5.7 version, and test your new pattrhub.
I'll also take a look at the amount of cpu for each method...
K.


Thanks Jeremy, it works, but here's another :

If you get rid of autopattr, the other methods speed up again, but... the

last one still works (?). Even stranger... it works almost twice as fast! If

you check the clientwindow tata doesn't show up, but sending "tata 1" still

sets tata to 1. I hope this helps you with your puzzle:-) It would be nice

to retain the same speed, as I now get 12ms instead of 21ms on the last

If you get rid of autopattr, the other methods speed up again, but... the
last one still works (?). Even stranger... it works almost twice as fast! If
you check the clientwindow tata doesn't show up, but sending "tata 1" still
sets tata to 1. I hope this helps you with your puzzle:-) It would be nice
to retain the same speed, as I now get 12ms instead of 21ms on the last
option.

This is normal: sending the name of an object that pattrstorage can find 

(whether "revealed" to pattrstorage via autopattr, pattr or not), plus a 

value will set the value of that named object, if possible.

The reason why the autopattr/pattrstorage object slows the patch down is 

this: there are several named number boxes in the patch (number, 

number[1], tutunum and tata). Every time the value of this box changes 

(so 9999 times in this case), autopattr/pattrstorage receives a 

notification of this change. So, if you have the autopattr, you need to 

use its include inlet to include only the number box you want. This 

Without the autopattr, there's no feedback -- the change in the number 

box isn't sent to any other objects. Therefore, it's the fastest.

autopattr including everything + pattrstorage

Medium is (and comparable to everything else):

autopattr including only the targeted obejct + pattrstorage

pattrstorage only (but useless, unless you just want to send messages to 

objects without knowing their values as they change)

This is normal: sending the name of an object that pattrstorage can find 
(whether "revealed" to pattrstorage via autopattr, pattr or not), plus a 
value will set the value of that named object, if possible.

The reason why the autopattr/pattrstorage object slows the patch down is 
this: there are several named number boxes in the patch (number, 
number[1], tutunum and tata). Every time the value of this box changes 
(so 9999 times in this case), autopattr/pattrstorage receives a 
notification of this change. So, if you have the autopattr, you need to 
use its include inlet to include only the number box you want. This 
speeds things up a bit.

Without the autopattr, there's no feedback -- the change in the number 
box isn't sent to any other objects. Therefore, it's the fastest.

So, slowest is:
autopattr including everything + pattrstorage

Medium is (and comparable to everything else):
autopattr including only the targeted obejct + pattrstorage

Fastest is:
pattrstorage only (but useless, unless you just want to send messages to 
objects without knowing their values as they change)

Thanks for explaining this. It all makes perfect sense. Using

autopattr including 512 named numberboxes against 1 is not even doubling the

processing time (25 against 16 ms), so I'm not worried about that.

Thanks for explaining this. It all makes perfect sense. Using
autopattr including 512 named numberboxes against 1 is not even doubling the
processing time (25 against 16 ms), so I'm not worried about that.

Here's a new testpatch that disapointed me a bit: preset VS coll VS 

pattrstorage (with autopattr include links...). This is a basic patch 

with only 4 "parameters" to be remembered for each method, and I know 

the results may be different with a greater number of data, but here 

pattrstorage seems to me inefficent, is it? Could you tell me which 

way you personnaly prefer to manage audio parameters for time 

NB: I installed both max457 and the new pattrhub: its displaying 

I noticed that pattrstorage is not to be able to find by itself 

(without any pattr or autopattr) a named object in a subpatch. 

Moreover, this method remains slower than send/receive...

Here's a new testpatch that disapointed me a bit: preset VS coll VS  
pattrstorage (with autopattr include links...). This is a basic patch  
with only 4 "parameters" to be remembered for each method, and I know  
the results may be different with a greater number of data, but here  
pattrstorage seems to me inefficent, is it? Could you tell me which  
way you personnaly prefer to manage audio parameters for time  
critical apps?
K.

NB: I installed both max457 and the new pattrhub: its displaying  
delay has disappeared, thanks jb. :-)
I noticed that pattrstorage is not to be able to find by itself  
(without any pattr or autopattr) a named object in a subpatch.  
Moreover, this method remains slower than send/receive...

No one ever said that pattrstorage is faster than send/receive or 

preset. How it functions is much more indirect than those two objects, 

so it would be expected (at least from me), that it would be slower. 

There are probably some additional optimizations that could be made, but 

at the moment, it works as fast as we could get it, given the 

And I would say it's fast enough for most tasks -- 75 ms for 9999 * 4 

messages restored is really quite fast (this is on my PBG4). It's not 

functioning at audio rate, but then again, neither are send or receive 

(nor would a receiving object get the message more than once per signal 

vector, even if it were, unless it were sending signal vectors itself, 

So... if you can come up with a patch in which the speed of pattrstorage 

vs. the speed of preset or send and receive actually has a demonstrable 

negative effect, I'll look closely at it. Otherwise, this is a purely 

intellectual exercise. I think that your time would be better spent 

making work than worrying about how fast messages are being passed.

As for the pattrstorage not finding objects in subpatchers -- you mean 

you can't send a message to an object in a subpatcher via pattrstorage 

(this is possible, and I just tested that it works), or that 

pattrstorage doesn't add those objects to its clientlist (that is 

correct -- you need a pattr or an autopattr object to reveal objects to 

And just FYI, "inefficient" is kind of a strong word in the ear of a 

developer, especially when the person saying it doesn't have access to 

the code involved. I realize it wasn't meant that way, but just so you know.

No one ever said that pattrstorage is faster than send/receive or 
preset. How it functions is much more indirect than those two objects, 
so it would be expected (at least from me), that it would be slower. 
There are probably some additional optimizations that could be made, but 
  at the moment, it works as fast as we could get it, given the 
challenges involved.

And I would say it's fast enough for most tasks -- 75 ms for 9999 * 4 
messages restored is really quite fast (this is on my PBG4). It's not 
functioning at audio rate, but then again, neither are send or receive 
(nor would a receiving object get the message more than once per signal 
vector, even if it were, unless it were sending signal vectors itself, 
which it isn't).

So... if you can come up with a patch in which the speed of pattrstorage 
vs. the speed of preset or send and receive actually has a demonstrable 
negative effect, I'll look closely at it. Otherwise, this is a purely 
intellectual exercise. I think that your time would be better spent 
making work than worrying about how fast messages are being passed.

As for the pattrstorage not finding objects in subpatchers -- you mean 
you can't send a message to an object in a subpatcher via pattrstorage 
(this is possible, and I just tested that it works), or that 
pattrstorage doesn't add those objects to its clientlist (that is 
correct -- you need a pattr or an autopattr object to reveal objects to 
pattrstorage)?

And just FYI, "inefficient" is kind of a strong word in the ear of a 
developer, especially when the person saying it doesn't have access to 
the code involved. I realize it wasn't meant that way, but just so you know.

I don't think its fair to compare pattrstorage in this way. First of all

pattrstorage is not comparable to preset or coll when it comes to

functionality, state management, or reliability. Second you're testing only

a few parameters, but 9999 triggers. Like I wrote before, using 512

parameters still gives me about the same performance compared to 1.

Coll will certainly increase as it actually is pretty slow on larger amounts

of data (and using a seperate coll for every parameters really sounds like a

bad idea). I don't know about preset, besides that it just sucks compared to

On my computer pattr can set 512 parameters 9999 times in 24 ms that's

0.0024 ms for changing all of the parameters once. How is that going to give

you problems with time critical apps? If you really want the best

performance and timing use s/r to drive parameters, as they are designed for

I don't think its fair to compare pattrstorage in this way. First of all
pattrstorage is not comparable to preset or coll when it comes to
functionality, state management, or reliability. Second you're testing only
a few parameters, but 9999 triggers. Like I wrote before, using 512
parameters still gives me about the same performance compared to 1.
Coll will certainly increase as it actually is pretty slow on larger amounts
of data (and using a seperate coll for every parameters really sounds like a
bad idea). I don't know about preset, besides that it just sucks compared to
pattr.

On my computer pattr can set 512 parameters 9999 times in 24 ms that's
0.0024 ms for changing all of the parameters once. How is that going to give
you problems with time critical apps? If you really want the best
performance and timing use s/r to drive parameters, as they are designed for
that purpose.

There's no way that pattrstorage interpolation could be as fast as 

jit.xfade -- it's a comparison of apples and elephants, really.

jit.xfade runs through 2 tables of consecutive-in-memory-space numbers 

and performs a linear interpolation between these two numbers.

pattrstorage has to do a hash table lookup in order to retrieve the 

value of each client object at 2 data points, compare the number of 

items in each value and perform one of several types of interpolation on 

one or more values. It then has to check if @changemode is enabled and, 

based on the results of the interpolation, send the value, or not.

This is no contest -- jit.xfade will win out in every case.

So, if your data is such that jit.xfade does the trick for you, you 

should probably use it. But there's nothing to be fixed here, I don't 

think. Go ahead and send me more details (your patch exhibits some 

problems, though -- interpolate to 100% and then back down), if you 

There's no way that pattrstorage interpolation could be as fast as 
jit.xfade -- it's a comparison of apples and elephants, really.

jit.xfade runs through 2 tables of consecutive-in-memory-space numbers 
and performs a linear interpolation between these two numbers.

pattrstorage has to do a hash table lookup in order to retrieve the 
value of each client object at 2 data points, compare the number of 
items in each value and perform one of several types of interpolation on 
one or more values. It then has to check if @changemode is enabled and, 
based on the results of the interpolation, send the value, or not.

So, if your data is such that jit.xfade does the trick for you, you 
should probably use it. But there's nothing to be fixed here, I don't 
think. Go ahead and send me more details (your patch exhibits some 
problems, though -- interpolate to 100% and then back down), if you 
like, though.

First of all, I'm grateful you for your answers, and please excuse me 

for strong words I used like "inefficient", to write in english is 

for me a difficult exercise. I didn't want to be unfair.

Maybe I should have told you that I've been working for 2 years on a 

msp patch on looping principles, with a composer. We named it 

CircularBox. I already knew about radiaL (and live), but we wanted to 

explore some other things... This patch is too big for the list, but 

karim.barkati.online.fr/Universite/Doctorat/JIM2005/JIM2005_ 5-4.htm 

(text in french), and I could send the whole (mac) folder of my app 

My last posts aren't a pure intellectual exercice, I simply would 

like to be sure of what kind of data control system is the more 

adapted to our needs. The last time we tried to show the soft (based 

on preset), we totaly failed listening what we expected. The current 

version is unable to manage short durations of sound (buffer~) on my 

ibook G4, but we are still interested in using both micro and macro 

sounds (say 10ms to 10mn). I guess I made wrong choices while coding, 

that's why, before giving this project a 2nd chance, I'm testing the 

different possibilities max offers. I thought preset was a reason of 

the certain slowness of my patch, I didn't know wether I'd rather use 

pattrstorage or not. I now feel like using pattrstorage with its 

useful order recall capabilities. I understand that the ideal limit 

of messages speed is the vector size, also related to the cpu, and 

that the practical limit depends of many things.

> As for the pattrstorage not finding objects in subpatchers -- you 

> mean you can't send a message to an object in a subpatcher via 

> pattrstorage (this is possible, and I just tested that it works), 

> or that pattrstorage doesn't add those objects to its clientlist 

> (that is correct -- you need a pattr or an autopattr object to 

This following patch shows what I meant about pattrstorage *alone* 

(without any pattr or autopattr), sending messages to objects in the 

same patch but not in subpatches, but that's not very important.

First of all, I'm grateful you for your answers, and please excuse me  
for strong words I used like "inefficient", to write in english is  
for me a difficult exercise. I didn't want to be unfair.

Maybe I should have told you that I've been working for 2 years on a  
msp patch on looping principles, with a composer. We named it  
CircularBox. I already knew about radiaL (and live), but we wanted to  
explore some other things... This patch is too big for the list, but  
there's a picture of the main screen at http:// 
 karim.barkati.online.fr/Universite/Doctorat/JIM2005/JIM2005_ 5-4.htm  
(text in french), and I could send the whole (mac) folder of my app  
off list.

My last posts aren't a pure intellectual exercice, I simply would  
like to be sure of what kind of data control system is the more  
adapted to our needs. The last time we tried to show the soft (based  
on preset), we totaly failed listening what we expected.  The current  
version is unable to manage short durations of sound (buffer~) on my  
ibook G4, but we are still interested in using both micro and macro  
sounds (say 10ms to 10mn). I guess I made wrong choices while coding,  
that's why, before giving this project a 2nd chance, I'm testing the  
different possibilities max offers. I thought preset was a reason of  
the certain slowness of my patch, I didn't know wether I'd rather use  
pattrstorage or not. I now feel like using pattrstorage with its  
useful order recall capabilities. I understand that the ideal limit  
of messages speed is the vector size, also related to the cpu, and  
that the practical limit depends of many things.

> As for the pattrstorage not finding objects in subpatchers -- you  
> mean you can't send a message to an object in a subpatcher via  
> pattrstorage (this is possible, and I just tested that it works),  
> or that pattrstorage doesn't add those objects to its clientlist  
> (that is correct -- you need a pattr or an autopattr object to  
> reveal objects to pattrstorage)?

This following patch shows what I meant about pattrstorage *alone*  
(without any pattr or autopattr), sending messages to objects in the  
same patch but not in subpatches, but that's not very important.

mmm... so I guess I will use more of that xfade trick as it seems to be 

the most efficient way of interpolating, given this information.

There was a missing part in the excerpt I sent, that does the storage in 

the temporary matrix, before going to a new preset target,

However, if banging the actual position in the "PreviousPreset" matrix, 

and setting the slider to 0 at that moment, this solution allows to stop 

between 2 presets and go to a new preset from that actual position.

I used to do it with Pattstorage by storing the *in between* position to 

slot 0 of pattrstorage, and then do "recall 0 TargetPreset, Position".

mmm... so I guess I will use more of that xfade trick as it seems to be 
the most efficient way of interpolating, given this information.
There was a missing part in the excerpt I sent, that does the storage in 
the temporary matrix, before going to a new preset target,
and reach 100%.
However, if banging the actual position in the "PreviousPreset" matrix, 
and setting the slider to 0 at that moment, this solution allows to stop 
between 2 presets and go to a new preset from that actual position.
I used to do it with Pattstorage by storing the *in between* position to 
slot 0 of pattrstorage, and then do "recall 0 TargetPreset, Position".
Thanks for the detailed explanations.
vincent


Here's your patch, revised so that it works: you might want to take a 

quick look at the tutorial chapters about pattr again -- named objects 

are local to patchers, so if you want to talk to a named object inside 

of another patcher, you need to give the patcher a name, and write the 

whole path to the object, in order to talk to it, as shown.

Here's your patch, revised so that it works: you might want to take a 
quick look at the tutorial chapters about pattr again -- named objects 
are local to patchers, so if you want to talk to a named object inside 
of another patcher, you need to give the patcher a name, and write the 
whole path to the object, in order to talk to it, as shown.

I'll soon try to rewrite my old patch with pattrstorage instead of 

Actual speed of max data control systems?