pcoopergardner

I'm having problems wrapping my head around the live object model, so I apologize if this is an easy question. I can't find an answer that clears it up for me in documentation or on the M4L forums.

I would like to continually observe a Live set's scene list and report when a scene is fired, along with the scene's index. Is this possible with live.path + live.observer, and perhaps a qmetro?

problem-continually-observing-any-given-scenes-state-firedidle

I should make search on the forum with these words. Someone recently asked for this and I made some patches to clarify this point.

I don't have it. I meant 'you should make a search'. I already made the patch, maybe you can do something to recover this ?

The patch enables automated fades in Ableton Live. It's meant for those designers working in theater who want both the malleability of Live and the operator-friendly automation (and excellent fade architecture) of Qlab.

It's a pretty simple patch in its essentials. However, in order to make it truly useful and Qlab-esque, I need the option to GO on a fade with any given scene, as selected from a umenu. This is the part I'm having difficulty with (you'll find my incomplete efforts at the bottom-right of the patch). One of my problems now is that Live doesn't want one live.observer to set the id of another live.observer (Max Window error: "setting the id cannot be triggered by notifications.") I guess Live is trying to avoid feedback loops?

PS - the compressed patch says it's a Max 5 patcher, but it is in fact written in Max 6.0.7.

It's a pretty simple patch in its essentials. However, in order to make it truly useful and Qlab-esque, I need the option to GO on a fade with any given scene, as selected from a umenu. This is the part I'm having difficulty with (you'll find my incomplete efforts at the bottom-right of the patch). One of my problems now is that Live doesn't want one live.observer to set the id of another live.observer (Max Window error: "setting the id cannot be triggered by notifications.") I guess Live is trying to avoid feedback loops? 

PS - the compressed patch says it's a Max 5 patcher, but it is in fact written in Max 6.0.7.


OK, I'm posting another (failed) attempt... but I'm getting closer. this time I'm leaving out the rest of my patch and just posting the meddlesome bit. If you want to see how it's supposed to work in a larger sense, open the last post's patch.

There are two attempts here, both of which attempt to skirt the extremely perplexing Max Window issue: "Setting the ID cannot be triggered by notifications."

(What use is Max for Live if you can't pass an ID to a live.object or live.observer in real time?)

The closest I've come to a breakthrough: I can in fact get the patch to notify me when a particular scene has been fired... but ONLY if Global Quantization is set, at the least, to 1/8th... and then it only works approximately two thirds of the time. Needless to say, it not only needs to work reliably, but also needs to work with Global Quantization set to 'None', as more often than not this is the standard setting for this patch's intended users.

Am I dealing with a glitch here? Or is live.observer simply that unworkable and unreliable? 

There are two attempts here, both of which attempt to skirt the extremely perplexing Max Window issue: "Setting the ID cannot be triggered by notifications." 

The closest I've come to a breakthrough: I can in fact get the patch to notify me when a particular scene has been fired... but ONLY if Global Quantization is set, at the least, to 1/8th... and then it only works approximately two thirds of the time. Needless to say, it not only needs to work reliably, but also needs to work with Global Quantization set to 'None', as more often than not this is the standard setting for this patch's intended users. 

Am I dealing with a glitch here? Or is live.observer simply that unworkable and unreliable? 


Don't have time to have a look today, I'll give it a try as soon as I can.

The attempt you've posted doesn't work because the property 'is_triggered' indicates if the scene is *blinking* but not if it's actually playing. Thus you get different results depending on quantization.

I guess your problem could be solved by observing the track property 'playing_slot_index'.

For the 'triggered by notifications' error, have a look at this thread:

https://cycling74.com/forums/getpath-of-a-clip-only-with-deferlow

its a little long, but scroll down a little. I made a patch that shows some alternatives, with and without deferlows showing when you need it and when you don't. Don't worry - it's driven us all crazy at some time or other. (or maybe I should say: do worry. At least you're not alone)

* M4L patches work differently whether or not the editor is open (...) Errors that happen when you have the editor may not happen when your patch is just running within Live

* you will always have lots of errors when you initialise your patches with loadbangs. Make sure you use [live.thisdevice] to do all your initialising bangs

Do have a look at that other thread - it will take some time to get your head around it but it will be worth it if you plan on working with Max for Live

For the 'triggered by notifications' error, have a look at this thread:
https://cycling74.com/forums/getpath-of-a-clip-only-with-deferlow

finally, 2 more things to know:
* M4L patches work differently whether or not the editor is open (...) Errors that happen when you have the editor may not happen when your patch is just running within Live
* you will always have lots of errors when you initialise your patches with loadbangs. Make sure you use [live.thisdevice] to do all your initialising bangs

Do have a look at that other thread - it will take some time to get your head around it but it will be worth it if you plan on working with Max for Live


@basvlk - that thread is definitely full of information, and I think fills in some massive holes in M4L documentation. I'll need some time to wrap my head around it - your demonstrated use of deferlow has helped immensely, but I still don't quite understand the rogue instances where it seems to lose its effectiveness.

@broc - as per your suggestion, I've abandoned the 'is_triggered' property in favor of 'playing_slot_index' because of the global quantization issue - when reading a particular track, it is quite a bit more reliable. The only problem being I need to read scenes, not tracks, and 'playing_slot_index' returns a value of -2 when no clip is present (and the master track, of course, contains no clips for which to monitor with this property). If only I could have the program automatically read which clips are full, which are empty, and then use that information to automatically change the path (e.g. message: 'path live_set tracks $1'), but this is proving tricky...

You could fill the empty slots of a track with dummy clips.

If this patch was solely for me, for a set project, absolutely. But I'm specifically building this patch to address an issue in Live that I know affects many people, and I'd like to share it. Therefore, must needs be user-friendly.

I learned today, the hard way (a couple hours of patching in vain), that MIDI can't be routed into M4L directly, but only through Live's track routing. So using the work-around of simply reading the MIDI key mapped to Scene Launch and comparing with current scene index, tragically, does not work... works just great in editing mode... I was crushed when I tested the locked device.

Not quite back to square one, however. I'm attaching my latest iteration. One part of the patch now compares the selected scene's index with a scene number chosen from a umenu, the result of which controls a gate for FIRE/GO commands, which is currently hooked up to my failed MIDI controller-workaround experiment. If I can just find a way to replace the midiinfo patching segment with a patch that reports when ANY scene in the live set has been fired, then I'm golden...

Not quite back to square one, however. I'm attaching my latest iteration. One part of the patch now compares the selected scene's index with  a scene number chosen from a umenu, the result of which controls a gate for FIRE/GO commands, which is currently hooked up to my failed MIDI controller-workaround experiment. If I can just find a way to replace the midiinfo patching segment with a patch that reports when ANY scene in the live set has been fired, then I'm golden...


Problem: continually observing any given scene's state (fired/idle)