7a5cea45e1
well, now... - Midi-Ports have a midi-buffer. - Midi-Tracks have a midi-buffer. - Midi-tracks have a diskstream. - Midi-diskstream has a midi-ring-buffer. - Midi-tracks have a delivery - The delivery can get a reference to the actual backend-ports - The delivery calls the Midi-Port's flush() buffer to send out queued events at the end of a cycle all clear ? :) - when splitting the process-cycle: only the Ports are informed. all other objects see a "normal" short process cycle starting at "0". The offset needs to be applied early on, so that internally routed buffers push the event at the correct time when combining the buffer with immediate and async events. Luckily Port::port_offset() is a static member, available to all, objects, which allows to bridge the conceptual gap between the diskstream and the delivery. There's a snag: When there's a note-on directly at the beginning of the loop it coincides with the panic message sent when looping. The panic comes before note events, so it *should* be good. Also the final note-offs (state tracker end of loop/region) are sent 1 sample too early (smells like an off-by-one), and are hence dropped. (no matter we send a panic right after it). It should really be at the same time, just before the panic.
Please see the Ardour web site at http://ardour.org/ for all documentation..
For information on building ardour:
http://ardour.org/development.html