live.remote~ or live.path/set value/live.object ????

[julienb]

hello,
as I understood, live.remote~ is very efficient. more efficient than set value on live.object.

so the choice could be:


by using live.remote~, it freezes the dial in live (that is not a problem, in my case)
more, I had some issues in max windows: "parameter already controlled by another live.remote" that it wasn't the behaviour expected because I didn't have explicitely sent my path yet...

any ideas? remarks? advices about using this or that method?

[julienb]

I tested without any live.remote~ in my patch at the beginning.

I put one, linked to a live.path itself linked to a [loadmess <path>]
I force the loadmess... ok.
it works.
I put another one etc all seems to be ok.

I shutdown m4L patch, I shutdown live
I restart... problem
I guess it is a loadmess issue... I mean: when it starts, all live.remote has the same id (id 0 ?) just before the live.path fires the correct id...

strange...

[pukunui]

I can't reproduce this.

Restoring a live set with a device containing live.remote~ hook ups to other devices using a loadmess path works for me.

Maybe give it to me step by step?

-A

[julienb]

I cannot describe it precisely
I only can give you my files.

I have a subpatch with live.remote~ / loadmess <path>
path are correct, and all different
and I have some instability (crash) & error message about ID etc.

set value / live.object works fine
I should use them instead of live.remote~

in this case (I want to control some parameters with a fixed manner = always these parameters, no dynamic change during the perf), what live.remote~ gives me more than set value / live.object method?

[julienb]

what is the benefits of live.remote use instead of live.object/set value use ?