Re: [Linuxsampler-devel] LinuxSampler GUI spec.

[Rui N. C. <rn...@rn...>]

Hi Vladimir,

>
> I've been thinking . . . for option lists such as engine, midi type,
> audio type and maybe even midi ports and instruments we may want some
> commands in LSCP to allow the client to figure out what server supports
> or has available. We already have GET AVAILABLE_ENGINES
> Should we also add:
> GET AVAILABLE_MIDITYPES
> GET AVAILABLE_MIDIPORTS
> GET AVAILABLE_AUDIOTYPE
> GET AVAILABLE_INSTRUMENTS
>
> This will allow the GUI to have less hard coded values and be more
> compatible with different versions of LS.
>

Yep, soon or later some of these will be quite handy.

votes++;

However the GET AVAILABLE_INSTRUMENTS command is surely prone to disparate
views. No vote here ;)

IMHO the best approach is that LOAD INSTRUMENT would be the proper place
to accept a regularly formed URI (e.g.
proto://hostname/directory/filename). Of course, this surely need support
on the linuxsampler server side.

The client just feeds the URI literally (it does not stream any data
whatsoever, just the LOAD INSTRUMENT command), but the UI may help a
little (e.g. common fileopen dialog, as of KDE's).


> Speaking about instruments . . . maybe we should also add a few more
> commands:
> ADD INSTRUMENT_LOCATION "url"
> REMOVE INSTRUMENT_LOCATION "url"
> GET INSTRUMENT_LOCATIONS
> RESET INSTRUMENT_LOCATIONS
>
> in this example, locally located instruments will have a location like
> "/mnt/gigs/" we could later add support for other location types such
> as "smb://server/share/dir/", etc. off the box locations may involve
> copying instruments to the local /tmp directory when they are loaded or
> perhaps streaming them over the network?! perhaps i'm just crazy and
> these "other location types" are overkill and nobody will ever need
> them anyway.

Overkill indeed, at least for the moment. But I see your point,
nevertheless. See above.

Bye.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...