Re: [Jack-Devel] A kit of (commandline) standard-tools?

On Thu, Oct 20, 2011 at 6:23 PM, k <[hidden]> wrote:
> Hello
>
> On Thu, 20 Oct 2011 23:56:46 +0200
> Adrian Knoth <[hidden]> wrote:
>
>> On Thu, Oct 20, 2011 at 11:47:58PM +0200, k wrote:
>>
>> Hi!
>>
>> > jack is great stuff, but i think it's missing a set of tools wich
>> > should be included in mainstream distributions, along with a fixed,
>> > minimalist but thorough set of options and features to enable easy use
>> > of jack from the commandline and embedded systems. ...i mean that
>> > 'unix'-way.

we believe that this has already been done. from time to time, new
tools emerge that should really be a part of this command set (in much
the same way that awk wasn't originally part of the command line
toolset for unix, but eventually became so). recently, jack.stdin and
jack.stdout are examples of such new tools that might eventually join
the suite that we already offer.

>> > I thought about this when doing field-recording with arecord
>> > (alsa-tools standard commandline record tool) piped to the
>> > flac-commandline-encoder. I know of and i use jack_capture for this
>> > now, but i really think that tools like this should be included
>> > officially (so to say: $ apt-get install jack-tools).

which package these tools are in is up to your distribution. they are
ALWAYS present in the source distribution from jackaudio.org.

>> I still fail to undestand your point. apt-get install jack-capture
> It's not included in my debian repository (debian 5). Is it in 6? Then i'm sorry. But it's "third-party". Can i be sure my scripts work with it, let's say, a year from now?

as noted by adi, this is an issue you MUST take up with your
distribution and/or the author(s) of jack_capture. we do not include a
tool like jack_capture in JACK because we consider there to be too
many design issues/choices for it to be reasonable for us to "bless" a
particular program as "the right way". that said, jack_capture is a
fine program.

>> > In my oppinion this would also include common tools like jack_connect
>> > or jack_lsp,
>>
>> Huu? jack_connect and jack_lsp are part of the jackd package. What's
>> wrong with that?
> I didnt say anything against it, did you read my mail entirely?
> It's lacking documentation, and i don't trust that commandline-"interface" to be consistent over time. that is all.
> (this is what i trust about arecord, amixer, etc. my scripts for these tools are years old and still work.)

the tools cited are a part of JACK and their API has not changed in
any backward incompatible way in at least 5 years.

> I was talking about scripting, not interactive shell. I was thinking about something like grepping (from one line) physical outputs and using the portnames for jack-connect. jack_lsp --properties gives 2 lines for a port. Whats your point with bash-completion here? anyway...

the names of JACK ports are decided by clients and the backends, with
some attempt at uniform/consistent naming of the ports representing
the backend.

> I know (and i think i made clear) that the issues mentioned are all possible to do right now (and so i am using it), but my concerns were about consistency, consistency to new versions of jack, to newer distributions, etc.

we do not change JACK arbitrarily. the API has been
backward-compatible for almost all clients for many, many years. you
talk about this as though there is a clear problem.

i'm assuring you that you can rely on the tools that are part of the
tools/ directory of the source distribution to remain consistent and
present *in the source distribution of JACK* for the foreseeable
future.

1319150483.2238_0.ltw:2,a <CAFa_cKmU5rCKupmgNx+Z0HB0VT5zYR1jwrqvPVYnzhvBPdJtCQ at mail dot gmail dot com>