On Wed, 24 Jul 2002, Andy Wingo wrote: [JACK transport control] > I've been meaning for some time to make a universal transport control, a > separate app whose sole purpose would be transport control. > This would be rad (TM) for a number of reasons: > > 1) Get your whole rig to start at once, even if you're not using > ecasound or ardour
Yup, I agree, a generic (and simple) transport master client would be a very valuable addition. Even though "works out-of-the-box" is a very high priority item in ecasound development, I must admit that achieving this goal is anything but easy with applications of this size. If nothing else, broken soundcard hardware, kernel drivers (and sometime the kernel itself) and libraries make it practically impossible to prepare for all situations. And the last thing people developing new client apps need is to worry about bugs and misc problems of other large client apps. In other words there should be enough jack_simple_client style apps to cover all JACK functionality. Getting these apps to work should require no more effort than that required by jackd. This is critical for getting more developers writing JACK clients. Requiring installation and use of ardour/ecasound/someotherbigapp is not good. > 3) funny tricks with beats -- speed up, slow down the tempo. Loop the > last 4 beats. All the GDAM tricks, but on a system-wide level.* [...] > * You'll run into some buffering issues here when streaming from disk. > Oh well. Actually the JACK transport API is quite flexible in this way. Ecasound doesn't yet (if ever, ecasound prefers per-audio-object looping to session-level looping) support the loop transport mode, but it does support "live seeks" (ie. random-access style changes in transport position during successive callbacks). If the disk-i/o subsystem can't keep up with the changes, the rt-part (callbacks) will ignore it until it has caught up. Of course for sample-accurate looping, the looping transport mode is still the only real solution. It's also true that transport-change patterns involving regulars jumps (like skipping x samples during each callback) will cause trouble to clients with slow non-rt i/o subsystems. But anyways, the most important feature IMHO is the basic transport control (ie. start, stop and non- or near-rt fw, rw and setpos). Most importantly this solves the old LAAGA use-case with drum-machine+soft-synth+multitracker (<http://eca.cx/laaga>). -- http://www.eca.cx Audio software for Linux!
