On 08/10/2014 06:24 PM, Len Ovens wrote: > Tim E. Real wrote: >> I believe it is crucial that all the apps (MusE included) use the complete >> full feature set of the Jack Transport API for the best accuracy. ...and port latencies! Sadly, many jack applications ignore those which leads to offsets, even though they share transport position. > Is there a record enable in there? No, there isn't. > It seems to me it would be worthwhile > for recording audio in one application and MIDI in another or for punch in > out. The application would choose to see or ignore such a signal. It's not that easy. Record enable is an application state not a position in time. Rec-arm needs to allocate buffers, prepare files on disk etc etc. It's not realtime-safe. For playback there's already a special state: JackTransportStarting. Applications should acknowledge that they're ready to roll before jack goes into "play". A lot of jack-clients forgo this which is already trouble enough, though not directly harmful in this case (just possibly out of sync playback). Adding ranges (loop, punch), application state (rec-en), or even varispeed support would likely increase the mess rather than solve anything. All clients need to explicitly agree in order for that to work properly. Then, there's also the requirement: "We want to provide for ongoing binary compatibility as the transport design evolves." [1] (IOW: "don't break existing jack applications") which complicates the actual implementation. That being said, yes, it would be cool. Multiple independent transports would be very nice as well, and I want a pony, too :) ciao, robin [1] http://jackaudio.org/api/transport-design.html _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
