On Fri, Feb 01, 2008 at 04:08:32PM -0500, Paul Davis wrote:
Please STOP all this discussion of coupling DBUS to JACK. JACK is a
cross-platform tool. It is currently dependent on nothing but ANSI C and
POSIX, though on OS X and Windows it does have to work aroudn the fact
that those platforms'
On Feb 3, 2008 4:24 PM, Guillaume Pellerin [EMAIL PROTECTED] wrote:
I agree ! It is time now to have some OGG players inside our phones !
I would be interested in hearing why having a OGG player (or anything
else) on a phone would need java. Most linux (non-java) applications
run out of the box
On Fri, 2008-02-01 at 19:34 +0100, Kjetil S. Matheussen wrote:
int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
On Mon, Feb 04, 2008 at 03:14:54PM +0100, Kjetil S. Matheussen wrote:
How about this interface then?
void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);
And then a typical playback client would work like this:
jack_client_t *client=...
On Mon, 4 Feb 2008, Bob Ham wrote:
On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
On Mon, 4 Feb 2008, Bob Ham wrote:
Even less hassle is for clients to do nothing at all and leave the whole
business entirely for jackd. I suggest the following function instead:
int
Fons Adriaensen wrote:
On Sat, Feb 02, 2008 at 08:22:20PM +0200, Juuso Alasuutari wrote:
1) Switch to using the JACK D-Bus interface for lashd-jackd communication.
Paul D. has already replied to this...
2) Add a D-Bus control interface to LASH, which is supposed to
eventually replace
On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
On Mon, 4 Feb 2008, Bob Ham wrote:
Even less hassle is for clients to do nothing at all and leave the whole
business entirely for jackd. I suggest the following function instead:
int jack_set_autoconnect(jack_client_t *,
On Mon, 4 Feb 2008, Bob Ham wrote:
On Fri, 2008-02-01 at 19:34 +0100, Kjetil S. Matheussen wrote:
int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record
Fons Adriaensen:
On Mon, Feb 04, 2008 at 03:32:23PM +0100, Fons Adriaensen wrote:
Where jack_autoconnect() would use environment variables,
read .rc files, invoke the Buddha, or consult Paul Davis or
the oracle of Delphi to find out which ports to use, but
without requiring any special
On Mon, 2008-02-04 at 16:25 +0100, Kjetil S. Matheussen wrote:
On Mon, 4 Feb 2008, Bob Ham wrote:
On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
On Mon, 4 Feb 2008, Bob Ham wrote:
What I am suggesting is not to toggle autoconnecting for individual
clients, but to toggle
On Mon, 4 Feb 2008, Bob Ham wrote:
On Mon, 2008-02-04 at 16:25 +0100, Kjetil S. Matheussen wrote:
On Mon, 4 Feb 2008, Bob Ham wrote:
On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote:
On Mon, 4 Feb 2008, Bob Ham wrote:
What I am suggesting is not to toggle autoconnecting for
On Sat, Feb 02, 2008 at 08:22:20PM +0200, Juuso Alasuutari wrote:
1) Switch to using the JACK D-Bus interface for lashd-jackd communication.
Paul D. has already replied to this...
2) Add a D-Bus control interface to LASH, which is supposed to
eventually replace the current liblash server
Is there any reason why raw ALSA MIDI streams would stop
working if the process that opened them switches to
daemon mode ? (see mand daemon(3))
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
On Mon, Feb 04, 2008 at 03:40:12PM +, Bob Ham wrote:
On Mon, 2008-02-04 at 15:32 +0100, Fons Adriaensen wrote:
In other words, ** you could write this function today **.
The functionality you want does not require any changes
to jack.
The problem is, you're still going to get
On Mon, 2008-02-04 at 16:56 +0100, Fons Adriaensen wrote:
On Mon, Feb 04, 2008 at 03:40:12PM +, Bob Ham wrote:
On Mon, 2008-02-04 at 15:32 +0100, Fons Adriaensen wrote:
In other words, ** you could write this function today **.
The functionality you want does not require any changes
On Mon, Feb 04, 2008 at 03:32:23PM +0100, Fons Adriaensen wrote:
Where jack_autoconnect() would use environment variables,
read .rc files, invoke the Buddha, or consult Paul Davis or
the oracle of Delphi to find out which ports to use, but
without requiring any special support from jackd
Paul Davis wrote:
there are many parts of the JACK API that are not RT-bound. in fact,
basically *all* of it except for a clients process() callback, which a
client is not required to register.
I guess the synchronous response to port appearance/connection events
(like application
I'm assuming you meant to post this to the list, Paul.
In reply to your comment:
One of the motives behind jack-dbus is that a JACK control application
shouldn't have to be RT capable since it's not processing any
realtime-sensitive data anyway. From a technical perspective, could
libjack be
On Mon, 2008-02-04 at 22:23 +0200, Juuso Alasuutari wrote:
I'm assuming you meant to post this to the list, Paul.
In reply to your comment:
One of the motives behind jack-dbus is that a JACK control application
shouldn't have to be RT capable since it's not processing any
On Mon, 2008-02-04 at 18:18 +0200, Juuso Alasuutari wrote:
Fons Adriaensen wrote:
I fail the see the advantage of D-Bus over e.g. OSC via UDP or TCP.
The core issue is abstracting the interfaces involved. As long as it
serves to free LASH from being a libjack client
Why is freeing LASH from
Le 5 févr. 08 à 00:10, Krzysztof Foltman a écrit :
Paul Davis wrote:
there are many parts of the JACK API that are not RT-bound. in fact,
basically *all* of it except for a clients process() callback,
which a
client is not required to register.
I guess the synchronous response to port
21 matches
Mail list logo
