Recording MIDI notes into Live Clip - timing issues

    Nov 06 2013 | 8:00 pm
    Second question for the day :)
    I'm recording MIDI notes into the currently playing Live Clip from a Max for Live device. The duration I calculate for them seems to work just fine. However, I am about to get grey hair because of their positioning.
    My strategy (failed) so far has been this: figure out what the currently playing Live clip is, observe its playing_position, continuously put it into an [f] and when the time comes to record a MIDI note, just send a bang to the f before the call list goes out to the [live.object] that's representing the Clip.
    The problem is that things go horribly wrong this way, the notes are all over the place.
    Is there a best practice to record the notes on-the-fly, to the right position? Is this a general timing issue which is unresolved? Or am I doing something very wrong?

    • Nov 06 2013 | 9:43 pm
      It's a general timing issue with the Live API, in particular time resolution of observers. For example, I've measured that the observer of playing_position sends its value only at intervals of 60 milliseconds.
    • Nov 06 2013 | 9:47 pm
      Thanks! I think I've heard of this before. For the current project, I only need to record very regular intervals, so I've settled with manually calculating the position using [plugsync~] in the meantime. This is far from ideal, however, because when the clip loops over, the notes already recorded are slightly off with the notes being played out of the M4L device, leading to audible and very annoying phasing. Still a solvable problem, but very annoying to have to work around this...
    • Dec 06 2013 | 3:32 am
      I was pulling my hair out too when trying to get the timing right for the start of MIDI notes. After several attempts I found that a when object going into translate provided the best accuracy. This method goes off of Live's timeline, but it might be adaptable to the timeline of a clip.
      This was the trick:
      when -> translate bars.beat.ticks ms @mode position
      Here is the sub patch for context:
    • Dec 06 2013 | 2:49 pm
      Brilliant, just what I needed. Thanks for this!