Re: [LAU] [Bulk] Re: Jack transport - was - Ardour/Muse Jack tempo lock

From: Tim E. Real <termtech@email-addr-hidden>
Date: Sun Aug 10 2014 - 20:47:50 EEST

On August 10, 2014 07:11:24 PM Robin Gareus wrote:
> 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.

Yeah I know. Bummer. Recorded waves are incorrectly shifted etc.

I'm working very hard at the moment on adding automatic + manual
 latency compensation to MusE.

It is sooo crucial - currently the top priority for me !

Man, it sure ain't easy, at least in MusE's case...

PS: While on the subject...

Regarding LADSPA and DSSI and VST DSSI plugins:

Many of them report a latency through a 'latency' output port.
But is there a standard?
Do some report frames of latency while others report in milliseconds?

Tim.

>
> > 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 Mon Aug 11 00:15:01 2014

This archive was generated by hypermail 2.1.8 : Mon Aug 11 2014 - 00:15:01 EEST