linuxsampler-devel

[Linuxsampler-devel] Current Status

[Christian S. <sch...@so...>]

Hi everybody!

We're making great steps towards the first release. Still a couple things to 
implement, but that won't take that much time from now.

Said that, it's time to introduce a bug tracking system. I saw somebody 
already prepared Mantis, I guess Benno? Should we take that or use another 
BTS? One thing I don't like about Mantis is that it's only web based, there 
is no other interface. Other BTSs provide further interfaces (e.g. via email 
or native GUI). What's your opinion about that?

The most important outstanding items for the first release is to finish the 
network interface. I updated the features site with all LSCP commands and 
their current implementation status:

	http://www.linuxsampler.org/features.html#LSCP

Please update that section if you changed / implemented something, so we can 
better keep track on what's still to do.

Regarding the GIG Engine: I planned to add support for layers and crossfades, 
maybe also implementing the "Bandreject" and "Turbo Lowpass" filters, but 
that's it. Then *only* overall bug squashing is scheduled and we're ready for 
the first release.

This week I won't have that much time, but next week I'll definitely go with 
full throttle. :)

Rui: what about you? Are you missing something (maybe in the network 
interface) for the first release? What's planned from your site regarding the 
GUI?

CU
Christian

Re: [Linuxsampler-devel] Current Status

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

Hi Christian, everybody,

>
> Rui: what about you? Are you missing something (maybe in the network
> interface) for the first release? What's planned from your site
> regarding the GUI?
>

As mentioned in a recent post, in a reply to Vladimir, I'm still thinking
about how to implement the device management stuff on qsampler.

OK, I confess that in these last couple of days my spare time has been
dedicated to my other pet projects, qjackctl and qsynth. I'm planning
having all those in a reasonable state before I go off in holidays, in
about three weeks from now.

Oh, and there's also the other so many things to get in shape ;)

Regarding LS/QS, the standpoint was about front-end configuration of
audio/midi i/o device space.

Vladimir proposed that devices should be commonly named, in alternation to
be numerically identified. That way one could query if a device instance
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 :)

What's for Plan B ?
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Current Status

[Christian S. <sch...@so...>]

Es geschah am Donnerstag, 15. Juli 2004 01:14 als Rui Nuno Capela schrieb:
> Oh, and there's also the other so many things to get in shape ;)

Yep, same accounts to me. :)

> Regarding LS/QS, the standpoint was about front-end configuration of
> audio/midi i/o device space.
>
> 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?

> 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?

CU
Christian

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...

Re: [Linuxsampler-devel] Current Status

[Christian S. <sch...@so...>]

Es geschah am Freitag, 16. Juli 2004 16:50 als Rui Nuno Capela schrieb:
> 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.

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?

> 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"

Sure, we can do that.

> 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.

> 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.

> 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.

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.

CU
Christian

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...

[Linuxsampler-devel] LSCP specs updated (13th draft)

[Christian S. <sch...@so...>]

Hi!

I just added a new chapter (5.6) "Global commands" and added as promised the 
command "RESET" which resets the whole sampler instance. It's already 
implemented in latest CVS version.

CU
Christian