redhexagonal

When I midi map a M4L parameter in this little auto mapping patch, there seems to be a data overload that gives a very poor response when controlling a parameter like pitch of a sample. It seems like live.object isn't very useful, musically.

I could probably use live.remote but this use up a lot of CPU it seems. Is there any way to reliably control a Live parameter using live.object? It doesn't seem very good in real time...

I'd like to have more than 8 macros, basically, which looks easy, but I hit his problem with poor response.

I could probably use live.remote but this use up a lot of CPU it seems.  Is there any way to reliably control a Live parameter using live.object? It doesn't seem very good in real time...

I'd like to have more than 8 macros, basically, which looks easy, but I hit his problem with poor response.


mapped-m4l-parameters-very-slow

There is no official document about the timing behavior of parameter control with M4L, but it's well known that the timing is not accurate. I've done some measurements and found response times in the range of 10-50 ms. So it's definitely not suited for time critical musical events like notes.

Broc, did you see any improvement about that with live.remote ?

No, I've found that live.remote is slower in general.

Typical values on a simple setup: live.object -> 10 ms, live.remote -> 20 ms.

It would be nice to have some 'official' comment on this.

No, I've found that live.remote is slower in general.
Typical values on a simple setup: live.object -> 10 ms, live.remote -> 20 ms.

It would be nice to have some 'official' comment on this.


So the API stuff is basically only useful for non time critical events?

It would be so cool if Max + Live could become a true modular system...

live.remote~ allows for audio rate and sample accurate control of parameters. I have no idea how it could be slower than live.object for controlling a parameter, and i would be interested to see how you arrived at that conclusion.

uh..oh..this is a very bad thing. as an improvisor everything is time critical. 10 ms - 20 ms is simply unacceptable. some official comment?

i'm sure c74 will try to solve the issue.

uh..oh..this is a very bad thing. as an improvisor everything is time critical. 10 ms - 20 ms is simply unacceptable. some official comment?
i'm sure c74 will try to solve the issue.


I've sent a number value from one live.dial to another and printed cpuclock on sender and receiver.

You're not likely to get an accurate idea of the timing of live.remote~ in this way. Your timing test will suffer from inaccuracies introduced by Max's message domain.

A more accurate way of measuring the performance of live.remote~ would be to create a ramp or some other audio signal which goes directly into live.remote~ which is controlling the output of some other audio you are recording somewhere else in your set, and compare the resultant waveforms. The expected result for a test like this is that live.remote~ has sample accurate timing.

Ok I just made a goofy MIDI loopback test. Running a metro in a max patch sending CC values to a mapped live.dial in an MFL device which is triggering a note on message which is going back out of Live to my original Max patch.

Total time for this voyage with a 64 sample buffer in Live is in the order of 5-6 ms. This doesn't seem to me to be any worse than it has always been. If you guys find otherwise please let us know, and let us know how you are testing.

I forgot to mention that my test was done with 512 sample buffer (as default in Live).

So it would be interesting to know your looptest result using the same buffer size.

I guess it will be similar to my test, ie. in the order of 20 ms.

I forgot to mention that my test was done with 512 sample buffer (as default in Live).
So it would be interesting to know your looptest result using the same buffer size.
I guess it will be similar to my test, ie. in the order of 20 ms.


Going back to my original post. I don't want to use live.remote~ at all, it would be overkill for what I need.

All I want to do is create a dial which is mapped using live.object to one of Live's device parameters, and then use Live's midi mapping, or blue hand control to control the M4L dial, and thus the Live dial.

If I move the M4L dial in the patch i posted with the mouse, it works fine - the live dial mirrors the M4L dial in a musically useful way. However, if I use blue handing, or midi mapping to control the M4L dial, the lag is so bad that i can take my hands off the mouse, and put them in my lap, while the Live dial wiggles around trying to keep up, so it must be at least 300ms lag, plus all kinds of errors, jumping back and forth between values etc.

It looks a bit like the live dial is trying to smooth the values from the M4L dial or something.

All I want to do is create a dial which is mapped using live.object to one of Live's device parameters, and then use Live's midi mapping, or blue hand control to control the M4L dial, and thus the Live dial. 

It looks a bit like the live dial is trying to smooth the values from the M4L dial or something.


This sounds as if you have more than one control mapped to the receiver dial! Make sure no other control is sending the same cc, make sure there is no other mapping to the receiver : a slider on a midi controller, or some such. The real clue here is the 'jumping back and forth' ... If you just were controlling with one set of values, it should follow cleanly, at some speed.

This sounds as if you have more than one control mapped to the receiver dial! Make sure no other control is sending the same cc, make sure there is no other mapping to the receiver : a slider on a midi controller, or some such. The real clue here is the 'jumping back and forth' ... If you just were controlling with one set of values, it should follow cleanly, at some speed.
Just an idea...
cfb aka j2k


No, its the only mapping in my song. same effect with blue hand. try the patch i posted (turn the cross on, and wiggle the dial you wish to map to)

The values of the M4L dial are not errors as such, it appears to jump around like its only updating every 100ms or so.

The Live dial that is being controlled moves smoothly, but seems to have a large back log of data that it takes a good few hundred ms to catch up with - possibly its slowly smoothing between the values from the M4L dial.

edit: I just inserted a speedlim object set to 30ms, before my live.object, which seems to solve the problem. For some reason M4L, when midi mapped or blue handed, is sending a lot more data than I'm putting into it, which jams up Live's own dials....

The values of the M4L dial are  not errors as such, it appears to jump around like its only updating every 100ms or so.

edit: I just inserted a speedlim object set to 30ms, before my live.object, which seems to solve the problem.  For some reason M4L, when midi mapped or blue handed,  is sending a lot more data than I'm putting into it, which jams up Live's own dials....


You might find that the defer automation output and update limit settings in the Live.* UI object inspectors can assist with data traffic management in much the same way as your speedlim solution.

You might find that the defer automation output and update limit settings in the Live.*  UI object inspectors can assist with data traffic management in much the same way as your speedlim solution.

bin - just to check: is your M4L open for editing while you test?

Basvik, my patch is closed when tested, but this issue is resolved for me.

Andrew, can you elaborate a bit on your comment "You might find that the defer automation output and update limit settings in the Live.* UI object inspectors can assist with data traffic management in much the same way as your speedlim solution." ?

It may be a bit outside the scope of this thread but I'm very interested in testing and improvement strategies for automation / remote control

There's no way we can know what a parameter will be controlling in advance. It may be that the amount of data coming into your device from automation in Live is too much for the process it is attempting to control, ie forcing updates too fast, as it appears to have been doing in the example in this thread. So we built in a kind of "limiter" for the stream of data as a convenience. That's pretty much the whole story.

Andrew- whats weird is that i can automate live's own dial no problem, but if I automate the M4L dial which is mapped to the Live dial, Live can't handle the amount of data sent to its dial.

What i mean is the process that M4L is attempting to control doesn't seem to be the problem (it happens even if I map to a dial that does nothing, like an empty rack macro), its something to do with the way the data is sent.

Looking at the data as it is sent to and from my patch, it looks like the Live dial "waits" until the M4L dial has stopped sending data until it actually does anything. So if you send a load of data from M4L quickly it just sits there and then wiggles around for a bit as it tries to catch up with the data sent from M4L.

Hi, are there any news to this topic? I currently want to control pitch of a vst synth, unfortunately the update rate is slow slow that I hear heavy stepping. :(

mapped M4L parameters very slow