Forums > MaxMSP

Actual speed of max data control systems?


kb
March 17, 2006 | 10:02 am

Hello,

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.

K.

max v2;
#N vpatcher 162 236 903 517;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 4 158 68 196617 name: number;
#P comment 340 187 83 196617 name: number[1];
#P message 286 126 14 196617 1;
#P message 286 187 14 196617 0;
#P message 484 210 14 196617 0;
#P message 78 158 14 196617 0;
#P message 472 126 37 196617 tutu 1;
#P newex 486 158 48 196617 pattrhub;
#P objectname titi[1];
#P button 486 35 15 0;
#P newex 486 68 74 196617 b 2;
#P newex 512 126 33 196617 delay;
#P number 550 158 74 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 550 126 34 196617 timer;
#P newex 486 93 50 196617 uzi 9999;
#P newex 485 187 131 196617 pattr tutu @bindto tutunum;
#X prestore 1 0 0;
#P objectname tutu;
#P number 500 210 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tutunum;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 95 210 73 1441802 prepend set;
#P window setfont "Sans Serif" 9.;
#P newex 302 158 50 196617 pattr titi;
#X prestore 1 0 1;
#P objectname titi;
#P number 302 187 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname number[1];
#P newex 95 187 54 196617 pattr toto;
#X prestore 1 0 0;
#P objectname toto;
#P button 302 35 15 0;
#P newex 302 68 74 196617 b 2;
#P newex 328 126 33 196617 delay;
#P number 366 158 74 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 366 126 34 196617 timer;
#P newex 302 126 21 196617 1;
#P newex 302 93 50 196617 uzi 9999;
#P number 95 158 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname number;
#P button 95 35 15 0;
#P newex 95 68 74 196617 b 2;
#P newex 121 126 33 196617 delay;
#P number 159 158 74 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 159 126 34 196617 timer;
#P newex 95 126 21 196617 1;
#P newex 95 93 50 196617 uzi 9999;
#P comment 536 210 76 196617 name: tutunum;
#P window linecount 5;
#P comment 590 92 106 196617 Why does it take so much time to display
the (good) result of timer? Is this 3rd method faster or not?;
#P connect 8 0 7 0;
#P connect 7 0 2 0;
#P connect 2 0 3 0;
#P fasten 20 0 9 0 100 236 74 236 74 149 100 149;
#P connect 3 0 9 0;
#P connect 31 0 9 0;
#P connect 9 0 17 0;
#P connect 17 0 20 0;
#P connect 2 1 6 0;
#P connect 7 1 4 0;
#P connect 4 0 5 0;
#P connect 6 0 4 1;
#P connect 16 0 15 0;
#P connect 15 0 10 0;
#P connect 10 0 11 0;
#P connect 11 0 19 0;
#P connect 34 0 19 0;
#P connect 19 0 18 0;
#P connect 33 0 18 0;
#P connect 10 1 14 0;
#P connect 15 1 12 0;
#P connect 12 0 13 0;
#P connect 14 0 12 1;
#P connect 23 0 30 0;
#P connect 28 0 27 0;
#P connect 27 0 23 0;
#P connect 30 0 29 0;
#P connect 32 0 21 0;
#P connect 23 1 26 0;
#P connect 27 1 24 0;
#P connect 24 0 25 0;
#P connect 26 0 24 1;
#P pop;


March 17, 2006 | 11:42 am

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.

