"selected_track" updates automatically, "highlighted_clip_slot" doesn't

    Aug 11 2013 | 12:04 am
    I just did a little test, which explains a lot why my patch doesn't work.
    Of the children of [live.path live_set view] some automatically update and some don't.
    For example [live.path live_set view selected_track] updates beautifully when you select a different track and so does [live.path live_set view highlighted_clip_slot]
    But [live.path live_set view highlighted_clip_slot] and [live.path live_set view highlighted_clip_slot clip view] do not - you need to bang them to update. I don't think this is documented - any comments or suggestions (am I not using this right?)

    • Aug 11 2013 | 9:01 am
      In the LOM, highlighted_clip_slot can be 'get' or 'set', but not observed. To be fair, I've just made a quick test and didn't get the real clip slot # but the id, which isn't easy to read. Can you post what you do ?
      Edit : your post is confusing. You write "For example [live.path live_set view selected_track] updates beautifully when you select a different track and so does [live.path live_set view highlighted_clip_slot] But [live.path live_set view highlighted_clip_slot] doesn't." To me, those two paths are the same...
    • Aug 12 2013 | 11:59 pm
      Thanks Stephane, I'm extending my controllers with better 'status' information: So I have some indicators on controllers and my Ipad.
      And yes - I made a type on the original post, that was a bit dumb. sorry for the confusion! I was trying to have an automatic update every time the 'highlighted clip slot' changes but figured that you can't. Have a look at the pasted bit of M4L patch below. So it seems that 'live.path' objects automatically update if in the Object Model they can be 'observed'.
      To clarify, 'selected_track' is a child of 'live_set view' according to the LOM this child can be observed [live.path live_set view selected_track] automatically updates the middle outlet whenever the selected track changes
      at the same time, 'highlighted_clip_slot' is also a child of 'live_set view' according to the LOM it can _not_ be observed [live.path live_set view highlighted_clip_slot] does _not_ automatically update when you change the highlighted clip slot, you need to bang the live.path again to get an update
      It's a shame, and I don't really see why it wouldn't do that. But my workaround is to take the selected track + selected scene and construct the clip from that. I know you can have a track and a scene highlighted without the actual clip being highlighted, but I hope I can get away with it in my patch.
      what do you think, does my analysis make sense?
    • Aug 13 2013 | 7:01 am
      That was what I meant when I underlined the fact that this can't be obsedrved. I can't see no reason why this is the case but I guess there must be one... And yes, for now, the solution is to combine selected_track and selected_scene, or use a 'get' command and bang it every time you need to know which clip slot is selected.
    • Aug 20 2013 | 9:09 am
      Thanks Stephane! I still find the M4L documentation quite poor. I figured it out but it seems many (important) things are not or unclearly documented. I'm glad we have the forum!
    • Sep 16 2014 | 1:08 am
      Hello, I m new to LOM.. Is it possible to get informations about a launched clip and then modify it ? For changing a clip in live performance.
      Sorry I furtherly developed the question here : https://cycling74.com/forums/stepping-through-a-midi-clip-with-m4l/
    • Sep 17 2014 | 10:37 am
      Odonjohn, You need to do what's described in this topic. Just put a defer low object between your bang and your get message, otherwise you'll have a "can't be triggered by notification" error message. It's kind of a dirty trick but it works perfectly.
    • Jan 24 2015 | 10:50 pm
      another example of something that doesn't seem to update the way you might expect is the ID coming out of the middle outlet of a [live.path this_device canonical_parent] when you move the device to another track. Would this be the same sort of thing?
    • Jan 25 2015 | 5:35 pm
      I suppose it could be! I haven't played with this for a while, so I'm not sure. I think these things should be documented though in the M4L documentation - like you say you would expect it to update, you can go nuts trying to figure out why your patch doesn't work!