Julien Bayle

I'm working on a nice installation based on very easy concepts:

- elements traveling on the screen (gl.gridshape > gl.multiple)

- each element has a poly~ voice and its position, orientation etc produce voice modifications

Objects' movements drive the whole system.

I mean, traveling elements is the root part that provokes sounds' alterations.

Thus, I'm spilling some matrices (one coordinate from positions, one from rotatexyz etc) to alter the sounds by sending these data to the appropriate voice of my [poly~]

As soon as I start to feed [poly~] like that, the performances decrease awfully.

My bottleneck here is that part for sure.

I have 64 voices and at each turn, I need to change 1 value in each voice of my poly.

You want to know about the poly? It is currently only a [cycle] with 2 [*~] in order to map the visual position with the stereo position.

I even played with audio parameters (vector size + signal size) because when you are near from critical limits, that can help.

It doesn't really help here. At least, it wasn't enough.

Are there limitations while we feed a poly like that? I mean, not about voices number, but more about deferring all messages entering into the poly or whatever else..?

I used jit.change, jit.qball and deferlow in order to limit the number of messages but, if it helps a very bit, it isn't enough.

Hi there,
I'm working on a nice installation based on very easy concepts:
- elements traveling on the screen (gl.gridshape > gl.multiple)
- each element has a poly~ voice and its position, orientation etc produce voice modifications

Objects' movements drive the whole system.
I mean, traveling elements is the root part that provokes sounds' alterations.

As soon as I start to feed [poly~] like that, the performances decrease awfully.
My bottleneck here is that part for sure.

I have 64 voices and at each turn, I need to change 1 value in each voice of my poly.
You want to know about the poly? It is currently only a [cycle] with 2 [*~] in order to map the visual position with the stereo position.

I even played with audio parameters (vector size + signal size) because when you are near from critical limits, that can help.
It doesn't really help here. At least, it wasn't enough.

Any experiences or ideas for me here?
Thanks by advance!


how-can-i-improve-massive-poly-feeding-from-some-jit-spill

Three random ideas to decrease the # of messages going to poly

1) Could you use speedlim to reduce the number of jit_matrix messages that are sent to jit.spill

(matrix of position/rotation) -> (speedlim) -> (poly)

2) Or get the data into the separate poly instances not using the poly message inlet method. Something like sending the matrix of position/rotation to a global send object. Inside each poly instance, is a matching receive object. The instance knows ~its own instance number (thispoly~) and can therefore lookup which row/column of the matrix to get its data.

3) Same as (2) except don't use send/receive. Instead just send a message to poly~ as a global message to be sent to all poly instances.

Three random ideas to decrease the # of messages going to poly
1) Could you use speedlim to reduce the number of jit_matrix messages that are sent to jit.spill
(matrix of position/rotation) -> (speedlim) -> (poly)

3) Same as (2) except don't use send/receive. Instead just send a message to poly~ as a global message to be sent to all poly instances.


thanks a lot for your neat answer, as usual.

I tried to run the visual part in a top-patcher that sends with jit.net.* some matrices to another top-patcher handling the sounds.

This "simple" fact improved the whole performances.

I feel a good idea here: only one message sent, and distributed job over all poly~ instances...

I tried to run the visual part in a top-patcher that sends with jit.net.* some matrices to another top-patcher handling the sounds.
This "simple" fact improved the whole performances.

I will try 3) first.
I feel a good idea here: only one message sent, and distributed job over all poly~ instances...


How can I improve massive [poly~] feeding from some jit.spill ?