Thijs

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 64 218 68 9109513 name: number;
#P comment 400 247 83 9109513 name: number[1];
#P message 346 186 14 9109513 1;
#P message 346 247 14 9109513 0;
#P message 544 270 14 9109513 0;
#P message 138 218 14 9109513 0;
#P message 532 186 37 9109513 tutu 1;
#P newex 546 218 48 9109513 pattrhub;
#P objectname titi[1];
#P button 546 95 15 0;
#P newex 546 128 74 9109513 b 2;
#P newex 572 186 33 9109513 delay;
#P number 610 218 74 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 610 186 34 9109513 timer;
#P newex 546 153 50 9109513 uzi 9999;
#P newex 545 247 131 9109513 pattr tutu @bindto tutunum;
#X prestore 1 0 1;
#P objectname tutu;
#P number 560 270 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tutunum;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 155 270 73 9240586 prepend set;
#P window setfont "Sans Serif" 9.;
#P newex 362 218 50 9109513 pattr titi;
#X prestore 1 0 1;
#P objectname titi;
#P number 362 247 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname number[1];
#P newex 155 247 54 9109513 pattr toto;
#X prestore 1 0 1;
#P objectname toto;
#P button 362 95 15 0;
#P newex 362 128 74 9109513 b 2;
#P newex 388 186 33 9109513 delay;
#P number 426 218 74 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 426 186 34 9109513 timer;
#P newex 362 186 21 9109513 1;
#P newex 362 153 50 9109513 uzi 9999;
#P number 155 218 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname number;
#P button 155 95 15 0;
#P newex 155 128 74 9109513 b 2;
#P newex 181 186 33 9109513 delay;
#P number 219 218 74 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 219 186 34 9109513 timer;
#P newex 155 186 21 9109513 1;
#P newex 155 153 50 9109513 uzi 9999;
#P comment 596 270 76 9109513 name: tutunum;
#P window linecount 5;
#P comment 650 152 106 9109513 Why does it take so much time to display the
(good) result of timer? Is this 3rd method faster or not?;
#P window linecount 1;
#P message 820 312 14 9109513 0;
#P message 818 186 37 9109513 tata 1;
#P newex 818 218 62 9109513 pattrstorage;
#X client_rect 0 0 640 240;
#X storage_rect 0 0 640 240;
#P objectname u490000016;
#P button 832 95 15 0;
#P newex 832 128 74 9109513 b 2;
#P newex 858 186 33 9109513 delay;
#P number 896 218 74 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 896 186 34 9109513 timer;
#P newex 832 153 50 9109513 uzi 9999;
#P newex 819 273 62 9109513 autopattr;
#X prestore number 1 0 1;
#X prestore number[1] 1 0 1;
#X prestore tata 1 0 1;
#X prestore tutunum 1 0 1;
#P objectname u124000017;
#P number 836 312 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tata;
#P comment 869 312 76 9109513 name: tata;
#P window linecount 4;
#P comment 938 149 106 9109513 this slows down the other ones , but turns
out to be the fastest on my system;
#P connect 7 0 5 1;
#P connect 5 0 6 0;
#P connect 8 1 5 0;
#P connect 4 1 7 0;
#P connect 12 0 2 0;
#P connect 8 0 4 0;
#P connect 9 0 8 0;
#P connect 11 0 10 0;
#P connect 4 0 11 0;
#P connect 21 0 20 0;
#P connect 20 0 15 0;
#P connect 15 0 16 0;
#P connect 44 0 22 0;
#P connect 16 0 22 0;
#P fasten 33 0 22 0 160 296 134 296 134 209 160 209;
#P connect 22 0 30 0;
#P connect 30 0 33 0;
#P connect 15 1 19 0;
#P connect 20 1 17 0;
#P connect 17 0 18 0;
#P connect 19 0 17 1;
#P connect 29 0 28 0;
#P connect 28 0 23 0;
#P connect 23 0 24 0;
#P connect 47 0 32 0;
#P connect 24 0 32 0;
#P connect 46 0 31 0;
#P connect 32 0 31 0;
#P connect 23 1 27 0;
#P connect 28 1 25 0;
#P connect 25 0 26 0;
#P connect 27 0 25 1;
#P connect 36 0 43 0;
#P connect 41 0 40 0;
#P connect 40 0 36 0;
#P connect 43 0 42 0;
#P connect 45 0 34 0;
#P connect 36 1 39 0;
#P connect 40 1 37 0;
#P connect 37 0 38 0;
#P connect 39 0 37 1;
#P window clipboard copycount 50;



