Re: [linux-audio-dev] What parts of Linux audio simply suck ?

On Mon, 20 Jun 2005 09:50:53 -0400
Paul Davis <paul@email-addr-hidden> wrote:

> > -Jack lack of OSC or any way to do parameter automation from the sequencer
>
> name one platform that allows this. just one.

There's none that i know of, but it would be cool to have anyways :)

> > -It is Impossible to do any sort of offline render, or high quality
> > render of a song (like, in 32/192khz) using JACK/Alsa
>
> i think you don't understand jack_freewheel().

Up to now, due to the lack of jack midi it wasn't really possible to
freewheel a complex setup (like several transport aware apps of which
one is a midi sequencer which drives softsynths). And it will again take
a while until jack midi has really been adopted. BTW: does jack midi
work in freewheeling mode, too?

> > -Saving/Restoring your project is just painfully hard. LASH doesnt help,
> > and even when I came up with the idea of it in the first place.
>
> that's because LASH's initial implementation was wrong and that
> following Bob's description of how to do it "right", nobody has found
> time to do it right.

Is there a design document for the Right Way out there? I would like to
take a look..

> > -Adding/Removing softsynths, linking connections, etc takes a while
> > having to use qjackctl, etc
>
> tell me a system in which this not true. i use the patchbay in qjackctl;
> if you don't like qjackctl, i'm sorry and i am sure rui is as well.

or use one of the console driven patchbay programs, like

jack_plumbing

or

jack_snapshot

> > -Lack of send%.. I just cant have a jack client doing a very high
> > quality reverb, only as wet processing and have clients send different
> > amounts of the signal to it, thus saving CPU
>
> this is completely ridiculous. the client can attenuate on its inputs.
> where would you rather have these controls - distributed across N apps
> or on the control interface for just one?

I agree with Paul here. Doing send/return/inserts, etc, is the job of a
jack mixer app. The ardour mixer is a good starting point for this..

> > -Lack of tempo-map based transport, I cant adapt my midi-only sequencer
> > , which works in bars,
>
> you can't do tempo-map based transport without sharing the tempo map.
> nobody has suggested a way to do this yet. please feel free.

Here i would like to chime in :) I think the mapping of BBT to frames
and the other way around isn't something that jack should be concerned
about. IMHO jack should only provide transport based on frame numbers.

Everything else, like different apps trying to agree with other apps
which frame corresponds to which BBT should really be handled by a
different mechanism.

The reason for this opinion of mine is that musical time is simply too
complex to be handled by one general mechanism. Think of different apps
using different meters, etc.. Or even a single app using different
meters on different tracks syncing to another app with yet another
meter.

I know, that dance music people for example would wipe this argument
away, but there's more complex music out there :) [sorry, if i offended
someone. I do not imply more complex == better].

IMHO the notion of BBT/tempo/etc. should be local to apps and if needed
be shared via another lib (which, if it finally settled down and became
quasi standard could again become part of jack).

Now the question is about how this mechanism should look like. I'm not
yet 100% sure, but i do have some ideas which i will ponder some more..

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/