Lot of abstractions VS poly~ for Jitter tasks... ?


    May 29 2012 | 11:45 pm
    Hi there,
    for my system, I'll need to use many abstractions.
    In each abstraction a visual object (= the base element of my system)
    I'd have a lot of abstractions to use and I read about the use of poly~ even with jitter object in order to avoid abstractions multiplication in patchers.
    What would be pros & cons about that ?
    Is there a specific way to use it with poly~ ? (= how would one use that considering the voices allocation etc ...?)
    any leads or examples would be appreciate

    • May 30 2012 | 3:01 am
      the "target" message is key. Also, I'd recommend just using one inlet and then using route/routepass to handle the messages inside the poly~ voice.
    • May 30 2012 | 7:48 am
      Hi Peter,
      yes indeed, I already used the poly~ so my question was obvious :-/
      about the message routing, I used to make kind of central hub (station) to dispatch stuff. It would be more efficient I guess, than to use a JS or even a JAVA/MXJ to parse/dispatch
      not really sure about the poly~ versus a lot of abstractions, from a performance point of view when objects number begins to increase..
      anyway, it would work on a same process for me:
      - creating the poly~ or the bunch of abstractions from JAVA
      - then, fire them a bunch of data to place them on the map, to configure them in fact.
      it wouldn't be hard to test both :)
    • May 30 2012 | 9:51 am
      If you're not tied to inlets, then it matters less. One nice plus of poly~ is that if you need to send global messages ("update positions, everybody..."), you can do so with the target 0 message, though the utility of this really depends on what you're doing, if that level of parallelism in your code is appropriate--i.e. are the objects mostly homogenous or heterogenous.
    • May 30 2012 | 10:06 am
      you are right.
      currently writing notes about the messaging system I'll use.
      objects will be very homogenous from a data/properties point of view.
      but with poly~, I wouldn't have to store all objects (abstractions) references. Only one, the poly~ one and I could easily messages them in one broadcast.
      I would have to track voices id in my JAVA Core.
      btw, i don't know the maximum voices a poly~ can handle.. I 'm afraid about that.
      basically here is a part of the schematic
      [attachment=195321,3971]
    • May 30 2012 | 9:02 pm
      Used to be ~1000 IIRC from a few years ago. If anything, it may have gone up, but that will probably keep you going for a while...
    • May 30 2012 | 9:34 pm
      dont forget you can nest poly~s too, either to get around voice number limitations or for some sort of functional 'grouping' of objects
    • May 31 2012 | 7:54 am
      @Peter, indeed it would be very enough, considering I would have 1 poly per type of objects, meaning it would also divide the number of "voices" used.
      @Terry, indeed!
      It means it could be a nice solution instead of create x copies of abstraction in the Patcher (which, obviously, wouldn't be really annoying because all operations (GUI, Play) would use a proper patch & physical controllers.
      I'm still hesitating.
      Probably because I cannot feel the performance benefits underneath for the moment.