knockd0ut

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 an object's "canonical_parent child"?

"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 an object's "canonical_parent child"?


canonical-parent-live-path-in-laymans-please-help-a-newb

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?

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?


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.

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

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

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.

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.

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.

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? 

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.

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.

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


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.

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