[proposal] connection veto callback

[Nedko Arnaudov]

Nedko Arnaudov <nedko@...> writes:

> Isn't single vetoer fixing this issue? ;)
> User starts JACK, then starts the vetoer, then no other all can
> supersede the existing vetoer. Just like X11 window managers work.

s/all/app/

no other app

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
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:31:35PM +0300, Nedko Arnaudov wrote:

> Fons Adriaensen <fons@...> writes:
>
> > But if someone is adding the veto callback to use
> > it in a dumb way, all it takes is _one_ extra
> > line of code, which is a near copy of one he/she
> > already has, to bypass the no-ports restriction.
> > Something like 10 seconds extra work.
> >
> > It will just become an idiom: if you want a
> > veto callback open a second client for it.
>
> Isn't single vetoer fixing this issue? ;)
> User starts JACK, then starts the vetoer, then no other all can
> supersede the existing vetoer. Just like X11 window managers work.

A single one would fix it, as long as it is the end
user who decides on what this single veto client is.

If it's 'the first one' then I'm pretty sure the
next release of <your favourite distro> will launch
one from the X11 init scripts, just as they do today
to force things like DesktopDirs, GnomeFuseDaemon,
and a collection of other things down your throat.

Second, if there is such a single app vetoing
connections then all clients are at the mercy of
it, and it would be a much cleaner solution to have
just a single client being able to make (non-local)
connections.

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 9:02 AM, Fons Adriaensen <fons@...> wrote:
>
> A single one would fix it, as long as it is the end
> user who decides on what this single veto client is.
>
> If it's 'the first one' then I'm pretty sure the
> next release of <your favourite distro> will launch
> one from the X11 init scripts, just as they do today
> to force things like DesktopDirs, GnomeFuseDaemon,
> and a collection of other things down your throat.

Regular distros haven't shown much interest in JACK to date. If they
had, the mess with /etc/security/limits.conf would probably have been
fixed by now. Given that no current distribution starts JACK from any
startup script, it seems rather unlikely they'd start a veto client.

If they did do this, then its a single command, more or less, to
remove the offending daemon permanently.

> Second, if there is such a single app vetoing
> connections then all clients are at the mercy of
> it, and it would be a much cleaner solution to have
> just a single client being able to make (non-local)
> connections.

I can't parse the intent of this.
_______________________________________________
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 09:20:21AM -0400, Paul Davis wrote:

> Regular distros haven't shown much interest in JACK to date. If they
> had, the mess with /etc/security/limits.conf would probably have been
> fixed by now. Given that no current distribution starts JACK from any
> startup script, it seems rather unlikely they'd start a veto client.
>
> If they did do this, then its a single command, more or less, to
> remove the offending daemon permanently.

Is it ? Please tell me how to remove these ones that
create a file system (not even listed in /etc/fstab)
that can't be removed by root:

fons      2290     1  0 11:19 ?        00:00:00 /usr/libexec/gvfsd
fons      2327     1  0 11:19 ?        00:00:00 /usr/libexec//gvfs-fuse-daemon /home/fons/.gvfs

and its family:

fons      2524     1  0 11:23 ?        00:00:00 /usr/libexec/gvfs-hal-volume-monitor
fons      2526     1  0 11:23 ?        00:00:00 /usr/libexec/gvfs-gphoto2-volume-monitor

and friends:

fons      2223     1  0 11:19 ?        00:00:00 /usr/bin/gnome-keyring-daemon -d --login
fons      2417     1  0 11:19 ?        00:00:00 /usr/libexec/gconfd-2

Note that I don't run Gnome. Login manager is xdm.
So don't please tell me run gnome-config or some such.


> > Second, if there is such a single app vetoing
> > connections then all clients are at the mercy of
> > it, and it would be a much cleaner solution to have
> > just a single client being able to make (non-local)
> > connections.
>
> I can't parse the intent of this.

Instead of allowing all client to make connections,
and then having one to veto them (which means that
whatever a client may want to do could be futile),
it would be much simpler to have just one client
that can make connections in the first place.
 
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 11:27 AM, Fons Adriaensen <fons@...> wrote:
>> If they did do this, then its a single command, more or less, to
>> remove the offending daemon permanently.
>
> Is it ? Please tell me how to remove these ones that
> create a file system (not even listed in /etc/fstab)
> that can't be removed by root:

