AndersStig

I'm experiencing some erratic behavior with a max4live patch.

I need to dynamically tell the patch how many instances I need of the poly~.

Inside the poly~ are both a live.object and a live.observer.

The live.object behaves as expected, but the live.observer stops working

once you change how many tracks you want to control.

I've attached the part that demonstrates the problem.

If you mess around with it, you will hopefully experience what I am talking about.

Anyone who can shed some light on this, is a hero!

I need to dynamically tell the patch how many instances I need of the poly~.
Inside the poly~ are both a live.object and a live.observer.
The live.object behaves as expected, but the live.observer stops working
once you change how many tracks you want to control.

I've attached the part that demonstrates the problem.
If you mess around with it, you will hopefully experience what I am talking about.

live-observer-stops-working-inside-poly

Changing how many instances with the 'voices $1' message somehow confuses the live.observers inside the poly,

so they dont behave as they should the second time they are instantiated.

I trying to work around so the number of voices are only set when the patch is initialised.

But that kind of defeats the whole purpose of the poly~ in this particular situation.

Changing how many instances with the 'voices $1' message somehow confuses the live.observers inside the poly,
so they dont behave as they should the second time they are instantiated.

I trying to work around so the number of voices are only set when the patch is initialised.
But that kind of defeats the whole purpose of the poly~ in this particular situation.

I concur that this is a bug. I have attached an audio device that I believe narrows the problem down further still from Anders example.

The attached device should monitor all track volumes by housing a live.observer in a poly subpatch. As the number of tracks in the set changes, the number of voices of the poly is updated, and hence an observer exists for the volume property of each track.

Each poly voice also outputs a tone at N * 100 Hz. If you put a spectrum device after this device, you can see the correct number of tones being output as the number of tracks in the set changes - this proves that the 'voices' message to poly~ IS causing the correct number of sub-patch instances.

The following erroneous behaviour indicates that something is wrong, however:

- Create a new Live set, delete the MIDI track so you have just one audio track

- Drop a TestPolyObservers device onto track 1

- Note that changing the volume of track 1 updates the display in the device

- Add a new audio track (track 2) to the set

- Note that altering the volme of track 2 DOES update the display in the device

- Note that altering the volme of track 1 NO LONGER updates the device

- Note that altering the volme of track 3 DOES update the device

- Note that altering the volme of tracks 1 & 2 DOES NOT update the device

(Note also that three tones can be heard, indiciating 3 poly sub-patches do exist, however, only the live.observer in the third sub-patch instance seems to be working....)

- Finally, delete track 3. Now volume changes in neither track 1 or track 2 update the device

Interestingly, with the attached device, it will 'sometimes' work as expected whilst editing the device (i.e. all 3 track volumes observed correctly).

- Create a new Live set, delete the MIDI track so you have just one audio track
- Drop a TestPolyObservers device onto track 1
- Note that changing the volume of track 1 updates the display in the device

- Add a new audio track (track 2) to the set
- Note that altering the volme of track 2 DOES update the display in the device
- Note that altering the volme of track 1 NO LONGER updates the device

- Add a new audio track (track 3)
- Note that altering the volme of track 3 DOES update the device
- Note that altering the volme of tracks 1 & 2 DOES NOT update the device

Interestingly, with the attached device, it will 'sometimes' work as expected whilst editing the device (i.e. all 3 track volumes observed correctly).


Thanks willyc for that elaborate bug hunt.

Lets hope this gets addressed in a future update.

Lets hope this gets addressed in a future update.
Looking forward to sharing it.

Thanks everyone and sorry for the inconvenience.

I can reproduce trouble and I will log it for engineering.

i am afraid this is a known limitation of the Live API

live objects (like live.observer) cannot be created on the fly - they need infrastructure on the Live side and this will only be created when the device is reloaded (which happens when you save it in the editor)

A workaround is to create a lot of poly voices and only use them as needed.

Would you imagine the proposed workaround adds much overhead?

If I had a poly with 128 voices, each containing a live.observer, with all bar one of them 'observing' id 0 (i.e. only 1 'active' observer), would you anticipate much performance hit from the 'spare' observers?

If they're not being used at all then I would imagine the the impact would be minimal. Let us know if you find otherwise.

live.observer stops working inside poly~ ???