Miles Davies

Would someone mind testing this out in a M4L midi effect device please.

I'm getting a slight fluctuation with my measurement count in ms for note length (Duration) on a single, same length note looping in a Live Clip.

I'm looking for a more accurate way to get to the exact same number count each time it plays the same note.

It would be good to know the reason for the fluctuation.

comment

message

print

number

button

counter

toggle

metro

unpack

borax

midiparse

midiin

Would someone mind testing this out in a M4L midi effect device please.
I'm getting a slight fluctuation with my measurement count in ms for

fluctuation-in-time-from-note-duration-m4l-midi-effect-device

I tested your patch and got the same results you must be seeing: In a 1 bar clip in 4/4, with a perfect 16th note on the downbeat of each bar, the 4th note @ piano roll position 1.4 always reads as 119ms, while the rest read 120ms.

What's funny is that depending on the length of the clip and the length of the notes in question, different positional values will have the error, but it's always the same position for that set. I can delete all the other notes in the test clip, and just leave the 16th note @1.4 and it will be off by 1ms every time... and ditto for the problematic position with 32nd notes or dotted 16ths.

I rebuilt your patch using mostly different objects, and got the exact same results relative to what borax is telling me.

Very interesting, but I have no idea what causing this. Sorry.

I tested your patch and got the same results you must be seeing: In a 1 bar clip in 4/4, with a perfect 16th note on the downbeat of each bar, the 4th note @ piano roll position 1.4 always reads as 119ms, while the rest read 120ms. 

What's funny is that depending on the length of the clip and the length of the notes in question, different positional values will have the error, but it's always the same position for that set. I can delete all the other notes in the test clip, and just leave the 16th note @1.4 and it will be off by 1ms every time... and ditto for the problematic position with 32nd notes or dotted 16ths. 

Very interesting, but I have no idea what causing this. Sorry. 

Thanks for testing it and clarifying. I appreciate your trying.

I too built an alternative patch, but measuring in transport ticks as I am trying to build an accurate polyrhythm sequencer triggered by notes lengths, but the ticks count was out by up to 5 ticks. Causing the sequencer to occasionally jump to the next beat at higher note intervals.

Not sure if its Max or Live causing the problem, or if there is another way to measure more accurately.

Is there anyone from @cycling74 that would shed some light on this? Thanks.

I am on the latest versions of Live and Max. Scheduler in Overdrive and Audio Interrupt checked.

Thanks for testing it and clarifying. I appreciate your trying. 

The problem could be that time data in clips are beats as float numbers while the metro interval is ms or ticks as integer.

That's a great point, BROC. That would explain the absolute consistency of the 1ms difference I was seeing.

Thanks BROC. I'll rework the patch along those lines to see if it is a fix.

Fluctuation in time from note duration (M4L midi effect device)