Missing: important listeners in API

[amounra93]

I can't figure out a way to do it: there needs to be a way to determine if there is a change in the live_set number of return_tracks.

You can call:

Code: Select all

tracks=new LiveAPI(this.patcher, track_count_change, "live_set");
tracks.property=("tracks");

function track_count_change(args);{
post("number of tracks has changed \n");}

This will notify when there is a change in the number of tracks.

But there is no corresponding way I can discover to do the same for return_tracks.

The purpose of my post is merely to get everyone to make a list of other calls that are missing from the API. Specific stuff, not just a wish list of features.

Another one that comes to mind, for instance:

Code: Select all

parameter_values=new LiveAPI(this.patcher, "live_set", "tracks", 0, "devices", 0);
post(parameter_values.get("parameters");

This will get you a nice list of parameter values, and their corresponding units (e.g. dB or Hz); however, they are not parsable (that is, they are (presumably) converted from a tuple into an unusable array, since some values contain one space, some two, some three, and there is no way to attach them to the parameter they correspond to). Its reasonable to expect that it must be called, and will not be automatically updated (this, I think, is how its been done since the MackieControl script, where its called every 100ms or whatever). But it would be REALLY nice if somehow this function could also be passed to an attribute somehow, so that it can be listened to.

I thought it might be easier for the developer(s) to see all this in one place. I know there is lots of stuff that I don't even deal with, while some of you others do.

Thanks.

[amounra93]

Here's another one:

It seems there is no way to receive a notification about what the currently selected device is selected (i.e. appointed_device).....

[Hanz_Petrov]

It seems there is no way to receive a notification about what the currently selected device is selected (i.e. appointed_device).....

Hi amounra93,

Been a while since I’ve fired up M4L, but in my latest APC40 script, I re-assign the 8 track encoders to device controls, then listen for device changes via the LiveAPI Song Class add_appointed_device_listener listener, as follows:

Code: Select all

self.song().add_appointed_device_listener(self._on_device_changed)

then do stuff with the newly appointed device (in my case, set_device):

Code: Select all

    def _on_device_changed(self):
        selected_device= self.song().appointed_device
        self._alt_device.set_device(selected_device) 

I assume that you should be able to do something similar in M4L.


You could listen for return track changes in a similar way:

Code: Select all

self.song().add_tracks_listener(self._on_track_list_changed)

then scan the return tracks to see what changed, if anything:

Code: Select all

    def _on_track_list_changed(self):
        for track in (self.song().return_tracks):
           #action

Hope that helps (and that I haven't missed the point entirely ;)

Best,

Hanz

[amounra93]

That's actually the perfect reply, Hanz. The two things you mention are exactly what I'm trying to accomplish, but from within M4L only. I'm still experimenting to see if these things are possible by modifying the Python scripts so that they are accessible from within m4l.

Only properties of Class objects are listenable from within the api, so in order to access a Python instantiated listener, that listener has to also change a property? I understand how the listener functions inside the Python script, but I haven't figured out how to modify the script so that the listener is accessible as a "listenable property" inside m4l. It may not even be possible...I still haven't figured out how m4l decides what properties to recognize as listenable. Or it may be way simpler than I'm making it LOL.

Lemme try that, though, and see how it works...."I'll be baaack...."

[amounra93]

Ok....I'm stumped.

I've been messing around with the APC40 scripts, and, although I can name a new property for a class, and retrieve it via m4l, I can't figure out how to make it observable. Presumably some types of data are hooked in the Conttrol_Surface implementation, specific to certain classes? I just can't figure it out.

Most of the component classes allow observation of "value", but value is abstract...as the component classes aren't specific placeholders.

An exception is the ModeSelectorComponent Class, for example, and its property "mode_index". But in investigating its references, I don't see any reason why it would be listenable, and another property would not.

Am I missing something? Does anyone else have the slightest clue what I'm talking about?


I'm currently getting around all this by making certain calls connected to a timer to find out their status, but it just seems more efficient to do away with this, and have the values updated only when they change. I would like to use a basic Ptython script as a basic for all the Monomod stuff, and modify each instance with m4l depending upon what the actual control surface(s) connected is(are). But I have to figure out first how to code these listener hooks in Python so they are usable within m4l.

Thanks for the help, Hanz....been studying your latest script. Very groovy I especially like the _alt_device stuff, I was thinking about doing that myselft, but in a much different way. I think I like your bit better

[amounra93]

something to do with the base Classes for ControlSurfaceComponent and its functions, I think....

Code: Select all

def set_register_component_callback(callback):

having a bit of trouble figuring out exactly what staticmethod() is....

It turns out there is COMPLETE documentation on the m4l.API for control surfaces: the included Python scripts, and a good understanding of Python itself.

Too bad the first aren't included as decompiled source by Ableton, and the latter...well, I'm not in possession of yet hehe

[Hanz_Petrov]

Only properties of Class objects are listenable from within the api, so in order to access a Python instantiated listener, that listener has to also change a property? I understand how the listener functions inside the Python script, but I haven't figured out how to modify the script so that the listener is accessible as a "listenable property" inside m4l. It may not even be possible...I still haven't figured out how m4l decides what properties to recognize as listenable. Or it may be way simpler than I'm making it LOL.

Clues about the missing link might be found somewhere in the _MXDCore scripts, which are the python scripts that enable communications between M4L and the LiveAPI. Here's an interesting line:

Code: Select all

LISTENABLE_PATH_COMPONENTS = ('tracks', 'return_tracks', 'clip_slots', 'cue_points', 'scenes', 'selected_track', 'selected_scene', 'detail_clip', 'devices', 'selected_device', 'parameters', 'clip')

If you can indeed listen to any or all of these components using M4L, then the rest of the implementation should be similar to the python listener/callback approach - shouldn't it? (e.g. listen for changes to selected_device, then go see what has changed.) You wouldn't be listening to the python listeners, however - you would be replicating their functionality instead.

Best,

Hanz

[amounra93]

oooo, now that's juicy, Hanz

But, they are not all listenable. Maybe they are intended to be, but certain bits are missing. I need to see the whole decrypt of the MxDCore/Utils. I guess I will set about finding it now, but something tells me I wont hehe....Lmao.

P.s. I'm almost done plagiarizing your APC40 scripts...keep up the good work!

[Surreal]

i would like a requestable index of what slots have clips in a track. i have a callback indexing midi tracks, but cannot think of an efficient way to index what slots have clips in a track.