[Rosegarden-devel] Re: RFC to developers: JACK transport BETA (fwd)

[Richard B. <bo...@bo...>]

Hi Kai,

Yes, Rosegarden definitely plans to implement JACK transport again.  We already have a
"master" infrastructure in place so it should be a simple matter of plugging everything
back in and working out the "slave" requirements.  I have to admit I gave up on implementing
or even following the discussion for JACK transport over the last six months (shocking how
time flies) waiting for a point just like this.  I believed you guys would get it right
and stable eventually and didn't feel like I could really contribute anything until we attempt
an implementation of it - which we surely will.  Might have to wait a couple of weeks though
for holidays etc.

Many thanks for letting us know and for your hard work on this one.  Hope we can do it
justice.

R

On Thursday 14 August 2003 7:21 pm, Kai Vehmanen wrote:
> Hi,
>
> I'll resending this directly to you as you've had interest in JACK
> transport stuff in the past. Your comments are welcome!
>
> ---------- Forwarded message ----------
> Date: Thu, 14 Aug 2003 21:12:59 +0300 (EEST)
> From: Kai Vehmanen <kai...@wa...>
> To: lin...@mu...
> Subject: RFC to developers: JACK transport BETA
>
> Hello,
>
> we are finally getting close to reaching the original goals set for
> JACK. The last big step has been the transport interface (to refresh
> your memory, take a look at the initial JACK/LAAGA use-scenario [1]).
>
> Thanks to Jack O'Quin's recent efforts, JACK now finally has a
> transport interface (and implementation) that fulfills all the
> requirements, and one that makes it possible to realize the example
> case [1].
>
> Now at this point we'd _really_ appreaciate your input. If you are
> short of time, at least take a look at our requirements list at the
> start of the design doc:
>
>         http://www.joq.us/jack/refman/transport-design.html
>
> The big questions are:
>
> 1. Is this API sufficient for your application? If not what is
>    missing and/or wrong?
>
> 2. Do you plan to add support for JACK transport to your app? If not,
>    what is the main reason not to (no interest, not useful for
>    your app, you prefer other solutions, etc)?
>
> In addition, comments regarding interface and implementation details
> are also welcome.
>
> [1] http://www.eca.cx/laaga
>
> ---------- Forwarded message ----------
> Date: 13 Aug 2003 22:08:09 -0500
> From: Jack O'Quin <jo...@io...>
> To: jac...@li...
> Subject: [Jackit-devel] CVS commit [0.77.0] new transport BETA test
>
>
> The new transport interfaces are ready for beta testing.  Bring on
> your applications and give it a try.  We will likely want to tweak a
> few things as problems are discovered.  So, please don't release any
> applications that depend on the new API until the beta test is
> finished and we cut a new JACK release.  But, the design seems stable
> right now.
>
> The reference manual is still at...
>
>   <http:www.joq.us/jack/refman>
>
> If you don't want to wait for CVS to catch up, here's a tarball...
>
>   <http:www.joq.us/jack/jack-audio-connection-kit-0.77.0-beta.tar.gz>
>
> Highlights...
>
>   * new minor version, API version and protocol version
>
>     -- to distinguish beta test level from earlier snapshots
>     -- source compatible with recent 0.76 snapshots
>     -- transport API not binary compatible: must recompile
>
>   * functional test complete (except internal clients)
>
>     -- if you have an internal transport client, try it
>     -- it might work, but I still have no test cases
>
>   * jackd -v option (--verbose) now prints useful transport state
>     change information for debugging JACK and clients both
>
>   * includes Bob Ham's makefile fix for the jackrec example client