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.
    max v2;

    • 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...
      max v2;
    • 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.
      max v2;
    • 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