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?
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.
Here is the replicable code, try it out Live.
----------begin_max5_patcher---------- 510.3ocyU1raaCCCG+r7SgfO6EXYmu5ts8ZLTXnXyjnNEICIkrrUz28IQYul tEuYGzVrCQAjTh3O+YQpGSHoazmAaJ8izuPIjGSHDzUvAoyljdfetVxs31RO .VKeGjlEi4fyNz+NsSSkhSPkEbTmgW+UKkQqkh1JqT6rzh9yrUqbJ9A.O2mL Btj9YsroOrnACn27vGJJ6cpNdPnjfCEQQmyVtqduPsqx.0tXQTrrXVdFkwv0 U43eKmkSu+4DoO55yD6BIYE+.kDKbnn63NceuEhYOMkdeHxSIIgkrQxLE7Me 07GHKPqY9ZX+M.F1UAC6eBlEqw0HdVOHWJmJWx598ZxmViP4FlMWAKrxIikx 4HJtC4RznHePtjeMt3A6MTzC1HANgZqdR08hI2lD5I7kcd9ntNvFnrecaSFh H0bojtUXfo2mrdpfgMON+n.uOLe0+8yO7ABhe5SPVcq2Y5Fjb2sbm4uiltPV 9InoJVXUbmyH1bzEekh7KBQRqZAiUXcfpNlbzOh1d.iozyI0u+FGVdA+uj5V 8QScuf5myRetBa.qu4j6DZ0kaxiR+Sc8aZunoATWNsnQX4aj.B+qOpXz5obL 54kh9MUOqFgdXkua5YwX+b89Hm0ukxId4l21dJzGDyIpD+viGzlf4xLzTnhl XFSMvIQ+9WjDx1SI+Dv+kLEV -----------end_max5_patcher-----------
Perhaps you have no clips in the 2nd channel in your set? Tracks number from 0
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.
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 ;-)
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.
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?
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.
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.
----------begin_max5_patcher---------- 1546.3oc6ZsriahDEcsiT9GPnY23XAXvXFMaRzrYjxpYazHqxPgcktnJDT1c 2SzLe6S8f2lxF+jtkxh.cpWbqy4dObqK9Ge7CSLWSeAlaZ7aFeyXxjevaYhr MQKSJaXhYB3kPLHWNPSB7Y55uaNsnOF7ElrcLZObFuGXHqpSxtDDACYxY5zn U5NVYy1kMGSILBHAJWsOmg.XiuPwQUKlZNrWSgJC1zz3uK6CEImE+w+I6klM Wwbz+HGus0Lqx1SArvsHxlUYBiUtX1Nh9MbrVHt4EHtZublU8iHGrGFsRsAW AXrLz5cLE3MoFqlXtJElkixYPRn5Aq53e+3Gj+Qwc9soCFxSf44fMvCw7P.F aDixp6BiHvP5NBqKh2COf1PnbD.iBepEQbm4G+qfer8cD2lOWRV9B94hQUcN xLi0F39cg0.QNWLDsFP1XNUKT4cQPkqzG110UBUNy7Jcku4PkLlmaBaOK3Z9 k6QMs3e8CWtWDbMW4Yobv7rqi7u8wqBnxP.ZqxgLCVFH7obCaCdHX5pbLkka 7K1luICZmeEPavRUnqzezdw8AZE.5aTvK3RvNeEn4HU5lGbCfN85c3Gldm9f 2K5sBARbYwx6tP2uZX+fRpAId0ce.zhK2KJ31APREedhOLJoxd1Cxp1h80e+ tTofL9jXvrUPBXMFNj.xAFvU+ZSs9L1dxqAkW6lmWUBdGKUu8.7NHMtr8pNZ t4RnQb.TtKD4qLsmgfojMGC.OX8PDwPszrZHxShUSZtV5VBZDTa+HRLUZK8Z .6HHEqze2zrHXl1kNBFejdySgvHLJQhVyzXa6Q4nB2k9WDFLU+dGPHTFfgnj UUPdu6CH2ErvIiFGKzs3DRkWR6g9RJk.UobqwrkfF60Bu79YkR2jYZ59nrdY LgS+fFhwUdZDn0Oxsklw50QrXvkmg4pNLibc4fqXXZUP5z+Uqf3bz2HEio.M pttmVJw0WpttnTV4skTRaj7mRIigTxYpObb4AcT+IDHJz.JRLugWZuxH12VY jBmvaoLhtL0RM.6hPzUwzrmAYQ8KgX0uJg0PyZqg.wEcvnhCDIkLVt7vZMIm hx6tkJQLBC2KJuDkzhkLAooMZuiBRB36T4Z4USWbvP0VClNCJBHTKQPMWU8P pse4w5jWV3Ju4tzpoKk45MXZ3SvnVNIl7P1yXMnoPReCu7RmghHoYvbdXlLj 7fGLXGlspEE4Lq+ADCBg5mda2hp3cyMYnHJQXHsmqn8xG42JS6zqk0KGBAj1 2zYTJdMHqgRUMoyiP.DTBfAYHkQ4XUOSTRZFRI5T2nJzcadXFEiauZpt12WW QbGiP3ynH11NJLsKfbK2tlQvs6nSjbHMIQnNNsw.pBm+ciurCgiLdktKSEYa .ii4dEF73CXq4zaoO0m9vQh+GhFf1DENlVvoJYmm7z9ApRQGTcPsVhlU5j2A z9uLuWvlwex.XTXaPJay5xf64hP54thq7Kse+Taf1w6.aOjhUhYCXkNWlwyQ 8cAT0EzuS0AeXLyWeOvLKdjLyRq2DDy6hPF2QHjw14mgLmlYbd7gLUeJswhX 9CY5DF7DVYnPNjxOlFhc8j0VTTDjbvLNRRa5pS+kfsdJ4nhub73AteVliDiZ 7U9AudGDA3e6B.rOc.fLMKGU.vR65h+NFbTbFM48BKs3gxRJ8IK0GObwcjkZ WDgNER.uaCGu+O8riid1w4bOIwA0kLGsgHjpp9K8uC4ZjsTeZnhrnTG+3NoZ cJrFQd6C01WOTWjVz.f5FUHPbzVcmxV9jDCPCIjyO4bX4VsXSXzI.MBlyPjp Bm7sJGqtCr9crs1sInnTJhvJrwyw64hLe6gZ912Tyuri5hhM3eUXmrBTGq1R mtpTG1q1GzFLcM.WTgwCKb8wJ1ktp1p.41doEUwsK8VVK2CoU+VdaZ3TwOtu li5PBUCY1aIlGtw40xW5XFm83XbmF47GGjycPHm23XbyGDx4NJFm+f.t4ihs ELDb6rgsk9xefJpZg5qRBr4+Yt5EnVKECa9I9crL38xhgrWBFMWfSZZKFESy cHl13H43cWbNOvzDMvu8+TESSNB -----------end_max5_patcher-----------
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!