20 Jun
2005
20 Jun
'05
3:34 p.m.
On Mon, 20 Jun 2005 09:50:53 -0400
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
There's none that i know of, but it would be cool to have anyways :)
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?
Is there a design document for the Right Way out there? I would like to
take a look..
or use one of the console driven patchbay programs, like
jack_plumbing
or
jack_snapshot
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..
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/
-Jack lack of
OSC or any way to do parameter automation from the sequencer
name one platform that allows this. just one. -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().
-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.
-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. -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? -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.