Actual speed of max data control systems?


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

    • Mar 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
    • Mar 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.
    • Mar 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:
      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
    • Mar 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
    • Mar 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
    • Mar 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.
    • Mar 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_
    • Mar 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
    • Mar 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_
    • Mar 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...
    • Mar 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
    • Mar 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
    • Mar 20 2006 | 11:58 am
    • Mar 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
    • Mar 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.
    • Mar 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
    • Mar 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.
    • Mar 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.
    • Apr 06 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
    • Apr 07 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
    • Apr 07 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.
    • Apr 07 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
    • Apr 08 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:// 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
    • Apr 09 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.
    • Apr 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