kb
March 17, 2006 | 2:23 pm

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?

K.


March 18, 2006 | 10:06 am

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:

http://www.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.

jb


March 18, 2006 | 10:24 am

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.

Thijs


March 18, 2006 | 10:43 pm

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.

jb



kb
March 18, 2006 | 11:28 pm

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.


March 19, 2006 | 11:55 am

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

best, t_

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 848 256 67 9109513 clientwindow;
#P comment 64 218 68 9109513 name: number;
#P comment 400 247 83 9109513 name: number[1];
#P message 346 186 14 9109513 1;
#P message 346 247 14 9109513 0;
#P message 544 270 14 9109513 0;
#P message 138 218 14 9109513 0;
#P message 532 186 37 9109513 tutu 1;
#P newex 546 218 48 9109513 pattrhub;
#P objectname titi[1];
#P button 546 95 15 0;
#P newex 546 128 74 9109513 b 2;
#P newex 572 186 33 9109513 delay;
#P number 610 218 74 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 610 186 34 9109513 timer;
#P newex 546 153 50 9109513 uzi 9999;
#P newex 545 247 131 9109513 pattr tutu @bindto tutunum;
#X prestore 1 0 1;
#P objectname tutu;
#P number 560 270 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tutunum;
#P window setfont "Fixedwidth Serif" 10.;
#P newex 155 270 73 9240586 prepend set;
#P window setfont "Sans Serif" 9.;
#P newex 362 218 50 9109513 pattr titi;
#X prestore 1 0 1;
#P objectname titi;
#P number 362 247 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname number[1];
#P newex 155 247 54 9109513 pattr toto;
#X prestore 1 0 1;
#P objectname toto;
#P button 362 95 15 0;
#P newex 362 128 74 9109513 b 2;
#P newex 388 186 33 9109513 delay;
#P number 426 218 74 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 426 186 34 9109513 timer;
#P newex 362 186 21 9109513 1;
#P newex 362 153 50 9109513 uzi 9999;
#P number 155 218 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname number;
#P button 155 95 15 0;
#P newex 155 128 74 9109513 b 2;
#P newex 181 186 33 9109513 delay;
#P number 219 218 74 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 219 186 34 9109513 timer;
#P newex 155 186 21 9109513 1;
#P newex 155 153 50 9109513 uzi 9999;
#P comment 596 270 76 9109513 name: tutunum;
#P window linecount 5;
#P comment 650 152 106 9109513 Why does it take so much time to display the
(good) result of timer? Is this 3rd method faster or not?;
#P window linecount 1;
#P message 820 312 14 9109513 0;
#P message 818 186 37 9109513 tata 1;
#P newex 818 218 62 9109513 pattrstorage;
#X client_rect 15 55 655 295;
#X storage_rect 0 0 640 240;
#P objectname u967000001;
#P button 832 95 15 0;
#P newex 832 128 74 9109513 b 2;
#P newex 858 186 33 9109513 delay;
#P number 896 218 74 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 896 186 34 9109513 timer;
#P newex 832 153 50 9109513 uzi 9999;
#P number 836 312 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tata;
#P comment 869 312 76 9109513 name: tata;
#P window linecount 4;
#P comment 938 149 106 9109513 this slows down the other ones , but turns
out to be the fastest on my system;
#P window linecount 2;
#P comment 849 275 100 9109513 tata is missing , but can still be
controlled!;
#P connect 21 0 20 0;
#P connect 20 0 15 0;
#P connect 15 0 16 0;
#P connect 44 0 22 0;
#P connect 16 0 22 0;
#P fasten 33 0 22 0 160 296 134 296 134 209 160 209;
#P connect 22 0 30 0;
#P connect 30 0 33 0;
#P connect 15 1 19 0;
#P connect 20 1 17 0;
#P connect 17 0 18 0;
#P connect 19 0 17 1;
#P connect 29 0 28 0;
#P connect 28 0 23 0;
#P connect 23 0 24 0;
#P connect 47 0 32 0;
#P connect 24 0 32 0;
#P connect 46 0 31 0;
#P connect 32 0 31 0;
#P connect 23 1 27 0;
#P connect 28 1 25 0;
#P connect 25 0 26 0;
#P connect 27 0 25 1;
#P connect 36 0 43 0;
#P connect 41 0 40 0;
#P connect 40 0 36 0;
#P connect 43 0 42 0;
#P connect 45 0 34 0;
#P connect 36 1 39 0;
#P connect 40 1 37 0;
#P connect 37 0 38 0;
#P connect 39 0 37 1;
#P connect 4 0 11 0;
#P connect 11 0 10 0;
#P connect 50 0 10 0;
#P connect 9 0 8 0;
#P connect 8 0 4 0;
#P connect 12 0 3 0;
#P connect 4 1 7 0;
#P connect 8 1 5 0;
#P connect 5 0 6 0;
#P connect 7 0 5 1;
#P window clipboard copycount 51;


