Actual speed of max data control systems?
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.
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
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.
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:
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
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
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
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
option.
best, t_
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
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_
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
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
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
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
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,
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
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.
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.
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
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
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.
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
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://
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
> 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.
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