you should talk to the kernel guys about that. they added ways to
mount filesystems other than /etc/fstab many years ago, and a number
of different subsystems have been using them ever since. you might
start with autofs and its associated configuration files.

> Note that I don't run Gnome. Login manager is xdm.
> So don't please tell me run gnome-config or some such.

you apparently do run GNOME without intending to. all the daemons
you've listed are part of the GNOME desktop system which your
distribution is apparently keen to run. it is not the job of JACK to
fix up desktop environments, especially given its status as a
multiplatform technology. if you don't want GNOME running you've
apparently picked the wrong distribution.

none of the daemons you've listed are realistically comparable to what
we're talking about. it would started as a "service" which means that
it can disabled with rm /etc/<path to rc file> or more orderly tools
related to chkconfig, or a distributions equivalent of
system-config-services.

> Instead of allowing all client to make connections,
> and then having one to veto them (which means that
> whatever a client may want to do could be futile),
> it would be much simpler to have just one client
> that can make connections in the first place.

Its clear that you and several other JACK users would like this model.
Its also clear that other JACK users would not. We are not going to
enforce one model or the other when both have clear benefits in
certain kinds of workflows and use cases. The idea of the veto system
is to allow both models to exist, according to the wishes of the user.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Fons Adriaensen <fons@...> writes:

> Instead of allowing all client to make connections,
> and then having one to veto them (which means that
> whatever a client may want to do could be futile),
> it would be much simpler to have just one client
> that can make connections in the first place.

This is what most people want. But maybe they don't know that ardour and
other autoconnect apps make jack connections for them. Superapps like
this tend to treat jack as interface to audio hardware. OTOH there are
people that want to save and restore jack sessions with multiple
applications. Superapp response is usually to reimplement functionality
that other apps are providing. This is not very unix-like. You no longer
have simple apps that do one thing and do it well.

Albert Einstein said that "everything should be made as simple as
possible, but no simpler."

I tend to agree. ;)

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


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

[Paul Davis]

On Tue, Jun 2, 2009 at 11:45 AM, Nedko Arnaudov <nedko@...> wrote:
> This is not very unix-like. You no longer
> have simple apps that do one thing and do it well.

We left that world a long time ago in most areas of end-user
computing. Get over it.

Those of us who are still intensely involved in the how and why of
computers are still able to take a unix-like approach to most tasks,
and the veto proposal doesn't change that.

Besides, it all comes down to how you define "one thing". 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.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Paul Davis <paul@...> writes:

> On Tue, Jun 2, 2009 at 11:45 AM, Nedko Arnaudov <nedko@...> wrote:
>> This is not very unix-like. You no longer
>> have simple apps that do one thing and do it well.
>
> We left that world a long time ago in most areas of end-user
> computing. Get over it.

You but not me. Ironically the rebels dbus trechnology helps to achieve
this. ;)

> Those of us who are still intensely involved in the how and why of
> computers are still able to take a unix-like approach to most tasks,
> and the veto proposal doesn't change that.

Single vetoer will be simpler for multi app users. And superap
environment should have songle vetoer too.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
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 06:45:38PM +0300, Nedko Arnaudov wrote:

> Fons Adriaensen <fons@...> writes:
>
> > Instead of allowing all client to make connections,
> > and then having one to veto them (which means that
> > whatever a client may want to do could be futile),
> > it would be much simpler to have just one client
> > that can make connections in the first place.
>
> This is what most people want. But maybe they don't know that ardour and
> other autoconnect apps make jack connections for them. Superapps like
> this tend to treat jack as interface to audio hardware. OTOH there are
> people that want to save and restore jack sessions with multiple
> applications. Superapp response is usually to reimplement functionality
> that other apps are providing. This is not very unix-like. You no longer
> have simple apps that do one thing and do it well.

What Ardour does makes sense in cases where there are
no other clients involved, and all ports it uses are
either its own or the system: ones which are persistent.

With non-persistent ports involved things go wrong - if
a client isn't running the connections are not made, and
they also just forgotten. Same if you have to restart a
client. Saving the session will save it without the
connections that couldn't be made, so opening a session
to change a small detail can be enough to make it forget
connections. Not thinking twice before you click 'Save
and Quit' can do the same.