March 19, 2006 | 1:12 pm

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)

I think there’s no more puzzle.

jb


March 19, 2006 | 2:11 pm

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.

best, t_



kb
March 20, 2006 | 10:32 am

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…

max v2;
#N vpatcher 168 282 922 551;
#P window setfont "Sans Serif" 9.;
#P comment 547 23 100 196617 slower :-(;
#P comment 359 23 100 196617 medium…;
#P message 97 119 14 196617 1;
#P number 661 212 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname cake;
#P number 622 212 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname heavy;
#P number 583 212 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname quite;
#P newex 287 119 64 196617 append 1;
#P newex 287 73 50 196617 loadbang;
#P newex 287 96 40 196617 uzi 4;
#P newex 356 169 32 196617 s foo;
#P objectname u485000005[1];
#P message 356 119 14 196617 1;
#N coll ;
#P newobj 356 146 53 196617 coll;
#P objectname u336000004;
#P button 370 39 15 0;
#P newex 370 73 74 196617 b 2;
#P newex 396 119 33 196617 delay;
#P number 434 146 44 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 434 119 34 196617 timer;
#P newex 370 96 50 196617 uzi 9999;
#P number 356 212 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname foonum;
#P newex 356 191 32 196617 r foo;
#P objectname u485000005;
#P message 544 119 22 196617 a 1;
#P newex 544 146 62 196617 pattrstorage;
#X client_rect 139 406 779 646;
#X storage_rect 0 0 640 240;
#P objectname u668000015;
#P button 558 39 15 0;
#P newex 558 73 74 196617 b 2;
#P newex 584 119 33 196617 delay;
#P number 622 146 44 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 622 119 34 196617 timer;
#P newex 558 96 50 196617 uzi 9999;
#P number 544 212 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname a;
#P newex 544 169 53 196617 autopattr;
#X prestore a 1 0 1;
#X prestore cake 1 0 0;
#X prestore heavy 1 0 0;
#X prestore quite 1 0 0;
#P objectname u490000016;
#P message 28 96 14 196617 1;
#P message 28 119 49 196617 store $1;
#P newex 28 73 50 196617 loadbang;
#P button 97 39 15 0;
#P newex 97 73 73 196617 b 2;
#P newex 122 119 33 196617 delay;
#P number 160 146 74 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 160 119 34 196617 timer;
#P newex 97 96 50 196617 uzi 9999;
#P number 97 195 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N vpreset 248;
#X append 1 1 2 195 97 number int 19 ;;
#X append 2 1 2 195 97 number int 0 ;;
#X append 3 1 2 195 97 number int 0 ;;
#X append 4 1 2 195 97 number int 0 ;;
#P preset 97 146 29 29;
#P comment 89 23 100 196617 faster;
#P connect 9 0 11 0;
#P connect 11 0 10 0;
#P connect 8 0 7 0;
#P connect 7 0 3 0;
#P connect 3 0 39 0;
#P connect 39 0 1 0;
#P connect 10 0 1 0;
#P connect 1 0 2 0;
#P connect 3 1 6 0;
#P connect 7 1 4 0;
#P connect 4 0 5 0;
#P connect 6 0 4 1;
#P connect 34 0 33 0;
#P connect 33 2 35 0;
#P connect 24 0 31 0;
#P connect 31 0 30 0;
#P connect 35 0 30 0;
#P connect 30 0 32 0;
#P connect 22 0 23 0;
#P connect 29 0 28 0;
#P connect 28 0 24 0;
#P connect 24 1 27 0;
#P connect 28 1 25 0;
#P connect 25 0 26 0;
#P connect 27 0 25 1;
#P connect 14 0 21 0;
#P connect 21 0 20 0;
#P connect 12 0 13 0;
#P connect 19 0 18 0;
#P connect 18 0 14 0;
#P connect 12 0 36 0;
#P connect 14 1 17 0;
#P connect 18 1 15 0;
#P connect 15 0 16 0;
#P connect 12 0 37 0;
#P connect 17 0 15 1;
#P connect 12 0 38 0;
#P pop;


