[proposal] connection veto callback

[Gabriel M. Beddingfield]

On Tue, June 2, 2009 2:32 pm, Marc-Olivier Barre wrote:

>>> > I just thought I'd point out:
>>> >
>>> > rah@myrtle:~$ dpkg -L jackd | grep init.d/j
>>> > /etc/init.d/jackd
>>>
>>> wow, what distro is that ? we want names ! :D
> On Tue, 2 Jun 2009 12:25:12 -0700 (PDT), James Warden <warjamy@...>
> wrote:
>> debian ;)
>
> Well, IMHO this deserves a bug report. Starting jack as root at boot time
> seems very foolish to me...
>
> Anyone from the debian multimedia strike team aware of this ?

FWIW, it *is* disabled by default.  You have to manually edit
/etc/default/jackd to enable boot-time starting of jackd.

--
               G a b r i e l   M   B e d d i n g f i e l d

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Bob Ham]

On Tue, 2009-06-02 at 15:42 -0400, Paul Davis wrote:

> On Tue, Jun 2, 2009 at 3:26 PM, Bob Ham <rah@...> wrote:
> > On Tue, 2009-06-02 at 12:02 -0400, Paul Davis wrote:
> >
> >> Presumably
> >> you'd like to put together a DAW from about 8 different pieces and
> >> have something like LASH to bind it all into something moderately
> >> coherent. The good news: you can. The other news: more than 90% of the
> >> people use who a DAW have no interest in doing this. Their definition
> >> of "one thing" is a LOT more expansive than the one you're suggesting,
> >> and it includes not having to start a different program in order to
> >> make connections from tracks.
> >
> > To argue for putting together a DAW from about 8 different pieces: those
> > 90% have no interest whatsoever in the difference between clicking on an
> > icon in an application toolbar and clicking on an icon in a GNOME panel.
> > The purpose of LASH is to enable systems where, from the user's
> > perspective, there is no difference between the two.
>
> that maybe the declared goal of LASH. but LASH has failed to meet even
> a subset of this goal to date. to suggest that you could use it to
> patch together programs that did metering, disk i/o, monitoring, FX,
> waveform display and editing into a coherent "single experience"
> strikes me as almost dangerously naive.

I admit it's not a simple task.  I don't think it's impossible, though.
I now use LASH when I'm making music, which seems to prove its
viability.

I think it would be naive to believe system builders will take advantage
of it in its current state.  I don't think it's naive to believe they
may in future.  The only thing that prevents LASH (or rather, its
successor, JIZZ) achieving the stability and features needed for status
as infrastructure is the (lack of) time people can to devote to it.

> there actually *is* a project that has tried to do something like that
> - they used libardour as a starting point. as far as i can tell, the
> project is dead and they got a great deal further than i think anyone
> could get using distinct processes that happened to started and
> interconnected via LASH.

Well, as noted, I use LASH.  If others have tried using libardour and
failed, then surely they haven't got further?

--
Bob Ham <rah@...>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Tue, Jun 02, 2009 at 03:42:51PM -0400, Paul Davis wrote:

> that maybe the declared goal of LASH. but LASH has failed to meet even
> a subset of this goal to date. to suggest that you could use it to
> patch together programs that did metering, disk i/o, monitoring, FX,
> waveform display and editing into a coherent "single experience"
> strikes me as almost dangerously naive.

Nobody is asking for separating things up to that level.

But there are *many* occasions where I'd prefer to have either
recording (whithout the complexities of a mixer added) or mixing
(whithout any reference to 'tracks') , or both but separated.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Tue, Jun 02, 2009 at 03:42:51PM -0400, Paul Davis wrote:

> that maybe the declared goal of LASH. but LASH has failed to meet even
> a subset of this goal to date. to suggest that you could use it to
> patch together programs that did metering, disk i/o, monitoring, FX,
> waveform display and editing into a coherent "single experience"
> strikes me as almost dangerously naive.

On prerequisite of having a single app providing a 'single experience'
is coherent design - different aspects of a the single app not being
in conflict with each other but having been analysed as a whole.

The problem with the 'Unix way' is not that there are multiple apps,
this can be made completely invisible to the end user. It is the
absence of coherent design. And that can even hit a single application
if things get added to it that provide a level of functionality that
was never considered at the start. It is this and nothing else that
is currently hitting Jack, and everything that depends on it e.g. LASH.
Jack has reached a level where it can't be improved on except by
changing things in non-compatible ways, for the simple reason that
the things we want to add now were ignored when it was originally
designed. There are limits to incremental design, and we are just
hitting them.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Bob Ham]

On Tue, 2009-06-02 at 15:42 -0400, Paul Davis wrote:
> On Tue, Jun 2, 2009 at 3:26 PM, Bob Ham <rah@...> wrote:
> > On Tue, 2009-06-02 at 12:02 -0400, Paul Davis wrote:
> >
> >> Presumably
> >> you'd like to put together a DAW from about 8 different pieces

> > To argue for putting together a DAW from about 8 different pieces

