What it means is you can send ints or floats via messages, using the standard message patch cables, or you can send values as an audio stream on MSP cables, like the output of the sig~ object, or any other MSP object.

-A

Thanks Andrew, so I overlooked the bit: "are send [sic] into [the] left inlet."

But this piece still has me confused: "The values are applied sample-precise (if sent by the audio thread of Max)." Presuming that [live.remote~]'s output is an audio signal, then its output will always be sample precise, correct?

So is this just awkward prose that's attempting to remind folks that messages are not sample-accurate?

If so, "input is an audio signal" might be more clear than "sent by the audio thread of Max."

Best wishes, Charles

On describing the messages the documentation mentions that [live.remote~] is not applied in real time if the input is not an audio signal. So I guess in this case the timing is basically the same as with set operations on [live.object]. But overall [live.remote~] is obviously more efficient as undo and automation are disabled.

Ah broc, thanks for reminding me of that passage...

"A floating point number value received in the left inlet will be applied to the selected Live DeviceParameter, if any. Obviously not in realtime."

So this evokes a picture of an object that can be both a Max "control-rate" object or MSP audio-rate object depending on what's connected to its input. That's what my take-away from reading the ref page was, but I wasn't sure. Andrew's reply then reads as a clarification, which I didn't take it to be at first. (Sorry, Andrew!)

But then, I presume that [live.remote~] with a int/float patch cable connected runs in the high priority thread, and likely [live.object] doesn't, running in the low priority thread? (So it can deal with undo history, etc.)

Best, Charles

Your assessment makes sense to me. But implementation details regarding priority threads are probably under NDA.

Think of sending ints and floats to live.remote~ via messages as the same thing as sending them to live.object, except they bypass Live's undo history. This object was created in this way to solve what we called the "LFO problem", so that automating parameters would not flood the undo history and make lots of people sad.

-A

Andrew-

Thanks again for your contribution, and my understanding is now crystal clear. But are you asserting that aside from Undo history entries, [live.object] and [live.remote~] handle messages identically?

That would sure run counter to the impressions that average users have of these objects, such as:

"So you try with live.object instead which does write to the automation lanes and it works ok for one or two at once but the more live.objects you have running the more messed up it gets. Alas live.objects's communication with the API is asynchronous and the bandwidth available to the API appears very limited. It's not meant for this application obviously, it's for one-shot get and set tasks."

Which you can find at http://forum.ableton.com/viewtopic.php?f=35&t=136101

broc's suggestion of NDA silence is painful if it's preventing brief, concise descriptions of threading priority for M4L automation, etc. such as what Max users got in version 4.6 on pages 56-60 of "Writing Max Externals in Java" and pages 43-45 of "Javascript in Max." These descriptions have been very educational for me, and would short-circuit a lot of blind testing and speculation if they could grow to encompass MaxForLive.

Best, Charles

You're sending messages from the scheduler (main) thread in both cases, so the problems are the same, minus perhaps a little bit of overhead on the Live side for the lack of undo.

Live.remote~'s audio mode was designed to get around these scheduler bottlenecks, the ability to send messages to it is a convenience rather than a "super scheduler mode"

If you like you could try it with 100 instances of each and let us know what you find.

-A

Thanks Andrew for the explanations.

I think it would be helpful to add a bit to the documentation, something like "live.remote~ can run in two modes, depending on the input..."

In the overview there is a plain statement "live.remote~ control Live device parameters in real time" which may lead to confusion.

Personally I would prefer to have 2 different objects, ie. with and without "~". But there may be good reasons for the dual mode approach too.

If you like you could try it with 100 instances of each and let us know what you find.

Well, I might. Although we all have to make our tools, it would be nice to make some music instead of puzzling out the rough edges of M4L. :-)

My last question: I presume that the Javascript LiveAPI.set() is the equivalent of [live.remote~] using messages, and not the equivalent of sending [live.object] the "set" message?

Best, C.