March 20, 2006 | 11:09 am

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.

jb


March 20, 2006 | 11:16 am

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.

Thijs



VG
March 20, 2006 | 11:58 am


March 20, 2006 | 12:28 pm

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
like, though.

jb



kb
March 20, 2006 | 12:55 pm

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.

max v2;
#N vpatcher -2 47 387 279;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 37 54 37 196617 tete 1;
#N vpatcher 26 307 320 438;
#P window setfont "Sans Serif" 9.;
#P message 60 60 14 196617 0;
#P number 76 60 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tete;
#P comment 114 60 76 196617 name: tete;
#P connect 2 0 1 0;
#P pop;
#P newobj 105 166 74 196617 p remote_tete;
#P message 177 54 67 196617 clientwindow;
#P message 88 137 14 196617 0;
#P message 105 54 37 196617 tata 1;
#P newex 105 86 62 196617 pattrstorage;
#X client_rect 50 475 690 715;
#X storage_rect 0 0 640 240;
#P objectname u024000024;
#P number 105 137 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tata;
#P comment 145 137 76 196617 name: tata;
#P window linecount 2;
#P comment 177 72 137 196617 tata is missing , but can still be
controlled! Not tete.;
#P connect 8 0 3 0;
#P connect 6 0 3 0;
#P connect 4 0 3 0;
#P connect 5 0 2 0;
#P pop;



VG
March 20, 2006 | 2:05 pm

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


March 20, 2006 | 2:13 pm

No worries — just pointing it out.

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.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 44 61 63 196617 rem::tete 1;
#N vpatcher 26 307 320 438;
#P window setfont "Sans Serif" 9.;
#P message 60 60 14 196617 0;
#P number 76 60 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tete;
#P comment 114 60 76 196617 name: tete;
#P connect 2 0 1 0;
#P pop;
#P newobj 112 173 74 196617 p remote_tete;
#P objectname rem;
#P message 184 61 67 196617 clientwindow;
#P message 95 144 14 196617 0;
#P message 112 61 37 196617 tata 1;
#P newex 112 93 62 196617 pattrstorage;
#X client_rect 50 475 690 715;
#X storage_rect 0 0 640 240;
#P objectname u228000007;
#P number 112 144 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname tata;
#P comment 152 144 76 196617 name: tata;
#P window linecount 2;
#P comment 184 79 137 196617 tata is missing , but can still be
controlled! Not tete.;
#P connect 5 0 2 0;
#P connect 4 0 3 0;
#P connect 6 0 3 0;
#P connect 8 0 3 0;
#P window clipboard copycount 9;



kb
March 20, 2006 | 2:27 pm

Thank you, it’s very clear for me now!
I’ll soon try to rewrite my old patch with pattrstorage instead of
preset…
Thanks again,
K.


April 6, 2006 | 8:25 pm

