Canonical Parent / Live.path in Laymans! please help a newb!
Can someone please try to explain to me what the difference between the left and middle outputs on the live.path object are in layman’s terms. I’ve read all of the online documentation on M4L so far and I’m having trouble understanding it.
"Sending a message to a live.path object results in an object id being sent out the left outout (where the id follows the object) or middle outlet (where the id follows the path)."
Also, can someone explain "Canonical Parent". I understand Canonical Path but the wording of the sentence below really confuses me. Sounds like there may be typos in there….
Additionally to what is described in the LOM, all objects have a canonical_parent child which is used by Live to determine the canonical path of an object. The canonical parents are get-only and useful for patching, too. For example, goto this_device canonical_parent is the perfect way to get the own track object."
What is "the own track object"????
What is an object’s "canonical_parent child"?
I found this blog by ShelLuser, which explains canonical parent very well!
BUT im still confused about the follows path and follows object. Anyone?
The problem with not using canonical_parent is that you have to indicate with track and the parameters you need to change. For instance if you want to control the gain of track 2, then you can do that merely by indicating track 1 (0 for track 1, 1 for track2… kinda confusing but just minus 1) and the volume. That will control the volume of track 2 always, no matter which track you drop the M4L device you’ve just created onto
However, if you want to create a device that no matter what track you drop it on, it maps to that tracks gain. Thats how you use the canonical_parent. It uses the id of the M4L device that you’ve created and by back tracking through the LOM (using the canonical_parent) – from child to parent, it find the id of the track that device sits on. Thats how you can create a device that is universal, in that it maps to that tracks parameters rather than creating different devices for each track and having track0 or track 1 or track 2 in the live.path.
Does that make any sense?
Basically it uses the child to find the id of the parent. The child being the device you’re creating. Such that you find the parent’s id through the device (the child).
protocol wrote ‘However, if you want to create a device that no matter what track you drop it on, it maps to that tracks gain. Thats how you use the canonical_parent. It uses the id of the M4L device that you’ve created and by back tracking through the LOM (using the canonical_parent) – from child to parent, it find the id of the track that device sits on. Thats how you can create a device that is universal, in that it maps to that tracks parameters rather than creating different devices for each track and having track0 or track 1 or track 2 in the live.path.’
ok, so in that case, what message would you send to a live.path object ? I thought about something like ‘goto this_device canonical_parent mixer_device volume’ but it doesn’t work…
About this question : 'Can someone please try to explain to me what the difference between the left and middle outputs on the live.path object are in layman's terms. I've read all of the online documentation on M4L so far and I'm having trouble understanding it.'
Did you read this in the live.path reference ? (had to do a screen capture because it's not possible to copy some text in the help file…)
Can someone from Cycling’74 elaborate on ‘the difference between the left and middle outputs on the live.path object’? I’m always using the middle outlet (as a kind of habit).
So in my first explanation it may have been a bit confusing, wrote it kinda quicly last time. The this_device sets the path to the M4L device, using canonical parent allows you to move up to the previous level.
for instance if you send the path the following message:
loadmess path this_device canonical_parent mixer_device volume
It would go the the device, then up one level (due to telling it canonical_parent) to the track, then you choose the track’s child mixer_device. Then you’re in the mixer_device of the track, without having to state what track # to go on – just as you were eluding at in your message.
I included a working patch for me below,
hope that helps,
Here is an example of how to use it:
----------begin_max5_patcher---------- 967.3oc0XF0jhhCD.9Y8WQJp6QGKRDP8d6teCWcur0TSgPTytPBURv041Z+u eIMvHnAA1cGu4dPQ5D5z8W5tSiea9LuchyTkG52QeBMa12lOaFHxJXV88y7x iOmjEqfo4kSUp3CTuEUioom0f7eC2HpHVmbjwO7hjlnqTMweo+BTn+Z6kUjk gKP3nk9nmqeDdYNimQ0vRPpExRAEK184mB7aT9dAWyiyovP+gjEmg9SQVp2E EIJ0MZBWKsRj90BZk43481Ja0mh8Ov.XiUZk984ysesXjDIichtL0XIMFwoX 4al3MC1OcBBA5DX+lrtO5fukNq1bQ4RyBqoxWn73cYz1OPWzz.Y0QwWaLV+d w0Bj29LQr9B2fmqLeGU19IKjTEkqi0LAukCFT4faH83fp3SzzWh0ZIaWold4 WpZrWycKZyJoh8Mhaj21yyEolsGvysKxhamQlfe31MnOEhe1aga8w3fW5VaL 9WrZS0BD2n.QJsugY78BvRbs3kbV09kyQExzN7uyfoz88OnpfRSyX4.lV51r NwTr5XHhKUnoE85ywbtnNL3MR6xCnmKDbSDS+1AP.8qchk6h2lcamOd9c26Z hwcC.l1DVzJSxIHOJjZGY6UyDpjzbYhkU3zuZRtuoNqD8zSOcRjUlSuSIkns 1jrfsPtVDj2g2zWIE+aKoPB+.WvMQjmaiYtFM+kLN4Kn+dH1.LYkOTSBShlb 4VxanQdXWkJswdlPLbPHIDC+xecvpsKrCzwyuCIstQhHSHmfJ6ReeWHdyODh 6I3Si1gxPCeVV.NphtfWXkMZ5FdmHO2Acq5KnaWL+f8nK3i6.PxuR5.Y+lAr vXHBEsZ0nHjqlgvSkPSMs7GiJ80YXgTTPk5WQvg2CG6D.wNa1b+hVN.yp0eL ASegKh3TKyPFTbDoOxTlyrOwRnnjXtfyRLG9XNnwToCkyNCmnCi1s3uo8CZh nr5Hzv9gKtp06ppd9Pv25vozjI9+Wv0lKZAq2PHYKbILZxUpHa+kUo5+fpTJ p7jo+vAyFWCW13O4xTjImMRtKddDkpTTcUUJzHdc1HreSVzDKTEPdr4RvbfJ EW8p9fuYk2kUJQoLoYEZd+azE+KkpzLNzdeqIYeMzVS5HKMkxa2WRNKsPv35 Zi.8ryctwZS13qAsoqL72caJ7iGmtZ45gSjGqMMl8tq1feusoqPPObB+PsIa yvH7X3Dd71joVdnsMqpVAp5T+p6hf+ntsUSLBd4ned+fLF1herrcvb0GaLns khA2uuxve2yUwiIWc6OgMYt46y+Wk++Sp. -----------end_max5_patcher-----------
About the difference between the two live.path outputs – it confused me too though I had a bit of an idea what it might be. sometimes it’s just better to try stuff out, have a look at the patch attached
Note that you MUST copy the code into a M4L device, if you just open this in Max it won’t work: live.path, live.object etc only work if they are in a patch that is ‘inside’ a max device.
So here’s my take on it: when you kick off a live.path both outputs give you exaclty the same. the key is, what happens with the path if something in live changes, eg you select a different track. Do you want your path to change to whatever the new selected track is? Or do you want the path to stay the same?
Have a look at the left live.path code and the message boxes, change the selected track in live and look at the outputs from live.path. then.. double click loadbang and you’ll get the point.
Now look at the right hand live.path example: this is a canonical path to track 2. What do you want to happen if you insert a track to the left? do you want your live path to update to the new track or stay with the one you selected? or if you move the track around, do you want the path to ‘follow the object’ or do you want it to update to whatever happens to be track 2 now? again, look at the message boxes as you move the track around, and double click loadbang and see what changes.
hope that helps!
----------begin_max5_patcher---------- 897.3oc6Y1zbZCCDF9r4WgFeljwqj+r2RmdIG5sdqICiAqBp0XyfDIoMS9uW KI6Bzl.BgqFOL4.3fjv90Od2Wsa34Qd9Sqehx8Qe.8Ujm2yi77TCIGvq8yd9 KyeZVYNWsL+kTNOeN0erdNA8IgZ7p7kTD9pa1Tvp6l7a0UBN6WT4BffqCZGt ZyRVUIUnNg31AWkKlsfUMexZ5LgVPwIIMeGDN.KO.3X0gl2Q2u8LUuQzcpf1 QYEJEUO86WgS6zhdchethpO499+4rHkoT9pu0MqY4knOVWV3Km8kQijuM9Lo ybp.otD8EYhTrf.xCQgV.lL2BlJ5iMW1+gKkrGnW2Lg7NqeQSLQdHQGyjdJn gDbFnocZd9CzhI5arI4BwZ1zMBchl2eHjm+jUz0bFWPqloueUiqPaOAXAZJp 7TPKbbzFnfZR30QGDs3WAsvah1o4Uy8G63zRVABBwcCWxpnyp2TI1U86wL7I GNlDksSlJQYnQvmT3H1pvw9DSJu867+x57Y+.gQhELNhwuyumRYiBi097f09 7DxEoOeTn1ZmDXqOOI7B0muCMwXq84id2m+fnMHxZe93AmO+1BdNSG8Xb5N4 jZG8SLvKwYN5uU5Xcdg9Ag4H4fALjsrHNPaleRDI8vwKNhJRSplauEH4eMg2 3kKja4wQPuAJkOUbaeMIGgTjWgTGnt8wsubaUAppATbB5sJBHXrFMAVWQ.bY 14GA2hjLaqH.tT67qCMwfsUDfeuyuCi1fPaqH.O757aae9mYEAgZrzlSZSEA 3jgQOdgW84a+zs8T9Hjo6mKKydS7Ky15fzVjjZsI9kZaccnQWEoMl3v6s0cX zFPr0DGFds0ER5ISbbBYmbRaLwgKs15fTMKhrssNLYf1V2CL5iHNsr4VsIOW 07RewL8ldwQ12gWu0fmZYp+q1+0uvmR2xw2Gl75Mqm0cw5ZKGsU5ETtfUkKX 0U6tnr8VzBVQAUMeG5VxJVUypDsh.c+q9n0XMIubvwzD3dMcTNE6VMEYhlH6 Ay+6ZJzDME4VNEahlBcul.S3DLvzTha0DXhlvCPME3dMcrXbra8wwF4YF317 t.S3Tpae1Yfj.Gu0hAQ3X2tCL1jmbfaexAlDgicaDN1Dm.Hy8ZBLgSv.SStc 2NvjcfggnlhbulNZLtaqnCLoxWvsU9Blzg.31NDvlrcG4LvTyGdYzuADjf9C -----------end_max5_patcher-----------
was that useful? (I’m only just starting to contribute after months of lurking :-) )
Thanks Basvlk, that was a neat idea… thanks Protocol for the help. Something bothers me in your patch : where is the s –volume ?
I’m a real beginner eager to learn and working hard to get it, but sometimes there are holes in the otherwise very clever Max help system.
So… What I notice is in the left patch, from the left outlet, each object gets an id which won’t change whatever you change in your liveset. Is that the idea ? (not id…)
I copied the patch from something I’ve been working on. To create a device that communicates to my Lemur and any OSC instrument and automatically maps it to a device or track parameter like the volume. I guess i left my —volume in (which takes the OSC value change from my Lemur and modifies the volume of the associated track).
So sorry for the confusion, just ignore it.
Thanks for sharing!
But what about this_device canonical_parent? The id does not come out of either outlet if you move the device to another track (thereby changing the id of the canonical_parent). I modified Baslvk’s patch to illustrate my point.
----------begin_max5_patcher---------- 1044.3oc6ZssbaBCD8YmYx+.CO6jAIw09V5uQlNdjA0XkhAOfrqayz+8BRfs SSwZcLHxvjGBXXwbVc1k8rrNub6MyrWlumUZa8EqGslM6kpyLSdt5yLq8Dyr WS2GmRKkWn8ZVYI8Il87FiB1dgzPFcMyBe2CaS34GrluUjxDhesgoPw115as 11PEwq3YOsnfEKTlChH26L2BE3I2g8k6p1d7akscs5lJcGzgaVAqjkInBdd1 qLvSjdW9xmuCGZ++t7KC+ummIJ4+VtdPNU1O5W7rV2Be5UWSLRe3gBNM05q4 oI1Ry+41ap2Wsa90S+OwDVRjd2TORtXcbq2441uLejdlWG7iLwmw9Y0J4s7d JeG69JK0qjqj5Ixzs.URWXOQ8DGnTe2v2OTeq8R5NVxBEksfJDE7kaEpxPyN x9yrWrgUTxKErrXExJCMAudMHJrVZk1c3aIM6I64.CiAQxst26c9nH9hhhHf QwtQGTPDY9BW7DKx68ImvlB0ppFDR+9jCVGmqG9WQ53K+ImAfu6CcZeerRmz cHzoIDcDO.7mp5z99NpbNx.nSSb0y75fe5pS2t1IdCfNMBCk56F9O0ognS2v iAgCgNsOvnX2nOE0oCbcOopAIne0oCz1ajV3GOc5NqWkSST4ymMa+7Y5dQp0 c8VUdG1ouXcsuLsVzAQ5HiR50hDUD4Jq5OsnrRqVTPi+QoE5Lo9ya9CRKStM 7PftfA4hBFQ.6X5LvOdQiAsUUWRnpUQxPzpJR6SA.vep1ppqZhBHG7.zpJJR OyqC9oaqpsqch6.zpJ1AJ02M7e1pJjVUa3wffAnUULBXTrazmhsp5gcNopQO 2pJVaqp5gehNRIhpmDT.dPzo0NRI.3OU0oINMiwDMD5zt5YdcvOc0oaW6pYG 22iTxCJ02M7epSCQmtgGUDXOqSi7AFE6F8onNMIL5jpF8rNMRqNsd3mliThn 9stBGfIJgAnQedv+HOPIwJd4hD1NdLyJllkmwiooK1PKpVmW6rkZ5cQMoALh zqyVBiA15zYfuuCLp6bE6l8l+8kjzSsg+IbUlusHtkVamYl0I9XBqTvyNPEO dbf9mdUq3IIL4EbXQjvKoKSYRFyo6LnKywPZcLj4crPPLVj4cLePLVvquJS4 X5YL2OnLV8uIooYLWHLlzwLLig.kiMBLFLGyYbbLsgR7HTtvAjiEZbFCCSRx w3LVcqY.XLy+TIFCI4GiFGGSecLy2cAFT4Br40JA5XNiiioOTZ95XXP0wPlu NFBTcLr4qigf01i4S9A5XdiiioOGy7cvJ4B8NFw7LFrNX8LOiARRhbcLVyal S2rYW8HbU2ZkOYul9bdQ8w9yUGyyTGqdye6B1Nd6WITcJZQ7JtfEK1VnFGvd e25gAHArZyeAUC.Mv -----------end_max5_patcher-----------