Canonical Parent / Live.path in Laymans! please help a newb!

Sep 18, 2011 at 10:43pm

Canonical Parent / Live.path in Laymans! please help a newb!

Hi everybody,

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

“Canonical Parent
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”?

#58932
Sep 18, 2011 at 11:50pm

I found this blog by ShelLuser, which explains canonical parent very well!

http://blog.synthfan.info/2011/04/11/m4l-diving-into-the-live-object-model.aspx

BUT im still confused about the follows path and follows object. Anyone?

#211715
Sep 19, 2011 at 2:36am

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

#211716
Oct 12, 2011 at 3:28pm

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…

#211717
Oct 12, 2011 at 4:41pm

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

[attachment=172591,2714]

Attachments:
  1. Image5.png
#211718
Oct 13, 2011 at 7:35pm

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

#211719
Oct 15, 2011 at 10:47pm

Stephane Morrise,
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,
Protocol

Here is an example of how to use it:

– Pasted Max Patch, click to expand. –
#211720
Oct 16, 2011 at 1:04am

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!

– Pasted Max Patch, click to expand. –
#211721
Oct 18, 2011 at 9:53am

was that useful? (I’m only just starting to contribute after months of lurking :-) )

#211722
Oct 20, 2011 at 6:50am

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.

#211723
Oct 20, 2011 at 8:00am

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

#211724
Oct 20, 2011 at 2:04pm

Stephane,
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,
Protocol

#211725

You must be logged in to reply to this topic.