Forums > Max For Live

Bizarre behavior with "call fire" and live.object

August 7, 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?


August 8, 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.


August 8, 2012 | 12:40 pm

Here is the replicable code, try it out Live.

– Pasted Max Patch, click to expand. –

August 8, 2012 | 3:03 pm

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

-A


August 8, 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.


August 8, 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 ;-)


August 9, 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?


August 9, 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.


August 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?


August 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.


August 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.

– Pasted Max Patch, click to expand. –

August 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!


Viewing 12 posts - 1 through 12 (of 12 total)