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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sun Aug 10 20:15:02 2014
This archive was generated by hypermail 2.1.8 : Sun Aug 10 2014 - 20:15:02 EEST