broc

I have 2 midi devices in serial connection each using its own (but identical) time control (metro>transport), and it turns out that the timing of the second device is *early* in relation to the first.

The patch below generating a note on every beat may be used to reproduce this behavior. Just build a device from it and load the device twice on a midi track. As instrument load some drum sticks, for instance operator preset 'Sidestick-808'.

When running you'll notice that the timing doesn't match. For synced timing the delay parameter of the second device must be adjusted (about 12ms).

I'm wondering if this behavior is intended or a bug?

timing-of-midi-devices-in-serial-connection

I've copied your maxpat into a MFL Midi Effect Device.

For notein I made a MIDI Clip with notes on 1, 1.2, 1.3 and 1.4. This matches with the metro. Then I copied this clip to a new track.

Both tracks initially had a NI AkousticPiano device.

I could not hear much difference between 0 delay and 12ms delay with this piano.

Then I changed to the 'Sidestick-808'. This is a very crisp sound indeed.

The best preset for my ears is 0 delay. 12ms delay can be heard as 2 sticks. So my experience is opposite to yours! It doesn't matter if the clip is on the same track as the metro or on a track of it's own.

I'm using Ableton Live with MFL on a Windows XP machine with a 4 core Intel processor running at 2.4 Ghz with 3.5Gb of RAM.

I've copied your maxpat into a MFL Midi Effect Device. 

I'm using Ableton Live with MFL on a Windows XP machine with a 4 core Intel processor running at 2.4 Ghz with 3.5Gb of RAM.


thanks for looking at it, but I think you misunderstood the configuration.

Don't use a clip for comparison. Just load my device *twice* on the same track.

So the midi data flow should be like this:

Don't use a clip for comparison. Just load my device *twice* on the same track.
So the midi data flow should be like this:

I loaded to patches to one track and now I hear what you are pointing at.

If I open the first of the devices in Edit mode the synchronization changes. I need to compensate for about 22ms now. When I open the second one in edit mode synchronization stays the same.

I can't imagine this behaviour being a 'hidden feature'. In my opinion it's neither intended nor a bug. It's a latency issue. The signal of the first device has to travel through the second and this takes apparently about 12 ms. The delay of the second device compensates for this.

Live and MFL have to share the same cpu using threads. Threads are either on different cores or they are time-sliced. The 12 ms latency is not constant but it gets better and worse from beat to beat, the synchronization of the beats sounds irregular.

I'm afraid Cycling '74 nor Ableton can take this issue away. I guess a lot of development time for MFL was already used for solving timing/latency problems.

If I open the first of the devices in Edit mode the synchronization changes. I need to compensate for about 22ms now. When I open the second one in edit mode synchronization stays the same. 

I can't imagine this behaviour being a 'hidden feature'. In my opinion  it's neither intended nor a bug. It's a latency issue. The signal of the first device has to travel through the second and this takes apparently about 12 ms. The delay of the second device compensates for this.

I'm afraid Cycling '74 nor Ableton can take this issue away. I guess a lot of development time for MFL was already used for solving timing/latency problems.


Your explanation makes sense to me. I understand that timing/latency issues are inherent to real time systems like M4L. But I think it's useful to identify and quantify them as much as possible, at least from the users view.

Timing of midi devices in serial connection