On Tue, 22 Nov 2005 15:34:14 +1100
Dave Robillard <drobilla(a)connect.carleton.ca> wrote:
> this line seems to be the culprit
(liblash/loader.c):
>
> #define XTERM_COMMAND_EXTENSION "&& sh || sh"
I don't know of anyone else actually using the
terminal client stuff
anyway, so I might just remove that part if there's no objections...
Personally i have no objection to removing the XTERM_COMMAND_EXTENSION.
There's another issue though with LASH which again might be due to my
limited understanding of it.
Imagine starting a lash client where you specify a state file on the
commandline (i.e. someone sent you a synth patch and you want to use it
in one of your projets now).
Ok, so you start your synth as
mySynth AwesomePatchStateFile
This is the commandline LASH will remember for this client app. Now
during the course of the LASH session the user chooses to load a
different statefile via the apps menu. Then the user chooses to save the
LASH prject and then close it (the synth will then save the current
statefile to the dir specified by LASH).
Now what happens on restore?
Well, the client will be started by LASH with the commandline
mySynth AwesomePatchStateFile
and right after starting up it will get a Restore_Data_File (or whatever
it was called) event from LASH which tells it to use a different
statefile (the one from the LASH project dir).
So basically the client loads two statefiles right after the other.
Which is a waste of cpu cycles and might generally be a nuisance for all
kinds of reasons.
I ardour i try to hack around this by stripping "offending" commandline
options from argv before passing it to lash_init.. If this is the
recommended way of solving the problem, i'd suggest the docs should be
updated to reflect this. For different app designs the solutions might
of course look different, so the docs should at least point out the
problem.
Any thoughts?
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org