30 Jan
2004
30 Jan
'04
3:47 p.m.
From: Frank Barknecht <fbar(a)footils.org>
I still don't understand what "Script UI" means. For example: In what
way has jMax a "Script UI" and Pd not?
My mistage.
For example, Csound has script UI because that is all what is there.
If PD can be fully programmed via text files, then it has script UI.
A script support is not exactly the same thing as script UI if
user has to use GUI at some point. Maybe "text UI" would be better
than "script UI".
Regards,
Juhana
30 Jan
30 Jan
4:37 p.m.
New subject: [linux-audio-dev] Jack Callbacks
The Jack API documentation says port_registration_callback is supposed
to be called on port register AND deregister, but it only seems to be
called when a port is registered.
So essentially, how can an app know when a jack port is deregistered?
In case you're wondering, I'm writing a modular jack patch bay, this is
the last hurdle before pre-release. So, uh, if you want a modular jack
patch bay, help a brother out. :)
(I would post this to jack-devel, but the server is giving me nonsense
and not letting me register)
-Dave
8:05 p.m.
New subject: [linux-audio-dev] Jack Callbacks
On Fri, Jan 30, 2004 at 03:35:37 -0500, Dave Robillard wrote:
The Jack API documentation says
port_registration_callback is supposed
to be called on port register AND deregister, but it only seems to be
called when a port is registered.
So essentially, how can an app know when a jack port is deregistered?
Youre right, theres a bug. I'l look at fixing it.
You might try jack_set_graph_order_callback(), which will detect it often,
but not always. I wonder why noones noticed this before.
- Steve
8:19 p.m.
New subject: [linux-audio-dev] Jack Callbacks
On Fri, 2004-01-30 at 19:01, Steve Harris wrote:
On Fri, Jan 30, 2004 at 03:35:37 -0500, Dave Robillard
wrote:
I did notice that the graph_order_callback was being called, but the
process of trying to figure out if a port has actually disappeared (or
something has just been connected) is both really gross and really
inefficient.
I can look into the bug some time next week (busy weekend), but if you
could do so beforehand, much appreciated..
-Dave
The Jack API documentation says
port_registration_callback is supposed
to be called on port register AND deregister, but it only seems to be
called when a port is registered.
So essentially, how can an app know when a jack port is deregistered?
Youre right, theres a bug. I'l look at fixing it.
You might try jack_set_graph_order_callback(), which will detect it often,
but not always. I wonder why noones noticed this before.
8:32 p.m.
New subject: [linux-audio-dev] Jack Callbacks
On Fri, Jan 30, 2004 at 07:18:02 -0500, Dave Robillard wrote:
On Fri, 2004-01-30 at 19:01, Steve Harris wrote:
Having looked at it some more I dont think it is a bug - I dont think a
client dosconnecting completely counts as deregistering.
Wether it should or not I dont know. I'm doing some more testing.
- Steve
On Fri, Jan 30, 2004 at 03:35:37 -0500, Dave
Robillard wrote:
I did notice that the graph_order_callback was being called, but the
process of trying to figure out if a port has actually disappeared (or
something has just been connected) is both really gross and really
inefficient. The Jack API documentation says
port_registration_callback is supposed
to be called on port register AND deregister, but it only seems to be
called when a port is registered.
So essentially, how can an app know when a jack port is deregistered?
Youre right, theres a bug. I'l look at fixing it.
You might try jack_set_graph_order_callback(), which will detect it often,
but not always. I wonder why noones noticed this before.
9:13 p.m.
New subject: [linux-audio-dev] Jack Callbacks
On Sat, Jan 31, 2004 at 12:28:56 +0000, Steve Harris wrote:
If you apply the patch at the end of this mail I think it should turn it
on, but I cant test it for various reasons.
- Steve
--- jackd/engine.c 13 Jan 2004 15:11:27 -0000 1.80
+++ jackd/engine.c 31 Jan 2004 01:07:26 -0000
@@ -1503,6 +1503,7 @@
for (node = client->ports; node; node = jack_slist_next (node)) {
port = (jack_port_internal_t *) node->data;
jack_port_clear_connections (engine, port);
+ jack_port_registration_notify (engine, port->shared->id, FALSE);
jack_port_release (engine, port);
}
I did notice
that the graph_order_callback was being called, but the
process of trying to figure out if a port has actually disappeared (or
something has just been connected) is both really gross and really
inefficient.
Having looked at it some more I dont think it is a bug - I dont think a
client dosconnecting completely counts as deregistering.
Wether it should or not I dont know. I'm doing some more testing.
31 Jan
31 Jan
2:53 p.m.
New subject: [linux-audio-dev] Jack Callbacks
On Fri, 2004-01-30 at 20:10, Steve Harris wrote:
If you apply the patch at the end of this mail I think
it should turn it
on, but I cant test it for various reasons.
- Steve
--- jackd/engine.c 13 Jan 2004 15:11:27 -0000 1.80
+++ jackd/engine.c 31 Jan 2004 01:07:26 -0000
@@ -1503,6 +1503,7 @@
for (node = client->ports; node; node = jack_slist_next (node)) {
port = (jack_port_internal_t *) node->data;
jack_port_clear_connections (engine, port);
+ jack_port_registration_notify (engine, port->shared->id, FALSE);
jack_port_release (engine, port);
}
Yep, that calls it. Maybe it wasn't there before because apps are
expected to deregister their ports before exiting? (None I've tested
actually do).
I don't see any problems having jack do it for clients though.. if the
client actually does deregister its ports before disconnecting, they
won't be around anymore (ie won't get double freed).
-Dave
1 Feb
1 Feb
6:41 a.m.
New subject: [linux-audio-dev] Jack Callbacks
On Sat, Jan 31, 2004 at 01:51:48PM -0500, Dave Robillard wrote:
The only thing I added was the notification to the other clients that the
ports were being deregistered. It always happend before.
We need a comment from the Benevolent Dictator as to wether this is a good
idea.
- Steve
---
jackd/engine.c 13 Jan 2004 15:11:27 -0000 1.80
+++ jackd/engine.c 31 Jan 2004 01:07:26 -0000
@@ -1503,6 +1503,7 @@
for (node = client->ports; node; node = jack_slist_next (node)) {
port = (jack_port_internal_t *) node->data;
jack_port_clear_connections (engine, port);
+ jack_port_registration_notify (engine, port->shared->id, FALSE);
jack_port_release (engine, port);
}
Yep, that calls it. Maybe it wasn't there before because apps are
expected to deregister their ports before exiting? (None I've tested
actually do).
I don't see any problems having jack do it for clients though.. if the
client actually does deregister its ports before disconnecting, they
won't be around anymore (ie won't get double freed). 
9:38 a.m.
New subject: [linux-audio-dev] Jack Callbacks
On Sat, Jan 31, 2004 at 01:51:48PM -0500, Dave
Robillard wrote:
The only thing I added was the notification to the other clients that the
ports were being deregistered. It always happend before.
We need a comment from the Benevolent Dictator as to wether this is a good
idea.
approved. it was just a thinko to not put this in before, rather than
a design feature. however, it does need to be tested to ensure it
doesn't cause "system wide" effects at client shutdown. if a couple
more people could test out steve's one line patch and report
themselves free of any problems, we can apply it.
--p
> --- jackd/engine.c 13 Jan 2004 15:11:27
-0000 1.80
> +++ jackd/engine.c 31 Jan 2004 01:07:26 -0000
> @@ -1503,6 +1503,7 @@
> for (node = client->ports; node; node = jack_slist_next (node)) {
> port = (jack_port_internal_t *) node->data;
> jack_port_clear_connections (engine, port);
> + jack_port_registration_notify (engine, port->shared->id, F
ALSE);
jack_port_release (engine, port);
}
Yep, that calls it. Maybe it wasn't there before because apps are
expected to deregister their ports before exiting? (None I've tested
actually do).
I don't see any problems having jack do it for clients though.. if the
client actually does deregister its ports before disconnecting, they
won't be around anymore (ie won't get double freed).
24 Feb
24 Feb
9:50 p.m.
New subject: [linux-audio-dev] Jack Callbacks
On Sun, 2004-02-01 at 08:34, Paul Davis wrote:
What was the verdict on this? Will it be in the next release of jack?
I can do whatever further testing is necessary, at least on my (limited)
hardware...
-Dave
On Sat, Jan 31,
2004 at 01:51:48PM -0500, Dave Robillard wrote:
The only thing I added was the notification to the other clients that the
ports were being deregistered. It always happend before.
We need a comment from the Benevolent Dictator as to wether this is a good
idea.
approved. it was just a thinko to not put this in before, rather than
a design feature. however, it does need to be tested to ensure it
doesn't cause "system wide" effects at client shutdown. if a couple
more people could test out steve's one line patch and report
themselves free of any problems, we can apply it.
--p > --- jackd/engine.c 13 Jan 2004 15:11:27
-0000 1.80
> +++ jackd/engine.c 31 Jan 2004 01:07:26 -0000
> @@ -1503,6 +1503,7 @@
> for (node = client->ports; node; node = jack_slist_next (node)) {
> port = (jack_port_internal_t *) node->data;
> jack_port_clear_connections (engine, port);
> + jack_port_registration_notify (engine, port->shared->id, F
ALSE);
jack_port_release (engine, port);
}
Yep, that calls it. Maybe it wasn't there before because apps are
expected to deregister their ports before exiting? (None I've tested
actually do).
I don't see any problems having jack do it for clients though.. if the
client actually does deregister its ports before disconnecting, they
won't be around anymore (ie won't get double freed). 
30 Jan
30 Jan
5:34 p.m.
Hallo,
Juhana Sadeharju hat gesagt: // Juhana Sadeharju wrote:
For example, Csound has script UI because that is all
what is there.
If PD can be fully programmed via text files, then it has script UI.
A script support is not exactly the same thing as script UI if
user has to use GUI at some point. Maybe "text UI" would be better
than "script UI".
Okay, thank you for clearing this up. I think, "text UI" would indeed
be a better name, because this is about a software having a text
interface, and not so much about, if it is "scriptable". In this
context Pd (and jMax) isn't really a synth with a text UI - although
one could control Pd through a text interface for example by using a
Python command line and OSC and one could write Pd patches in a text
editor if one is a very strange type of guy, but it isn't part of the
central concept of Pd or jMax.
ciao
--
Frank Barknecht _ ______footils.org__
7360
days inactive
7385
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
Dave Robillard -
Frank Barknecht -
Juhana Sadeharju -
Paul Davis -
Steve Harris