> to suggest that you could use it to
> patch together programs that did metering, disk i/o, monitoring, FX,
> waveform display and editing into a coherent "single experience"
> strikes me as almost dangerously naive.

After re-reading, it looks like there's been some miscommunication here.
By "DAW" I'm not referring to a hard-disk recording application but
simply a workstation used for digital audio work.  So, metering, disk
i/o, monitoring, FX, waveform display, and editing would be functions of
a hard-disk recorder.  A hard-disk recorder, sequencer, soft-synths and
DSP processors would be parts of a DAW.  In fact, metering, monitoring
and FX don't necessarily have to be part of a hard-disk recorder and can
be separated out (cf. jack-mixer and jack-rack.)

LASH aims to put together a DAW rather than a hard-disk recorder.

--
Bob Ham <rah@...>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Tue, Jun 2, 2009 at 5:15 PM, Fons Adriaensen <fons@...> wrote:
> The problem with the 'Unix way' is not that there are multiple apps,
> this can be made completely invisible to the end user.

At incredible cost in terms of infrastructure design and intra-app
complexity. Why does Linux audio look the way it does (even just the
JACK niche of the wider ecosystem)? Precisely because we've taken this
approach further than any other platform. We have some of the plumbing
but not all of it, and designing and implementing the plumbing for
integration on this scale is a formidable task. I might even say
"close enough to impossible as to make no difference". I'm not talking
about integration on the level of "i can record hydrogen in ardour" -
I'm talking about soloing having a coherent effect and a coherent
visual display across the entire "system". Do the same thing for all
manner of subtle behavioural switches, and the plumbing required to
make this work across processes and applications developed by
independent parties is almost unimaginable to me. It works for the
command line because there is one data type - text - and a very fixed
data flow. I cannot think of a single attempt to expand unix  IPC
concepts (such as branching pipes) has ever taken off other than in
experimental/academic operating systems. Well, OK, JACK :)

> It is the
> absence of coherent design. And that can even hit a single application
> if things get added to it that provide a level of functionality that
> was never considered at the start. It is this and nothing else that
> is currently hitting Jack, and everything that depends on it e.g. LASH.
> Jack has reached a level where it can't be improved on except by
> changing things in non-compatible ways, for the simple reason that
> the things we want to add now were ignored when it was originally
> designed. There are limits to incremental design, and we are just
> hitting them.

I disagree with everything you have written in this paragraph.
Absolutely and totally. I believe you are sensitive to and observing
social issues with the JACK development "team" and mistaking them for
technical issues. I believe this is a huge mistake even IF those
social issues are also rather significant.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Tue, Jun 02, 2009 at 05:35:46PM -0400, Paul Davis wrote:

> On Tue, Jun 2, 2009 at 5:15 PM, Fons Adriaensen <fons@...> wrote:
>
> > It is the
> > absence of coherent design. And that can even hit a single application
> > if things get added to it that provide a level of functionality that
> > was never considered at the start. It is this and nothing else that
> > is currently hitting Jack, and everything that depends on it e.g. LASH.
> > Jack has reached a level where it can't be improved on except by
> > changing things in non-compatible ways, for the simple reason that
> > the things we want to add now were ignored when it was originally
> > designed. There are limits to incremental design, and we are just
> > hitting them.
>
> I disagree with everything you have written in this paragraph.
> Absolutely and totally. I believe you are sensitive to and observing
> social issues with the JACK development "team" and mistaking them for
> technical issues. I believe this is a huge mistake even IF those
> social issues are also rather significant.

On the contrary. I have been ignoring any 'social' aspects
and been quite blunt lately. Not only in this thread but in
others as well. Not because I enjoy acting like that - and I
like the people I know here too much to be nasty to them - but
because IMHO the technical issues should not be obscured by
the social ones.

But we can agree to disagree. For me there have been (and there
still are) a number of Jack related issues such that if I look
at the complete picture the conclusion is that it would be a
good thing to start thinking about something that at some time
could become Jack N (N > 2) and that would include some radical
changes.    

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Tue, Jun 2, 2009 at 6:05 PM, Fons Adriaensen <fons@...> wrote:
>
> On the contrary. I have been ignoring any 'social' aspects
> and been quite blunt lately.

I think you misunderstood my use of the term "social". I did not mean
anything related to "politeness" or "pleasant interactions".
The way JACK evolves is actually highly dependent on the interactions
of a rather small number of people (certainly at present).
The context and content of those interactions is not, IMO, very
favorable right now. This means that even if technical solutions are
actually relatively easy to achieve (they may be, or they may not), it
has become MUCH harder to reach them because there really isn't a good
consensus on the goals, strategies and techniques that should be part
of the future of JACK. This is unfortunate. Its not caused by any of
the recent discussions. I don't think its caused by any bad-faith
actions or choices on anyone's part either, which makes it even
harder. We've just ended up in a place where its become much harder to
make decisions with any level of consensus, and I don't believe that
this is because of any technical issues at all.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org