Re: [Linuxsampler-devel] Current Status

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

Hi Christian,

>>
>> Vladimir proposed that devices should be commonly named, in alternation
>> to be numerically identified. That way one could query if a device
>> instance[...]
>
> That would be than e.g. (in case of two created Alsa sound devices):
>
> C: "LIST AUDIO_OUTPUT_DEVICES"
> S: "Alsa:0,Alsa:1"
>
> So the numerical IDs would still be there, but there would be the driver
> prefix. Is that how you thought it to be?
>

Hmmm.... naaah :) I'd rather extend some LSCP commands to accomodate for
device naming, instead of breaking what's already specified.

Let me suggest the following:

a) The device name will be given by a new device instance parameter:
"name". This new parameter value is obviously a name identifier as a
character string (type: STRING). This parameter is mandatory and by
default should be initialized as the concatenation of the driver type name
and an ordinal number (e.g. "Alsa:1", "Alsa:2" or "Jack:1"). This number
should be unique for the respective device driver and type, not
necessarily identical to the device number ID.

b) The device enumeration commands, GET/LIST...DEVICES, should accept an  
optional parameter list, that act as a query search criteria. Only the
existing devices that match the given parameter values are part of the
command result.

   Examples:

   C: "LIST AUDIO_OUTPUT_DEVICES"
   S: "0,1,3,4,5"

   C: "LIST AUDIO_OUTPUT_DEVICES driver='Alsa'"
   S: "0,1,5"

   C: "LIST AUDIO_OUTPUT_DEVICES driver='Alsa' samplerate='48000'"
   S: "0,5"

   C: "LIST AUDIO_OUTPUT_DEVICES name='Alsa:2'"
   S: "1"

c) Most importantly, the device creation command semantics should be
"slightly" altered. The special case comes when, and only when, the
parameter "name" argument appears on the CREATE...DEVICE command line: if
a device already exists with the same name, driver and type, no new device
is created, being just returned the numerical identifier of the existing
one. Additionally, if further parameters are given, they should override
the existing one's values and immediate device setttings.


>>
>> [...]is already created, and reuse it, instead of taking the cold
>> path i.e. destroy every existing device and create everything yet
>> again as of some LSCP script which holds a master device configuration,
>> which is also my plan A :)
>
> Not sure if I understand that. Why should you destroy them?
>

The main question is: how you'll manage the device configuration space?

This configuration should be almost static during a server instance life
time, so another question arises: should this configuration be owned by
the server? That is, the server is ultimately responsible to maintain,
store and restore, a master device configuration across it's runtime
instances?

Client front-ends may query and change the configuration, but the server
would be the one to store and restore it from the e.g. file system, making
it persistent.

If this is not viable, the other way around is having the front-end(s)
doing this configuration maintenance for themselves and on their own.
Loading or restoring a configuration, which translates to a series of
CREATE...DEVICE commands, should imply that we start with an empty
configuration space, or do you have some other idea in mind? That's why we
should destroy all of them before, then restore the new configuration by
script.

Am I missing something?
-- 
rncbc aka Rui Nuno Capela
rn...@rn...