Simon Rivet

I need a bang if the arm state changes on any track of my set, regardless of the number of tracks. Is there a way to do this without creating observer objects for each track?

I need a bang if the arm state changes on any track of my set, regardless of the number of tracks. Is there a way to do this without creatin

observe-arm-on-all-tracks

You need multiple observers, but they can be created with [poly~].

Thanks! Can you give me an example with 2 observers?

I've ended up manually creating all of the observer objects, but now I've got a new problem : I want the track IDs to automatically update whenever a track is added, so I'm observing the track ID list and sending a bang to all track_arm observers whenever that changes, but I get the infamous message "Setting the ID cannot be triggered by notifications. You will need to defer your response."

I've inserted a deferlow object but that didn't solve it. How can I have the track IDs update automatically?

Here is a solution with [poly~] using two simple patches.

1. The poly~ abstraction. Save it as "arm_observer".

2. Main patch for creating and updating the observers.

I'm afraid that might be a simple answer, but I'm not getting any outlet on the poly~ patch. I've named it arm_observer exactly, put the patcher in my maxforlive device folder and chose the file from the Inspector window. The inlet is there, but not the outlet...

Simple answer: the name needs the usual extension.

Simple answer: the name needs the usual extension.
"arm_observer.maxpat"


It did automatically add the .maxpat extension, but apparently I had to close the device and open it again for the outlet to show up. From my experience, the poly~ object can be a bit picky about those sort of things...

I'm still getting the "Setting the ID..." notification, but the track list updates well now. I guess I should just ignore it? Is it max just being overly cautious?

Generally I would not ignore such messages. Just did a quick test using a Live set with 10 empty MIDI tracks and got no error. So the problem seems depending on the set. With some more testing it should be possible to find where the problem is.

BTW, to avoid the flood of initialisation bangs I'd suggest to insert [change] after the observer in poly~.

Ha! Again, opening up the device one more time magically solved the problem.

One little problem that I get now is that every time I delete or create a track, the live.observer object creates an "Undo Change" step in the undo history. I tried disabling "Use Persistent Mapping" but it didn't work.

Observe Arm on all tracks