Bizarre behavior with "call fire" and live.object

    Aug 07 2012 | 11:56 pm
    I store a clip_slot in live.object. When I call getinfo or getid on this live.object, it returns the correct id ("id 5", for our purposes). However, when I send it a message saying "call fire", and print the dumpout, it says it "fire id 0". When I say fire, it calls the wrong id, but when I say getid/getinfo, it shows that the live.object is storing a different id. What's going on?

    • Aug 08 2012 | 12:15 pm
      Is this question not specific enough? If anyone might be able to enlighten me on these objects, I'd appreciate it. Right now, this seems like a flat out bug.
    • Aug 08 2012 | 12:40 pm
      Here is the replicable code, try it out Live.
    • Aug 08 2012 | 3:03 pm
      Perhaps you have no clips in the 2nd channel in your set? Tracks number from 0
    • Aug 08 2012 | 9:25 pm
      Maybe I don't understand how Live assigns ID's... I'm aware of the how track numbering works, but it is true that those clip slots are indeed empty. The weird thing is that this sometimes works and it sometimes doesn't.
    • Aug 08 2012 | 10:37 pm
      Actually there is nothing strange about this behaviour. Why the assumption that it should print out the id of the clip ?
      When you use the fire function on the clipslot there is no 'real' association with the clip. After all; first there doesn't have to be a clip and second; it merely gets triggered. Put differently: you're operating within the scope of the ClipSlot class and don't really access the Clip class.
      When you use the fire function with the Clip class itself then you'll see the same behaviour btw; it will print id 0 (same as 'stop').
      Which is AFAIK by design because there are no "object associations" involved here. The function is called and merely triggers (or stops) a clip. Also note that the references don't mention anything about any ID or status values being returned. (I'd sooner expect a return / status value than an ID btw).
      To my knowledge it will always print 'id 0' because there's no real id to print here.
      Oh btw; you may want to use "getid" next time, it makes it a lot easier to, well, get the id ;-)
    • Aug 09 2012 | 1:53 am
      Thanks @ShelLuser. I guess then that my question is the following: I want to programatically load in different clip_slots/clip locations into the live.object, and then call fire on those respective locations. What would be the correct method to do this?
    • Aug 09 2012 | 10:24 pm
      Well, you could setup a list of locations (path names) which you want to control then work / loop your way through it.
      You can easily point the same live.object to a different location so that it can perform the same task on it.
    • Aug 10 2012 | 1:55 am
      I guess that's where I don't follow -- doesn't pointing live.object to a different location make it retain the corresponding id? I tried to having live.path convert a received get the id of a received path name, and it does so correctly, but then I send that ID to live.object, on which I call fire, and I'm back where I started. What's wrong with my approach?
    • Aug 10 2012 | 2:13 am
      In fact, I can use the exact same approach they say to use in "Creating Devices That Use The Live API", and it calls things at the wrong location.
    • Aug 10 2012 | 3:12 am
      Without seeing your patch its obviously not possible for me to determine where you're going wrong.
      Alas, here's your proof of concept. Click the button and a clipslot is fired. Hit the button again and the next one is fired, and so on.
      Dynamic path, same live.object being used several times.
    • Aug 10 2012 | 12:35 pm
      Thanks again ShelLuser. I chose not post the patch because currently it is a goliath, and given that the problem could have existed anywhere in it, I didn't want to burden the online community with it. But you're indeed right, and it showed me that live.object was not at all the problem!