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
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.
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 :)
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.
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:
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…
dont forget you can nest poly~s too, either to get around voice number limitations or for some sort of functional ‘grouping’ of objects
@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.