Forums > Max For Live stops working inside poly~ ???

Apr 19 2012 | 9:18 pm


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
The live.object behaves as expected, but the 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!


  1. polytest.amxd
Apr 20 2012 | 12:19 pm

Ok, so I have narrowed it down to this.

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.

Well here goes.


Apr 21 2012 | 5:28 pm

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

– 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

(Note also that three tones can be heard, indiciating 3 poly sub-patches do exist, however, only the 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).

Apr 23 2012 | 1:12 pm

Thanks willyc for that elaborate bug hunt.

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


Apr 23 2012 | 7:17 pm

Thanks everyone and sorry for the inconvenience.

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



Apr 26 2012 | 5:06 pm

OK guys here’s the deal

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

live objects (like 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.



Apr 26 2012 | 8:49 pm

Thanks for the clarification Andrew

Would you imagine the proposed workaround adds much overhead?

For example:

If I had a poly with 128 voices, each containing a, 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?


Apr 26 2012 | 10:15 pm


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.



Viewing 8 posts - 1 through 8 (of 8 total)

Forums > Max For Live