Re: [Linuxsampler-devel] Current Status

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

Christian,
>>
>> 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.
>
> Agreed. But in general; do you think the device names should be unique
> too? I mean the device number is already a unique identifier, so do you
> see a reason that the device name should also be unique? If the default
> name is applied then of course the name will be unique (driver:nr), but
> it the user provides the name when he creates the device:
> CREATE ... name="something" ?
> Me opinion is it does not have to be unique, what about you?
>

Yes, its part of my plan to have unique device names. Better yet, it's
quite fundamental being unique for each driver (Alsa, Jack, etc.) and type
(audio_output, midi_input).


>> 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.
>
> Not sure if I like that idea. If you use the "CREATE" commands your
> intention should really be to create something. If you just want to
> alter settings then you should use the "SET" commands.
>

Remember that the special case is when we're asking to create a device
with the same name as an already existing one. My proposal seems to make
sense, at least to me. The alternative would be just reject the create
command, taking in effect the uniqueness of the device name.


>> 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.
>
> At this point I don't think the configuration should be stored on server
> side. Maybe at a later stage. Especially because I'm considering the
> Knoppix LS scenario, where you can randomly grep machine(s), boot them
> with a LS Knoppix CD and configure those dedicated samplers via _one_
> laptop or something.
> So you don't have to deal with config files on each machine.
>

I'm really a bit more focused on a studio setup, where things shouldn't
just vanish when the power is off. Configuration files, which maps to the
real physical devices, should be always considered persistent for each
machine or studio setup. I know that knoppix CDs are great media for demos
and will take a fundamental role on linuxsampler PR, but I hope you're not
assuming that will be the only way to deploy it, are you?


>> 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?
>
> That's of course up to the frontend. You can either delete everything
> and start from point zero or you can compare current (running)
> configuration with your desired configuration and just alter things
> that differ from your desired configuration.
>

That comparison is somewhat delegated on the server side, as of my
proposal above, on the CREATE...DEVICE command. If a device configuration
is about to be stored as a LSCP script, I'd rather have only one parser
and it being centralized on the server side. If those comparisons are to
be also taken by the client front-end, then the client surely needs to
parse the configuration script before submitting it to the server. That
adds just more noise, complexity and error source to the subject.

I would like to keep things simple, not simpler (a la Einstein :)

> For the first, crude solution, we can also introduce the command
> "RESET SAMPLER" if you like. Maybe that would be best for the GUI at
> the moment, because it's easy to implement, not so error-prone and
> just works.
>

Yes, that's surely fine. My vote on that. However it doesn't solve the
general problem of having several clients, with diverse but proper device
configurations. Having unique device names with the create-override
feature would help, but it's just my personal solution, probably not the
best one nor optimal.

Cheers,
-- 
rncbc aka Rui Nuno Capela
rn...@rn...