An app can't be 'the central place where everything is
organised' and a 'civilised component' relying on others
to do some things at the same time.

At least latest Ardour does not reconnect its auditioner
if the session was saved with it disconnected (thanks * 100).
It still sets the auditioner gain to 0dB even if saved with
a much lower value, which can be almost as dangerous.

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

[Glynn Clements]

Fons Adriaensen wrote:

> > Regular distros haven't shown much interest in JACK to date. If they
> > had, the mess with /etc/security/limits.conf would probably have been
> > fixed by now. Given that no current distribution starts JACK from any
> > startup script, it seems rather unlikely they'd start a veto client.
> >
> > If they did do this, then its a single command, more or less, to
> > remove the offending daemon permanently.
>
> Is it ? Please tell me how to remove these ones that
> create a file system (not even listed in /etc/fstab)
> that can't be removed by root:
>
> fons      2290     1  0 11:19 ?        00:00:00 /usr/libexec/gvfsd
> fons      2327     1  0 11:19 ?        00:00:00 /usr/libexec//gvfs-fuse-daemon /home/fons/.gvfs
>
> and its family:
>
> fons      2524     1  0 11:23 ?        00:00:00 /usr/libexec/gvfs-hal-volume-monitor
> fons      2526     1  0 11:23 ?        00:00:00 /usr/libexec/gvfs-gphoto2-volume-monitor
>
> and friends:
>
> fons      2223     1  0 11:19 ?        00:00:00 /usr/bin/gnome-keyring-daemon -d --login
> fons      2417     1  0 11:19 ?        00:00:00 /usr/libexec/gconfd-2

The GVFS daeons are auto-started by the GVFS library. If you don't run
any GVFS-enabled programs, the daemons won't get started. You can
always kill off the daemons after the fact (although regarding FUSE,
bear in mind that no-one (including root) can unmount a "busy"
filesystem).

If you have root access, you can use "chmod o= /dev/fuse" (or the
equivalent udev configuration) to prevent user-space programs from
being able to create filesystems. Also, rmdir'ing ~/.gvfs and
replacing it with a file may be enough to prevent gvfs-fuse-daemon
from operating (I don't use GVFS, so I can't say for certain).

If you dislike such "features" generally, you might want to consider
using Gentoo, which offers fine-grained control over which features
are enabled for a package. Binary-based distributions tend to enable
everything.

--
Glynn Clements <glynn@...>
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Bob Ham]

On Mon, 2009-06-01 at 17:20 +0200, torbenh@... wrote:
> On Sun, May 31, 2009 at 11:20:02PM +0100, Bob Ham wrote:

> > If we provide the facility for a port-connection veto,
> > people will make use of that.  They may produce systems that work for
> > themselves but not for others.  They may produce systems that work for
> > everybody.
>
> an normal jackapp has no business with connection vetos. its intended
> for control apps only.

There's no need to be like that.. programmers that write control apps
are people just like programmers that write normal jack apps :-)

--
Bob Ham <rah@...>


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

[Bob Ham]

On Tue, 2009-06-02 at 09:20 -0400, Paul Davis wrote:

> Given that no current distribution starts JACK from any
> startup script

I just thought I'd point out:

rah@myrtle:~$ dpkg -L jackd | grep init.d/j
/etc/init.d/jackd


--
Bob Ham <rah@...>


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

[Marc-Olivier Barre-3]

On Tue, 02 Jun 2009 20:07:13 +0100, Bob Ham <rah@...> wrote:
> On Tue, 2009-06-02 at 09:20 -0400, Paul Davis wrote:
>
>> Given that no current distribution starts JACK from any
>> startup script
>
> 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

Marc-Olivier Barre.
------
Participez au black-out anti-HADOPI :
http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[James Warden]

debian ;)

--- On Tue, 6/2/09, MarcO'Chapeau <marco@...> wrote:

