On Mon, 20 Jun 2005 09:50:53 -0400 Paul Davis <[EMAIL PROTECTED]> 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/
