mapped M4L parameters very slow
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.
----------begin_max5_patcher---------- 1078.3oc0XF0jihBD.94jeETV2i4RABZh2a2V6KSU28KXpoRYhLYXKCjRHYm 41Z+ueBnFyFMprNty9Bp.Bc+Q2MM7s4y71JdkJ8.+E3QvrYea9rYlpzULq36 YdGhecWZrzzMON8qhsewagsIE8Uko5TQbx1X99xF3mNv3oTk4mPEUdLVs6EF e+lL5NkcRQQjkvEffHSYftDsdID7zkwQbR8iCDKwLo4BxeFfJmxmEbEO9.0z zemwhSAeRjlT1rcXTucjZmYOi3VMQ5+Vx9OSiH3Rnt1uOettXwOGZT.HPNTt 3GsRyB+f05GXr4CXqfw+Vv3GzNXZkILtxaAvqEr36DVTh86SokS4wLpjxUwJ lfWSeCPKCpqm2ps8CagjZXq4ApA6o5BUK1Y9gUZPbVNLUzrMTd71TCZf2Cnf mFOio8wJZi1R9sCELwBEhwjBS5ITpq7qcvVZTMhRYmoKSpMcmiypjipFez+o NryVoMyPQ5RKUzPYvlYEDk.MDs4ApAuydXlgg2yLC0JqycZeNOFr5BzkwmoI ahUpL11SJ5k2jEXtfyZTldhJdtr5x5qKBkSUgc9UsIeQjotcsvqgtlJ36u2p 1Uc9Dmojp2Jzba6FqlxGiU34sfTPpmal.9qL6bg7Qc3UgaXsF4fWkcSV6J9n 5g01F65Uo7FzJtawcBPj9gnlbG7G0.OW4ZXUp63Wr4HMSxjJJem032cauCTo LdO8F5JoJvefbDr3PzkvOCKqIL9Wc.81HxwLQN1UuALQkbkLPiW450NPFxuZ xbeGQIM6LMyUtXSvZMb3oShcIcx6Gj5Co2nwryceRRjwmbU3vs7HjOr9jwpW .Z6uMFBwneEHoo4pd95V090CEXEm7CgLljnHeyivA4q55Q+lhi8Y7W0jywiD iH1yDGN7DK7ib0WcrSpXm3vAJWcCb92G97C.k.7O4PpRVy1u0JKvk3E5BhtL u.4RJ5VOPr0crvFqUHBuEhq5v3B7fJNksqtpsSjJx5VEthqnwmqOmIN7dRVn 0us1NrCBrgejAaKNyGXIrbsZntxDKdLa1ArG+9N6Iz.q76YDt2uvXZMmwcSw wV8FN78Bc9R8r22R2Twzm7Xz7e71OMJit9qQkTbJaW4jTFiEfplpDpTw3Umr +wK2aRsN8BKIgxquTmvj5y1mTkPyMKZ8Udz2CJ.1g7fupOumhiNYltEG+Njm q76CfnnPzhVdKx71kIbzzDchucqISGYw8hrA+NPVbezD3zQVTOboMjE8tP17 PsGE4AvJhHQfDychCw1S4Csmr8pur6ESP1dhqmk3HykNWmH+NXwo0D+9DUB8 QWSf8XMgPlNemdHNlsLmFwwrwamxSvzIOg8QdVOcxSPeB0glV4oS9DNYxSeh 346nzXS8L93wy5KzxNjFAIOe7uXCrDtv7Iia+zLhdYzyrx9imqGsuO++Aojf RFB -----------end_max5_patcher-----------
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.
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.
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.
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.
Is this normal?
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.
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….
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?
Thanks for the tip Andrew
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.