Lot of abstractions VS poly~ for Jitter tasks… ?

May 29, 2012 at 11:45pm

Lot of abstractions VS poly~ for Jitter tasks… ?

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

#56743
May 30, 2012 at 3:01am

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.

#203345
May 30, 2012 at 7:48am

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 :)

#203346
May 30, 2012 at 9:51am

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.

#203347
May 30, 2012 at 10:06am

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]

Attachments:
  1. theschematic.PNG
#203348
May 30, 2012 at 9:02pm

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…

#203349
May 30, 2012 at 9:34pm

dont forget you can nest poly~s too, either to get around voice number limitations or for some sort of functional ‘grouping’ of objects

#203350
May 31, 2012 at 7:54am

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

#203351

You must be logged in to reply to this topic.