Julien Bayle

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.

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

for my system, I'll need to use many abstractions.
In each abstraction a visual object (= the base element of my system)

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


lot-of-abstractions-vs-poly-for-jitter-tasks

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.

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.


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.

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

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.

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.

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.


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

you are right.
currently writing notes about the messaging system I'll use.

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.

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

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.

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.

Probably because I cannot feel the performance benefits underneath for the moment.

I'm still hesitating.
Probably because I cannot feel the performance benefits underneath for the moment.


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