> From: MarcO'Chapeau <marco@...>
> Subject: Re: [Jack-Devel] [proposal] connection veto callback
> To: jack-devel@...
> Date: Tuesday, June 2, 2009, 3:19 PM
> On Tue, 02 Jun 2009 20:07:13 +0100,
> Bob Ham <rah@...>
> wrote:
> > On Tue, 2009-06-02 at 09:20 -0400, Paul Davis wrote:
> >
> >> Given that no current distribution starts JACK
> from any
> >> startup script
> >
> > 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
>
> Marc-Olivier Barre.
> ------
> Participez au black-out anti-HADOPI :
> http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

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

[Bob Ham]

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.

--
Bob Ham <rah@...>


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

[James Warden]

and I don't want to throw more oil on fire but there is yet another jackd config file, namely /etc/dafult/jackd.

It looks like this by default:
============
# Set to "yes" to start jackd at boot
START_DAEMON=no

# The jackd process will run under this user
USER=fred

# Options to pass to jackd
OPTIONS="-R -d alsa -d hw"
============

so one can simply replace with his/her favorite options, and configure the startup level of the init service (with e.g. sysv-rc-conf).

J.
--- On Tue, 6/2/09, James Warden <warjamy@...> wrote:

> From: James Warden <warjamy@...>
> Subject: Re: [Jack-Devel] [proposal] connection veto callback
> To: jack-devel@..., "MarcO'Chapeau" <marco@...>
> Date: Tuesday, June 2, 2009, 3:25 PM
>
> debian ;)
>
> --- On Tue, 6/2/09, MarcO'Chapeau <marco@...>
> wrote:
>
> > From: MarcO'Chapeau <marco@...>
> > Subject: Re: [Jack-Devel] [proposal] connection veto
> callback
> > To: jack-devel@...
> > Date: Tuesday, June 2, 2009, 3:19 PM
> > On Tue, 02 Jun 2009 20:07:13 +0100,
> > Bob Ham <rah@...>
> > wrote:
> > > On Tue, 2009-06-02 at 09:20 -0400, Paul Davis
> wrote:
> > >
> > >> Given that no current distribution starts
> JACK
> > from any
> > >> startup script
> > >
> > > 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
> >
> > Marc-Olivier Barre.
> > ------
> > Participez au black-out anti-HADOPI :
> > http://www.laquadrature.net/fr/APPEL-HADOPI-blackout-du-net-francais
> > _______________________________________________
> > Jack-Devel mailing list
> > Jack-Devel@...
> > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> >
>
>
>      
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

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

[Bob Ham]

On Tue, 2009-06-02 at 21:19 +0200, MarcO'Chapeau wrote:

> On Tue, 02 Jun 2009 20:07:13 +0100, Bob Ham <rah@...> wrote:
> > On Tue, 2009-06-02 at 09:20 -0400, Paul Davis wrote:
> >
> >> Given that no current distribution starts JACK from any
> >> startup script
> >
> > 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

rah@myrtle:~$ cat /etc/debian_version
squeeze/sid

but, I should also point out:

rah@myrtle:~$ grep no /etc/default/jackd
START_DAEMON=no


--
Bob Ham <rah@...>


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

[Marc-Olivier Barre-3]

> --- On Tue, 6/2/09, MarcO'Chapeau <marco@...> wrote:
>
>> Bob Ham <rah@...>
>> wrote:
>> > On Tue, 2009-06-02 at 09:20 -0400, Paul Davis wrote:
>> >
>> >> Given that no current distribution starts JACK
>> from any
>> >> startup script
>> >
>> > 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 ?

--
Marc-Olivier Barre
XMPP ID : marco@...
www.MarcOChapeau.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Marc-Olivier Barre-3]

On Tue, 2 Jun 2009 12:28:34 -0700 (PDT), James Warden <warjamy@...>
wrote:

> and I don't want to throw more oil on fire but there is yet another jackd
> config file, namely /etc/dafult/jackd.
>
> It looks like this by default:
> ============
> # Set to "yes" to start jackd at boot
> START_DAEMON=no
>
> # The jackd process will run under this user
> USER=fred
>
> # Options to pass to jackd
> OPTIONS="-R -d alsa -d hw"
> ============
>
> so one can simply replace with his/her favorite options, and configure

the
> startup level of the init service (with e.g. sysv-rc-conf).

Ok, this works. I would have been very surprised if something like that was
started at boot time as root.

--
Marc-Olivier Barre
XMPP ID : marco@...
www.MarcOChapeau.org
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

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.

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.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org