21 Nov
2009
21 Nov
'09
7:39 p.m.
On Sat, Nov 21, 2009 at 06:05:01PM -0500, David Robillard wrote:
its not really persistent. the client needs to set them.
and i dont have means yet, to set them from another client.
do you think thats necessary ?
I don't understand what the reply string means. You said "return a
string which specifies, how they want to be restarted". Specifies
what/how, precisely?
oh... its the key to session reload.
it basically is the command line, thats needed to get this client up
again, and make it load its config.
(so simple clients might specify their config via commandline switches
or whatever)
another special handling is for ardour, which isnt able to save a
session into some session dir.
so my current patch makes it save a snapshot, and puts the path to the
snapshot into a file in session dir.
then it returns: "alink_loader /path/to/session/<prefix>.alink"
we have already identified a weakness for ncurses clients.
so we might need to specify some environment variables, which are usable
in these commandlines. $XTERM or something...
On Sat, 2009-11-21 at 23:36 +0100, torbenh wrote:
Is there a purpose to this ID other than getting the client name? If
it's about client name, we should just use the client name.
what would happen if the name was already taken ?
i basically had lash in mind when i imlemented it.
but the client name would not work, if i had a hydrogen running, and
loaded a session with another hydrogen.
On Sat, Nov 21, 2009 at 04:37:17PM -0500, David
Robillard wrote:
[...]
What is
this unique ID? Unique ID of what?
unique id, which is meant to persistent. a unique client id for the
session.
jack_client_open is extended to accept this uuid. so upon session
restore, the client will have the same uuid again.
and the session manager will be able to query its jack client name.
and then be able connect things again. i have added:
void jack_client_set_cookie( jack_client_t *client, const char *key, const char *value
);
char *jack_get_cookie_by_uuid( jack_client_t *client, const char *uuid, const char *key
)
now. this allows for publishing such things.
Excellent. Jack has needed a metadata system really, really badly for
ages. Need to be able to set stuff for ports too though. This could
elegantly solve so many long standing problems of jack (e.g. the auto
connect problem).
However, notes from a metadata nerd:
- The key should REALLY REALLY be a URI. The manager (or whoever else,
including JACK itself) needs to be able to actually infer some meaning
from a "cookie", or the system isn't really that useful. Because this
is persistent, and can be used to convey meaningful information, using a
free text (i.e. meaningless) key is an extremely bad idea.
- There should probably be an optional const char *type parameter, to
specify the type of the value.
I still don't see why this uuid is needed when any existing client
already has a unique name.
noted above, because the client name uniqueness doesnt necessary persist
between session loads.
But this
leads me to the main point I want to make:
My take on this general thing is that a simple API like this is very
definitely the right path, but if anything I would like it not even tied
to Jack itself either. The reason session management has failed to take
hold is too much implementation-defined crap, breaking APIs, complexity
to implement, and all that kind of thing.
How about taking it one step farther: define this API in a single C
header, which would be very small, not tied to ANY implementation
whatsoever, and implementable by both plugins and hosts (this last part
is a very big win IMHO). All this header would define is a descriptor
(struct) with the necessary methods. Sort of a ladspa.h for session
management, except even simpler. How you actually get this descriptor
would be the only implementation dependent part (e.g. a host could pass
it to a plugin, or Jack could have a single new call to return it).
interesting idea. i am not sure about the semantics of the reply strings
in the plugin case though.
Cheers,
-dr
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language