21 Nov
2009
21 Nov
'09
1:49 p.m.
hi...
on a side note to the LADI discussion, which might even be my fault,
i want to tell you what i am currently up to.
in my opinion the inherent fail of session handler stuff, is that
somehow it wasnt easy enough or too complex to integrate lash support
into apps.
also many people didnt like to use some other ipc mechanism...
so to me the most natural way to do session notification was adding it
to jack. most apps are already listening for some jack callbacks.
(at least they should be listening for shutdown :)
so in my working copy of jack1 i have added 2 API calls:
typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* session_dir,
const char* prefix, void *arg);
int jack_set_session_callback(jack_client_t *client,
JackSessionCallback session_save_callback,
void *arg);
struct session_command * jack_session_notify (jack_client_t* client, jack_session_event_t
code, const char *path );
by calling jack_session_notify() the session callbacks of the listening
clients are invoked.
they are supposed to save their state, and return a string which
specifies, how they want to be restarted. the prefix parameter is unique
and there is a method to make this persistent over session reload.
the aggregation of the returned strings and unique ids is returned by
the notify call.
i have also changed jack_client_open which is able to accept a client
specified unique id. (this must be used when reloading state, so that
clients can be found again
so... a potential session handler is still required. and it needs to be
able to query the portconnections.
in order to restore them.
but clients are not required to have an extra dependency in order to
support sessions.
you may have noticed that this is currently ignoring alsa connections.
but i think we only need to add a way to publish an alsa seq id
via this protocol.
then a pure alsa client would also need to link to libjack and create a
jackclient with no ports and no process callback, in order to
participate in session handling.
i dont see a difference. it just links to "some" session handler lib.
the only disadvantage i am seeing currently is that apps are treating
jack like an abstract audio output, and getting a jack signal up to the
gui layers where the invokation of save is generally happening is a bit
cumbersome.
so far i have only patched oom and ardour. and ardour doesnt quit yet,
when requested.
well... tell me what you think :)
--
torben Hohn
21 Nov
21 Nov
2:22 p.m.
On 11/22/2009 04:49 AM, torbenh wrote:
hi...
on a side note to the LADI discussion, which might even be my fault,
i want to tell you what i am currently up to.
in my opinion the inherent fail of session handler stuff, is that
somehow it wasnt easy enough or too complex to integrate lash support
into apps.
Or not documented in a way that made it explicitly clear to a mortal
developer how to implement it quickly and correctly.
also many people didnt like to use some other ipc
mechanism...
so to me the most natural way to do session notification was adding it
to jack. most apps are already listening for some jack callbacks.
(at least they should be listening for shutdown :)
so in my working copy of jack1 i have added 2 API calls:
typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* session_dir,
const char* prefix, void *arg);
int jack_set_session_callback(jack_client_t *client,
JackSessionCallback session_save_callback,
void *arg);
struct session_command * jack_session_notify (jack_client_t* client, jack_session_event_t
code, const char *path );
by calling jack_session_notify() the session callbacks of the listening
clients are invoked.
they are supposed to save their state, and return a string which
specifies, how they want to be restarted. the prefix parameter is unique
and there is a method to make this persistent over session reload.
the aggregation of the returned strings and unique ids is returned by
the notify call.
i have also changed jack_client_open which is able to accept a client
specified unique id. (this must be used when reloading state, so that
clients can be found again
so... a potential session handler is still required. and it needs to be
able to query the portconnections.
in order to restore them.
but clients are not required to have an extra dependency in order to
support sessions.
you may have noticed that this is currently ignoring alsa connections.
but i think we only need to add a way to publish an alsa seq id
via this protocol.
then a pure alsa client would also need to link to libjack and create a
jackclient with no ports and no process callback, in order to
participate in session handling.
i dont see a difference. it just links to "some" session handler lib.
the only disadvantage i am seeing currently is that apps are treating
jack like an abstract audio output, and getting a jack signal up to the
gui layers where the invokation of save is generally happening is a bit
cumbersome.
so far i have only patched oom and ardour. and ardour doesnt quit yet,
when requested.
well... tell me what you think :)
I like the simplicity of the approach. FWIW, I would find it
straightforward to implement.
Would there be any issues with 20 different apps saving state at the
same time?
Patrick Shirkey
Boost Hardware Ltd
2:31 p.m.
On Sun, Nov 22, 2009 at 05:21:07AM +1100, Patrick Shirkey wrote:
depends on how big the state is...
but fwiw the notification callbacks are executed sequentially in the
current implementation.
--
torben Hohn
On 11/22/2009 04:49 AM, torbenh wrote:
yeah. it was a bit annoying in lash, that you needed to poll on a
separate fd in order to get your notifications.
this approach takes advantage of the jack client thread, so you dont
need to look for it in your mainloop.
however: save is invoked from a different thread. so this is still not
totally easy.
hi...
on a side note to the LADI discussion, which might even be my fault,
i want to tell you what i am currently up to.
in my opinion the inherent fail of session handler stuff, is that
somehow it wasnt easy enough or too complex to integrate lash support
into apps.
Or not documented in a way that made it explicitly clear to a mortal
developer how to implement it quickly and correctly. also many people didnt like to use some other ipc
mechanism...
so to me the most natural way to do session notification was adding it
to jack. most apps are already listening for some jack callbacks.
(at least they should be listening for shutdown :)
so in my working copy of jack1 i have added 2 API calls:
typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* session_dir,
const char* prefix, void *arg);
int jack_set_session_callback(jack_client_t *client,
JackSessionCallback session_save_callback,
void *arg);
struct session_command * jack_session_notify (jack_client_t* client, jack_session_event_t
code, const char *path );
by calling jack_session_notify() the session callbacks of the listening
clients are invoked.
they are supposed to save their state, and return a string which
specifies, how they want to be restarted. the prefix parameter is unique
and there is a method to make this persistent over session reload.
the aggregation of the returned strings and unique ids is returned by
the notify call.
i have also changed jack_client_open which is able to accept a client
specified unique id. (this must be used when reloading state, so that
clients can be found again
so... a potential session handler is still required. and it needs to be
able to query the portconnections.
in order to restore them.
but clients are not required to have an extra dependency in order to
support sessions.
you may have noticed that this is currently ignoring alsa connections.
but i think we only need to add a way to publish an alsa seq id
via this protocol.
then a pure alsa client would also need to link to libjack and create a
jackclient with no ports and no process callback, in order to
participate in session handling.
i dont see a difference. it just links to "some" session handler lib.
the only disadvantage i am seeing currently is that apps are treating
jack like an abstract audio output, and getting a jack signal up to the
gui layers where the invokation of save is generally happening is a bit
cumbersome.
so far i have only patched oom and ardour. and ardour doesnt quit yet,
when requested.
well... tell me what you think :)
I like the simplicity of the approach. FWIW, I would find it
straightforward to implement.
Would there be any issues with 20 different apps saving state at the
same time? 
5:37 p.m.
On Sat, 2009-11-21 at 18:49 +0100, torbenh wrote:
hi...
on a side note to the LADI discussion, which might even be my fault,
i want to tell you what i am currently up to.
in my opinion the inherent fail of session handler stuff, is that
somehow it wasnt easy enough or too complex to integrate lash support
into apps.
also many people didnt like to use some other ipc mechanism...
so to me the most natural way to do session notification was adding it
to jack. most apps are already listening for some jack callbacks.
(at least they should be listening for shutdown :)
so in my working copy of jack1 i have added 2 API calls:
typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* session_dir,
const char* prefix, void *arg);
int jack_set_session_callback(jack_client_t *client,
JackSessionCallback session_save_callback,
void *arg);
struct session_command * jack_session_notify (jack_client_t* client, jack_session_event_t
code, const char *path );
What is jack_session_event_t?
by calling jack_session_notify() the session callbacks
of the listening
clients are invoked.
they are supposed to save their state, and return a string which
specifies, how they want to be restarted. the prefix parameter is unique
and there is a method to make this persistent over session reload.
the aggregation of the returned strings and unique ids is returned by
the notify call.
What is this unique ID? Unique ID of what?
so... a potential session handler is still required.
and it needs to be
able to query the portconnections.
in order to restore them.
This could simply be implemented as another jack client, though, right?
but clients are not required to have an extra
dependency in order to
support sessions.
you may have noticed that this is currently ignoring alsa connections.
but i think we only need to add a way to publish an alsa seq id
via this protocol.
Personally I think it's pretty reasonable to expect Jack session
management to only support Jack things. Jack is portable to systems
where Alsa doesn't exist, for one thing. We have MIDI and bridges
between them, just keep the system clean, I say. The session manager
can deal with that crap if it wants to.
the only disadvantage i am seeing currently is that
apps are treating
jack like an abstract audio output, and getting a jack signal up to the
gui layers where the invokation of save is generally happening is a bit
cumbersome.
I like the simplicity of this, but this last part is a problem. I'm not
sure doing this in Jack1 where all callbacks are in the process thread
is really appropriate. Then again, I don't think all callbacks being in
the process thread is appropriate, period ;) I guess this is just
another case of this error anyway, but an extremely bad one. You're
going to get a pretty severe drop-out saving a ton of stuff to disk in
the audio thread!!
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).
Then we have ONE very straightforward plain C session management API, no
reason for app authors to reject implementing it, and implementations of
it do not affect those who have implemented the API. In the process
we'd have solved the same problem for plugins, which needs doing anyway.
-dr
6:36 p.m.
On Sat, Nov 21, 2009 at 04:37:17PM -0500, David Robillard wrote:
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.
yes. the session handler is simply another jack client.
(it might even be ardour :)
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.
yup. i will fix this up. its not really complicated to do.
however it hasnt been a real problem yet.
On Sat, 2009-11-21 at 18:49 +0100, torbenh wrote:
enum { JackSessionSave, JackSessionQuit }
hi...
on a side note to the LADI discussion, which might even be my fault,
i want to tell you what i am currently up to.
in my opinion the inherent fail of session handler stuff, is that
somehow it wasnt easy enough or too complex to integrate lash support
into apps.
also many people didnt like to use some other ipc mechanism...
so to me the most natural way to do session notification was adding it
to jack. most apps are already listening for some jack callbacks.
(at least they should be listening for shutdown :)
so in my working copy of jack1 i have added 2 API calls:
typedef char *(*JackSessionCallback)(jack_session_event_t code, const char* session_dir,
const char* prefix, void *arg);
int jack_set_session_callback(jack_client_t *client,
JackSessionCallback session_save_callback,
void *arg);
struct session_command * jack_session_notify (jack_client_t* client, jack_session_event_t
code, const char *path );
What is jack_session_event_t? by calling
jack_session_notify() the session callbacks of the listening
clients are invoked.
they are supposed to save their state, and return a string which
specifies, how they want to be restarted. the prefix parameter is unique
and there is a method to make this persistent over session reload.
the aggregation of the returned strings and unique ids is returned by
the notify call.
What is this unique ID? Unique ID of what? so... a
potential session handler is still required. and it needs to be
able to query the portconnections.
in order to restore them.
This could simply be implemented as another jack client, though, right? but clients are not required to have an extra
dependency in order to
support sessions.
you may have noticed that this is currently ignoring alsa connections.
but i think we only need to add a way to publish an alsa seq id
via this protocol.
Personally I think it's pretty reasonable to expect Jack session
management to only support Jack things. Jack is portable to systems
where Alsa doesn't exist, for one thing. We have MIDI and bridges
between them, just keep the system clean, I say. The session manager
can deal with that crap if it wants to. the only disadvantage i am seeing currently is
that apps are treating
jack like an abstract audio output, and getting a jack signal up to the
gui layers where the invokation of save is generally happening is a bit
cumbersome.
I like the simplicity of this, but this last part is a problem. I'm not
sure doing this in Jack1 where all callbacks are in the process thread
is really appropriate. Then again, I don't think all callbacks being in
the process thread is appropriate, period ;) I guess this is just
another case of this error anyway, but an extremely bad one. You're
going to get a pretty severe drop-out saving a ton of stuff to disk in
the audio thread!!
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.
Then we have ONE very straightforward plain C session management API, no
reason for app authors to reject implementing it, and implementations of
it do not affect those who have implemented the API. In the process
we'd have solved the same problem for plugins, which needs doing anyway.
-dr
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
7:05 p.m.
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.
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?
Cheers,
-dr
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.
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.
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
8:03 p.m.
On Sun, 2009-11-22 at 00:39 +0100, torbenh 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 assume it would/could be saved as part of a session, so "persistent"
that way. Either way, arguments apply since it should be "meaningful".
Clients changing properties of other clients seems like probably a bad
idea to me.
The client in effect has nothing to do with anything about a session
until it is explicitly saved or restored. I may just misunderstand
what you mean this ID to mean, but it seems really wonky.
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.
Ah. Maybe not very portable?
It seems sort of redundant to have restoring via command line when we
already have a restore callback that does that anyway. What if instead
we give a unique ID to the application itself only(*). Then, before
calling jack_client_open, the client must call
jack_client_set_id(myappid) so Jack (and/or the session manager) knows
what it is. The session manager can then restore it via the usual
callbacks. Then app authors only need to implement restore once, in the
callback, and don't have to deal with command line stuff at all (which
can be pretty annoying in some cases). I suppose this requires that the
command line arguments of the app are basically irrelevant though, but
the appp could save those same settings to the save directory too...
Just a thought, trying to make it simpler and purely API based.
-dr
(* Pedantically, all versions of an application that are save/restore
compatible to the same directory)
On Sat, Nov 21, 2009 at 06:05:01PM -0500, David
Robillard wrote:
Yeah, that kind of thing is the problem... you said it is an ID for the
session, where does the client get this ID to pass to jack_client_open?
The only thing I can see making sense is where the app passes an ID to
jack is if it's passing an ID for /the application itself/, so the
session manager could then say "ah, this session requires you" and send
it the appropriate restore command. Multiple instances of the same app
would send the same ID, and the session manager would send them
different restore events.
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. 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. but the client name would not work, if i had a
hydrogen running, and
loaded a session with another hydrogen.
This is why an ID for the session doesn't work either, as far as I can
see.
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.
8:30 p.m.
On Sat, 2009-11-21 at 19:03 -0500, David Robillard wrote:
Ah. Maybe not very portable?
It seems sort of redundant to have restoring via command line when we
already have a restore callback that does that anyway. What if instead
we give a unique ID to the application itself only(*). Then, before
calling jack_client_open, the client must call
jack_client_set_id(myappid) so Jack (and/or the session manager) knows
what it is. The session manager can then restore it via the usual
callbacks. Then app authors only need to implement restore once, in the
callback, and don't have to deal with command line stuff at all (which
can be pretty annoying in some cases). I suppose this requires that the
command line arguments of the app are basically irrelevant though, but
the appp could save those same settings to the save directory too...
Just a thought, trying to make it simpler and purely API based.
On second thought, I see the utility of command line stuff, though maybe
it should be sent as argc and argv for more portability and less
nuisance for apps that just want to pass them straight through? (no need
to assemble an actual command line string, which is both annoying and
not portable)
Cheers,
-dr
8:46 p.m.
On Sat, Nov 21, 2009 at 07:30:02PM -0500, David Robillard wrote:
on windows you only have an args string.
however i dont see what an app which cant save its state. (iE
jack_netsource, should do ?)
snprintfing some commandline string shouldnt be a problem at all.
i dont see why this should be so complicated.
On Sat, 2009-11-21 at 19:03 -0500, David Robillard
wrote:
> Ah. Maybe not very portable?
well... commandline parameters are not totally portable, thats true.
thats why i basically avoid to say that its commandline parameters.
on windows or osx, it might be something different.
also i dont have a restore callback.
hmm... you proposed one int other mail i guess...
>
> It seems sort of redundant to have restoring via command line when we
> already have a restore callback that does that anyway. What if instead
> we give a unique ID to the application itself only(*). Then, before
> calling jack_client_open, the client must call
> jack_client_set_id(myappid) so Jack (and/or the session manager) knows
> what it is. The session manager can then restore it via the usual
> callbacks. Then app authors only need to implement restore once, in the
> callback, and don't have to deal with command line stuff at all (which
> can be pretty annoying in some cases). I suppose this requires that the
> command line arguments of the app are basically irrelevant though, but
> the appp could save those same settings to the save directory too...
err... which app doesnt support loading a statefile when being started
via commandline ?
i also think that the restore event only makes things more complex.
Just a thought, trying to make it simpler and purely API based.
On second thought, I see the utility of command line stuff, though maybe
it should be sent as argc and argv for more portability and less
nuisance for apps that just want to pass them straight through? (no need
to assemble an actual command line string, which is both annoying and
not portable)
Cheers,
-dr
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
11:25 p.m.
On Sun, 2009-11-22 at 01:46 +0100, torbenh wrote:
Not sure what you're getting at here. Of course apps have to save their
state, that's the whole point?
On Sat, Nov 21, 2009 at 07:30:02PM -0500, David
Robillard wrote:
I assumed it was a possible value of jack_session_event_t, but I see
it's not. n/m
On Sat, 2009-11-21 at 19:03 -0500, David
Robillard wrote:
> Ah. Maybe not very portable?
well... commandline parameters are not totally portable, thats true.
thats why i basically avoid to say that its commandline parameters.
on windows or osx, it might be something different.
also i dont have a restore callback.
hmm... you proposed one int other mail i guess... i also think that the restore event only makes things
more complex.
It allows loading a different session without shutting down the app
entirely, but I guess that's no big loss. Apps shouldn't take forever
to start up anyway :) (plus it's much more bug prone)
On second
thought, I see the utility of command line stuff, though maybe
it should be sent as argc and argv for more portability and less
nuisance for apps that just want to pass them straight through? (no need
to assemble an actual command line string, which is both annoying and
not portable)
on windows you only have an args string.
however i dont see what an app which cant save its state. (iE
jack_netsource, should do ?) snprintfing some commandline string shouldnt be a
problem at all.
i dont see why this should be so complicated.
I don't think this makes it more complicated, but it does make it
portable, standard C, and makes sense for libraries/plugins; but I don't
really care enough to argue about it. If jack_initialize and friends
took an argv that would be a strong argument for it, but they just take
an arbitrary string, so I guess that's an argument to use a string. For
internal clients the returned string would not be a command line but the
argument to jack_initialize
-dr
22 Nov
22 Nov
2:42 a.m.
On Sat, Nov 21, 2009 at 10:25:06PM -0500, David Robillard wrote:
Not sure what you're getting at here. Of course apps have to save their
state, that's the whole point?
netsource doesnt have code to save its state.
its state is completely described by its commandline.
and i guess there are some small apps which are the same.
but argv wouldnt change matters here.
what i find cumbersome, is that youd need to mess with argv also.
(consider running app bla.conf ... edit stuff... session save.
app would save <uuid>.conf into session dir. so the
correct startup is "app /path/to/<uuid>.conf"
(or a string containing jack_load :)
--
torben Hohn
On Sun, 2009-11-22 at 01:46 +0100, torbenh wrote:
i am getting dizzy when i think of ardour receiving reload this other
session event :)
i also think that the restore event only makes
things more complex.
It allows loading a different session without shutting down the app
entirely, but I guess that's no big loss. Apps shouldn't take forever
to start up anyway :) (plus it's much more bug prone) On second
thought, I see the utility of command line stuff, though maybe
it should be sent as argc and argv for more portability and less
nuisance for apps that just want to pass them straight through? (no need
to assemble an actual command line string, which is both annoying and
not portable)
on windows you only have an args string.
however i dont see what an app which cant save its state. (iE
jack_netsource, should do ?) snprintfing some commandline string shouldnt be a
problem at all.
i dont see why this should be so complicated.
I don't think this makes it more complicated, but it does make it
portable, standard C, and makes sense for libraries/plugins; but I don't
really care enough to argue about it. If jack_initialize and friends
took an argv that would be a strong argument for it, but they just take
an arbitrary string, so I guess that's an argument to use a string. For
internal clients the returned string would not be a command line but the
argument to jack_initialize
5476
days inactive
5477
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
3 participants
participants (3)
-
David Robillard -
Patrick Shirkey -
torbenh