Bizarre behavior with "call fire" and live.object

Aug 7, 2012 at 11:56pm

Bizarre behavior with "call fire" and live.object

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?

#63898
Aug 8, 2012 at 12:15pm

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.

#230426
Aug 8, 2012 at 12:40pm

Here is the replicable code, try it out Live.

– Pasted Max Patch, click to expand. –
#230427
Aug 8, 2012 at 3:03pm

Perhaps you have no clips in the 2nd channel in your set? Tracks number from 0

-A

#230428
Aug 8, 2012 at 9:25pm

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.

#230429
Aug 8, 2012 at 10:37pm

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 ;-)

#230430
Aug 9, 2012 at 1:53am

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?

#230431
Aug 9, 2012 at 10:24pm

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.

#230432
Aug 10, 2012 at 1:55am

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?

#230433
Aug 10, 2012 at 2:13am

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.

#230434
Aug 10, 2012 at 3:12am

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.

– Pasted Max Patch, click to expand. –
#230435
Aug 10, 2012 at 12:35pm

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!

#230436

You must be logged in to reply to this topic.