I use autopattr and pattrstorage all the time, great! In jitter I use
a metro powered bline object to generate smoothing between parameters
rather than pattrstorage’ internal interpolation functions. However,
I would certainly use the interp stuff more if autopattr had a 5th
outlet where you could connect the object to the pattr system but
exclude it from interpolation. Does this exist already in some other
form within the pattrstorage suite?
Many thanks
Martin~
martin parker
mp@tinpark.com


April 7, 2006 | 8:52 am

Martin Parker wrote:
> However, I would certainly use the interp stuff more if autopattr had
> a 5th outlet where you could connect the object to the pattr system
> but exclude it from interpolation. Does this exist already in some
> other form within the pattrstorage suite?

I guess you could just store the information you want to interpolate in
a different pattrstorage as those you don’t want to interpolate…

What would be more interesting in general would be some kind of grouping
of parameters/objects which would as well allow what you intend:
Lets say I have one big pattr system which has rythms and pitches and I
want to recall only a certain pitch set and keep the rythm or the other
way around.
Of course this could also be done with several pattrstorages, but the
logic behind it would be to have only one place to store all information.
This could be something like a command [group groupname obj1 obj2 obj3]
and then as retrieval a command [groupname programnumber] to pattrstorage.
I would not vote for an extra outlet, I’d rather do it with commands.
It would be much more flexible as you could change the behaviour at runtime.

Stefan

[][] [][][] [][] [][][]
[][][][][][][][][][][][][][][]

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



grg
April 7, 2006 | 11:35 am

Am 07.04.2006 um 10:52 schrieb Stefan Tiedje:

> Martin Parker wrote:
>> However, I would certainly use the interp stuff more if autopattr had
>> a 5th outlet where you could connect the object to the pattr system
>> but exclude it from interpolation. Does this exist already in some
>> other form within the pattrstorage suite?
>
> I guess you could just store the information you want to interpolate in
> a different pattrstorage as those you don’t want to interpolate…

You can just send "interp myobject off" to pattrstorage, check out the
interp subpatch in pattrstorage.help.

cheers, g.


April 7, 2006 | 5:38 pm

As others have remarked, this functionality is available in the
pattrstorage object, which is sensible, since it is pattrstorage which
does the actual interpolation. Your request, though, has been heard, and
I am open to adding "defaults" to pattr and autopattr in some
unspecified, hazy future version of the objects. But who knows when that
will happen.

jb


April 8, 2006 | 11:42 pm

Thanks Jeremy, Stefan and Georg

The only issue with sending commands to pattrstorage is that it is
labour intensive; I have over 700 clients in pattrstorage usually.
Adding a second pattrstorage for non-interp clients adds to confusion
in this scenario too.

While I wait hoping for autopattr’s 5th outlet, I’ve knocked together
a wrapper for pattrstorage which allows global setting of interp to
all or some of the objects in the user’s preset system.
Pattrstorage is queried for clients, these in turn generate three
lists of clients (ints, float and list). These can each have their
interp setting globally or individually changed. The reason I’ve
divided up the clients crudely into data type is that I usually don’t
want to interp through ints but floats and lists I do.

A better way to manage this would be to change the name of the
objects when I make them – perhaps adding ‘iON’ to those that I would
like to be part of the interpolation system and iOF to those I’d like
to filter out but that would mean changing lots of objects in my
patches and rewrites to presets that already exist.

This code could also be adapted and used to create a similar wrapper
for setting priority globally.

I attach the code as a zip and have uploaded here; http://
http://www.shonkymusic.com/pattr_storage_interp_manger.zip

Let me know if it is useful or if you improve on it.
best wishes
Martin~

http://www.tinpark.com
mailto:mp@tinpark.com


April 9, 2006 | 12:46 am

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

"retardement" – i have alot of that in my patches too.


April 10, 2006 | 8:23 am

Martin Parker wrote:
> Let me know if it is useful or if you improve on it.

Thanks for sharing this…

Stefan

[][] [][][] [][] [][][]
[][][][][][][][][][][][][][][]

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


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