M4L, serialosc and send/receive latency

Quick technical question about using a grid in M4L.
Since you cannot select a grid twice in two different tracks (serialosc accepts only one connection, right ?), is it good practice to use send/receive to spread the grid press messages to different tracks, and to merge led messages to one “master track” containing the serialosc bpatcher ?
I’ve always used this method, but I’m not sure if this adds latency.

Very noobish answer but if I understood you correctly, you can use “Auto-focus” to have 2 or more M4l patches with a grid attached loaded.
A couple of M4l devices I use have this implemented.
Also iirc it was initially provided by stretta.

Thanks for the answer.
I’m not talking about several apps in several tracks, but one app controlling stuff located in several tracks. This is useful when ‘regions’ of the grid talk to ‘satellite’ patches located on different tracks.

1 Like

I’m using my 256 grid within Ableton in my custom M4L devices just the way you said by usind send and receive messages. For me it works fine with normal latency times …

1 Like

What do you mean by this ? My tests seem to prove that there is (99% of the time) no latency introduced by send/receive, but I might be mistaken and never found an official statement about it.

What I was trying to say is that I didn’t notice any latency times or if there was any kind of latency it was minimal. The only thing to keep in mind is that depending on how you build your M4L patch you will probably will need to introduce deferlow messages when updating the grid led lights. I was getting CPU peaks until I put deferlow messages.

1 Like

Ok, I seem to come to the same conclusion. But still wish I could find an official statement regarding send/receive latency across devices. Thanks !