linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] Dynamic Engine Loader

[Vladimir S. <ha...@so...>]

Christian Schoenebeck wrote:

>Hi and sorry for the late response, I just came back from holidays while 
>Vladimir is still enjoying it it seems.
>
>  
>
No, i'm actually back for a few days now. I'm just keeping quiet for the 
time being :)

Regards,
Vladimir.

Re: [Linuxsampler-devel] Dynamic Engine Loader

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

Es geschah am Sonntag, 8. August 2004 11:30 als Pieter Palmers schrieb:
> Hi all,

Hi and sorry for the late response, I just came back from holidays while 
Vladimir is still enjoying it it seems.

> I've started writing an engine for linuxsampler for more

Great!

> (like multiple loop points). The gig engine is also more instrument
> oriented, while this engine should be more oriented towards the drumloop
> type of sampling. And there is currently no gig format file editor for
> linux that I know of, so...

Right, we discussed adding the possibility to edit or create .gig files, but 
we ended that an own format would be a better idea.

> Anyway, I was wondering if there are plans for supporting the dynamic
> loading of the engines (i.e. like with ladspa plugins). I inserted my
> engine into the linuxsampler code tree, and I have the impression that
> this feature is intended.

Yes, dynamic engine loading is planned of course. This should be done via the 
"LOAD ENGINE" LSCP command:

http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#rfc.section.5.4.2

But at the moment, as we only have one engine yet, we only simply check if the 
engine name is either "gig" or "GigEngine" when the "LOAD ENGINE" command was 
issued (see src/network/lscpserver.cpp line 448 et seqq.).

> I would like to implement a dynamic engine loader, but I was wondering
> if there are already some thoughts on how this should be done.

We already load audio output drivers and MIDI input drivers dynamically (see 
src/network/lscpserver.cpp line 358 / 374 et seqq.). We use factory classes 
for this (src/drivers/audio/AudioOutputDeviceFactory.cpp and 
src/drivers/midi/MidiInputDeviceFactory.cpp) which resolve the given strings 
and create an instance of the desired class. Unfortunately this can't be 
solved as elegant in C++ as it can be in other languages like Java (Java 
reflections API) so we're forced to use preprocessor macros in the driver 
classes, so the driver classes actually register themselves the factory. This 
is definitely one big feature that should be added in a future standard of 
C++ IMO.
Anyway... implementing dynamic loading of engines can be almost identically 
done the same as it's already done for the audio and MIDI drivers. There's 
only one issue: for loading the drivers we also introduced a some how complex 
system of dynamic driver parameters. That way the GUI frontends don't have to 
know which drivers are implemented, what parameters these drivers support or 
need, what these parameters do, etc.
For loading sampler engines I think we could simply drop that dynamic 
parameters approach. Or do you think there will be engines in future which 
could require special parameters for loading the engine?

CU
Christian

[Linuxsampler-devel] Dynamic Engine Loader

[Pieter P. <pi...@jo...>]

Hi all,

I've started writing an engine for linuxsampler for more 
'sampler-oriented' work, a sampler in this sense being a device that 
plays back (recorded) samples. The base for it is (of course) the gig 
engine, but I need some features that aren't provided in the gig format 
(like multiple loop points). The gig engine is also more instrument 
oriented, while this engine should be more oriented towards the drumloop 
type of sampling. And there is currently no gig format file editor for 
linux that I know of, so...

Anyway, I was wondering if there are plans for supporting the dynamic 
loading of the engines (i.e. like with ladspa plugins). I inserted my 
engine into the linuxsampler code tree, and I have the impression that 
this feature is intended.

I would like to implement a dynamic engine loader, but I was wondering 
if there are already some thoughts on how this should be done.

Greets,

Pieter

Re: [Linuxsampler-devel] GUI

[Mark K. <mk...@co...>]

Emiliano . wrote:
> Hi, im Emiliano, from argentina, i am new in linux, but i saw that you 
> need help with the GUI. I am a web designer, if you need anything just 
> let me know.
> 
> (sorry for my inglish)
> 
> Emiliano
> 
>> From Argentina.
> 

Welcome!

Please never be sorry for your English around here! You've already shown 
more ability than I can in any other language.

It would be fun to list the native languages of all the participants. I 
don't know what the list looks like, but I'm pretty sure the 3 main 
developers are German, Italian and Portugese. I have wondered what 
Vladimir's native language was, but only because of his name. (You there 
Vladimir? Senkov is Russian or somethign else?)

Cheers,
Mark

[Linuxsampler-devel] GUI

[Emiliano . <emi...@ho...>]

Hi, im Emiliano, from argentina, i am new in linux, but i saw that you need 
help with the GUI. I am a web designer, if you need anything just let me 
know.

(sorry for my inglish)

Emiliano
From Argentina.

_________________________________________________________________
MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/

[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

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

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

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

[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] liblscp packaging

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

Es geschah am Dienstag, 13. Juli 2004 10:55 als Rui Nuno Capela schrieb:
> > I propose to change the pkg-config library name (in liblscp.pc.in) from
> > 'liblscp' to 'lscp', as it's common to omit the 'lib' prefix and maybe
> > also to rename that file to lscp.pc.in.
>
> That's OK with me, but /only/ on the pkg-config matter. I do like the
> liblscp name, and no, I don't have any objective argument to hold that,
> it's just folklore :)

Ok, then I'll change that.

And of course no, I don't want to change the lib name in general, it's only 
the pkg-config name. :)

> I guess the same applies to libgig, where the pkg-config file
> (libgig.pc.in) should be renamed to gig.pc.in ?

Already done, couple of days ago.

CU
Christian

Re: [Linuxsampler-devel] liblscp packaging

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

Hi Christian,
>
> I added files to create Debian packages for liblscp. The two packages
> ('liblscp' and 'liblscp-dev') can be generated as usual by calling
>
> 	'make -f Makefile.cvs && dpkg-buildpackage -rfakeroot'
>
> in the sources top level directory.
>

Cool. Even though I don't have a clue about debian packaging. Eheh...  but
"fakeroot" sounds funny :)


> I propose to change the pkg-config library name (in liblscp.pc.in) from
> 'liblscp' to 'lscp', as it's common to omit the 'lib' prefix and maybe
> also to rename that file to lscp.pc.in.
>

That's OK with me, but /only/ on the pkg-config matter. I do like the
liblscp name, and no, I don't have any objective argument to hold that,
it's just folklore :)

I guess the same applies to libgig, where the pkg-config file
(libgig.pc.in) should be renamed to gig.pc.in ?

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

[Linuxsampler-devel] liblscp packaging

[Christian S. <chr...@ep...>]

Hi Rui!

I added files to create Debian packages for liblscp. The two packages 
('liblscp' and 'liblscp-dev') can be generated as usual by calling

	'make -f Makefile.cvs && dpkg-buildpackage -rfakeroot'

in the sources top level directory.

I propose to change the pkg-config library name (in liblscp.pc.in) from 
'liblscp' to 'lscp', as it's common to omit the 'lib' prefix and maybe also 
to rename that file to lscp.pc.in.

CU
Christian

Re: [Linuxsampler-devel] [ANNOUNCE] QSampler 0.0.3 released!

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

(Vladimir, I think this thread is of interest to the list,
so I took the freedom on cross-posting it).

From:    "Vladimir Senkov" <ha...@so...>
Date:    Wed, July 7, 2004 13:50

Hi Rui,

>
> Incidentally, this is the time of the year that I get more free time for
> these. However, in August it's my turn to go away :)
>
>
I myself will disappear in about a week. But i'll be back (C) ....

>
>> I've been trying to get the GUI to work with current ls.
>> When i add a channel via the gui, if i just pick the instrument right
>> away and click "OK" (everything else if left default) i get into a
>> state when instument is loading in the background but the GUI doesn't
>> like something and keeps displaying the instrument status as "-1".
>> If i follow a different procedure everything seems to work:
>> 1) Click add channel but instead of picking and instument and clicking
>> OK i click cancel.
>> 2) Then i go back in the channel, pick the engine and the instrument
>> and click OK. Now it loads OK.
>>
>
> Hmm. Something's missing here. The instrument status should be ERR-1
> (in red), isn't it? Did you specify a valid engine, other than "(No
> engine)" ? Remember you can't load an instrument without loading an
> engine in the first place.
>
Well, when the dialog box first opens GigEngine is already there for me.
But . . . when i open it for the second time i DO have to pick it from the
list.

>
>> BTW, do you think "cancel" should create a channel? I've added tracing
>> capability to the server (just open another connection and do SUBSCRIBE
>> MISCELLANEOUS and it will spit out the commands it gets over any
>> connection) and it shows that you execute "ADD CHANNEL" when dialog box
>> is created, not when "OK" is pressed. It's a bit confusing i think . . .
>> usually you have to click OK for something to get created . . . jmho.
>>
>
> I know this seems somewhat unorthodox, but that's true and it's working
> as designed :) When you click to add a new channel, an empty channel
> strip get's created immediately, although not shown until after the
> channel dialog shows up to change and accept the new channel settings.
>
> This was done this way just for simplicity (i.e. lazziness :) :
> the channel dialog needs the channel-id of the channel strip being
> edited, so it must be already known--ADD CHANNEL is where one gets
> this id and the GUI must show that a channel is already there. The
> alternative would have two code paths, one for creating a new channel,
> the other to edit it's settings. I choose the simpler one. An empty
> channel is created, period. Then the user is allowed to setup existing
> channels.
>
I understand the motivation but from enduser perspective it's a bit 
confusing. I think that dialog box will have to change a little bit 
anyway and in fact will probably become two different dialog boxes in  the
future. The reason is . . .  audio channels and midi ports are not  like
devices, you can't know what their parameters are going to be  before you
create them :) Maybe we need to rework the spec there a  little bit i'm
not sure, but this (i think) will be a problem for the  GUI because it
will first have to create audio channels and midi ports  and only after
that will be able to configure them. So you can't really  display things
like port name and alsa binding parameters before you  create the port :(

>
> Current qsampler is still a legacy from the older linuxsampler
> interface, when there wasn't no virtual device management. Remember
> my batle to keep backward compability? There you got it :)
>
> On the contrary, liblscp is already on shape to the latest LSCP
> draft-protocol v.11, including driver, device and event subscription
> and notification. QSampler is still behind on these features, but the
> hooks are in place, so we may consider it a baseline now.
>
> OK. Now's the time to think about how to implement this device
> managament stuff on the QS front-end. I think I have my mind fixed on
> a device vs. channel space separation, so I'll let you all discuss this
> with me.
>
> In this (neo)terminology of mine, what I mean as device space is as
> being the configuration space of audio output and midi input devices.
> The channel space, which on QS is currently mapped on so-called session
> files, covers the description and configuration of a sampler channel set.
>
> Each element on the channel space, a sampler channel, have a reference
> to a couple of entities belonging to the device space: an audio output
> device and a midi input device identifier. OTOH no entity belonging to
> the device space has a pointer into the channel space. That's why my mind
> is somewhat fixed on this separation.
>
> Are you following me? :)
>
I think so. I'd probably say a given sampler channel is linked to a midi 
port and audio channel(s) rather than device but it's the same idea.

>
> OK. We already have the channel space description on QS, that's the
> session. The user may already load and unload this description into
> or from a file, the session file. Sampler channels maybe then be
> created, edited and removed at will. The persistance of a channel
> session configuration is by now already understood.
>
> Now's the hard question, or so to speak. The device space description
> and configuration, which most probably will be maintained in the
> filesystem, must be retained in such a way that it survives a session
> lifespan. As you might imagine, it probably makes no sense to maintain
> a session file without a very well established master device file.
> Note that every channel session file will reference this master device
> configuration, so it seems logical to have this separation.
>
I agree.

>
> This master device configuration file is supposed to be realized
> (loaded) by default and implicitly, whenever a linuxsampler server
> engine is started. Shouldn't it better be on the server side ? That
> is, being a property of the server?
>
I'm thinking that client will have to major features:
1) Configuring performance related stuff (sampler channels, instruments, 
etc)
and
2) Configuring setup related stuff (audio channels and their mixing,  midi
ports and their bindings, maybe other "global" properties such as  engine
parameters, etc)

I think of 1) as loading a "performace" file maybe.
And 2) is perhaps a sampler configuration file.
The first one is definitely more fluid while the second one may remain 
the same forever (depending on what the user is doing).

>
> Surely the QS front-end may emulate this feature, resetting the complete
> device configuration on demand or on very well know occasions (e.g.
> local server startup), from a local stored file, but this will certainly
> clash in a multi-client environment.
>
I think we be able to be multi-client friendly. That's why i wanted to 
have "name" parameters for sampler channels and midi ports. I'd hope  that
"performance" configuration file could reference those names rather  than
device/port/channel IDs.
Then QS could detect if those names exist when performance file is  loaded
and use the exising config or tell the user that he can't load  the
performance before he creates (or loads) the sampler configuration  data
that will create all devices/audio channels/ports that this
particular performance requires. Or maybe user will have an option to 
skip creation of sampler channels that could not be created because  there
is nothing to map them to . . .
I think we need to think that through but i hope it can be done.

>
> So, using QS in practice, the user may setup his/her master device
> configuration, save it to a spacial device description file, and make
> it persistant over the linuxsampler server cycle. Loading a device
> description file, which is a plain LSCP script, implies a complete
> reset of any existing device configuration--all existing device
> instances are destroyed, the new ones created by submitting the LSCP
> device description script file.
>
> Does this sound reasonable? As I said before, I'm asking your opinion
> or leveraging this up to discussion, as I'm probably lacking ideas.
>
I think your thinking is very close to what i've been dreaming. But i'm 
hoping that we can use the names to avoid complete destruction of the 
configuration . . . in other words, we should be able to merge configs.

Another option is to split the functionality into two apps. One will be 
the QS. It will manage performances like it does today. Sampler
channels, instruments, etc. But when it comes to devices and ports it 
will only be able to "pick from the list". In other words, it will not  be
able to make any changes to those lists.
QS will then have a config and only performance (local) data will be 
saved there. In other words, if there is another QS running talking to 
the same LS it will have it's own config for it's sampler channels.

But there will also be another app that will be able to create those 
objects for those lists. That app then will have it's own config and  will
probably be able to save LSCP config for either all objects or only  the
ones created on this instance of the app. In other words, it should  be
able to either save global config or local . . .

Does that sound completely nuts?
Let's brainstorm this at some point and then ask Mark maybe he has  better
ideas.

Regards,
Vladimir.

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Hi Christian,

>
> I felt forced to add support for generating Debian packages as well. ;)
> I commited it couple of minutes ago.
>
> Rui, could you please also put a line into README how to generate the
> RPMs? I just left a TODO there, hoping you will do it. Right after that
> I will roll the tarball and generate the .deb files and upload them
> together with your RPMs.
>

To generate the RPMs you have to be on a RPM based system/distro, or at
least have the rpmbuild tool properly configured. I take my knowledge
because all my boxes have RPM based distros (suse, mdk and fedora). But
things may differ

The steps are simple:

1) Get .spec file generated by ./configure. Edit it as appropriate.

Then, as root:

2) Copy the source tarball to "/usr/src/<rpmdir>/SOURCES" directory.

3) Build the rpm(s) by invoking 'rpmbuild -bb <specfile>' from the command
line.

On success, the resulting rpm(s) can usually be found under the proper
"/usr/src/<rpmdir>/RPMS/<arch>" directory. The recently built package(s)
aren't installed by default.

The names for the sub-directories <rpmdir> and <arch> depends on the
distro or rpm installation. For example, on SUSE we have
<rpmdir>="packages", on Mandrake <rpmdir> is "RPM" and for redhat/fedora
<rpmdir> always equals "redhat".

As you see, I don't feel very sure about writing /so/ specific
instructions, as YMMV.

Feel free to drop yourself a line on the README file. At the moment I
don't have access to make it right, maybe tonight.

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

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

[Christian S. <chr...@ep...>]

Hi!

I felt forced to add support for generating Debian packages as well. ;)
I commited it couple of minutes ago.

Rui, could you please also put a line into README how to generate the RPMs? I 
just left a TODO there, hoping you will do it. Right after that I will roll 
the tarball and generate the .deb files and upload them together with your 
RPMs.

CU
Christian

P.S. in configure.in you can now set the version of the generated shared 
library (.so file). I left it with 0:0:0 for the moment due to the version 
number constraints of libtool which would not allow a version of 0:0:7


Es geschah am Samstag, 3. Juli 2004 01:57 als Rui Nuno Capela schrieb:
> Christian,
>
> > Btw, you could also commit the Borland/Win stuff. Maybe you create a
> > win32 directory or something for the fake headers. Once gigextract's
> > dependency to libaudiofile is replaced by libsndfile, then even
> > gigextract will conveniently be compilable on Windows.
>
> I'll do that when I get back to my workplace, where I do the windoze dance
>
> :) and look closer to a bunch of warnings the compiler spitted out.
>
> As I said it's not a priority.
>
> Cheers.

Re: [Linuxsampler-devel] [ANNOUNCE] QSampler 0.0.3 released!

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

Vladimir,
>
> I'm glad you are alive and kicking! You are the only one i'm getting any
> LS related e-mails from. Everybody else went quiet. Vacation time i guess
> :)
>

Incidentally, this is the time of the year that I get more free time for
these. However, in August it's my turn to go away :)

>
> I've been trying to get the GUI to work with current ls.
> When i add a channel via the gui, if i just pick the instrument right
> away and click "OK" (everything else if left default) i get into a state
> when instument is loading in the background but the GUI doesn't like
> something and keeps displaying the instrument status as "-1".
> If i follow a different procedure everything seems to work:
> 1) Click add channel but instead of picking and instument and clicking
> OK i click cancel.
> 2) Then i go back in the channel, pick the engine and the instrument and
> click OK.
> Now it loads OK.
>

Hmm. Something's missing here. The instrument status should be ERR-1 (in
red), isn't it? Did you specify a valid engine, other than "(No engine)" ?
Remember you can't load an instrument without loading an engine in the
first place.


> BTW, do you think "cancel" should create a channel? I've added tracing
> capability to the server (just open another connection and do SUBSCRIBE
> MISCELLANEOUS and it will spit out the commands it gets over any
> connection) and it shows that you execute "ADD CHANNEL" when dialog box
> is created, not when "OK" is pressed. It's a bit confusing i think . . .
> usually you have to click OK for something to get created . . . jmho.
>

I know this seems somewhat unorthodox, but that's true and it's working as
designed :) When you click to add a new channel, an empty channel strip
get's created immediately, although not shown until after the channel
dialog shows up to change and accept the new channel settings.

This was done this way just for simplicity (i.e. lazziness :) :
  the channel dialog needs the channel-id of the channel strip being
edited, so it must be already known--ADD CHANNEL is where one gets this
id and the GUI must show that a channel is already there. The
alternative would have two code paths, one for creating a new channel,
the other to edit it's settings. I choose the simpler one. An empty
channel is created, period. Then the user is allowed to setup existing
channels.

>
> I've been thinking about adding proper support to GET
> MIDI_INPUT_PORT_PARAMETER INFO command so that it will list possible
> alsa bindings . . . It would be nice if it listed not just the port
> names such as '64:0','72:0', etc but also their alsa names . . . Our
> current spec doesn't allow this though. Any ideas?
>

Current qsampler is still a legacy from the older linuxsampler interface,
when there wasn't no virtual device management. Remember my batle to keep
backward compability? There you got it :)

On the contrary, liblscp is already on shape to the latest LSCP
draft-protocol v.11, including driver, device and event subscription and
notification. QSampler is still behind on these features, but the hooks
are in place, so we may consider it a baseline now.

OK. Now's the time to think about how to implement this device managament
stuff on the QS front-end. I think I have my mind fixed on a device vs.
channel space separation, so I'll let you all discuss this with me.

In this (neo)terminology of mine, what I mean as device space is as being
the configuration space of audio output and midi input devices. The
channel space, which on QS is currently mapped on so-called session files,
covers the description and configuration of a sampler channel set.

Each element on the channel space, a sampler channel, have a reference to
a couple of entities belonging to the device space: an audio output device
and a midi input device identifier. OTOH no entity belonging to the device
space has a pointer into the channel space. That's why my mind is somewhat
fixed on this separation.

Are you following me? :)

OK. We already have the channel space description on QS, that's the
session. The user may already load and unload this description into or
from a file, the session file. Sampler channels maybe then be created,
edited and removed at will. The persistance of a channel session
configuration is by now already understood.

Now's the hard question, or so to speak. The device space description and
configuration, which most probably will be maintained in the filesystem,
must be retained in such a way that it survives a session lifespan. As you
might imagine, it probably makes no sense to maintain a session file
without a very well established master device file. Note that every
channel session file will reference this master device configuration, so
it seems logical to have this separation.

This master device configuration file is supposed to be realized (loaded)
by default and implicitly, whenever a linuxsampler server engine is
started. Shouldn't it better be on the server side ? That is, being a
property of the server?

Surely the QS front-end may emulate this feature, resetting the complete
device configuration on demand or on very well know occasions (e.g. local
server startup), from a local stored file, but this will certainly clash
in a multi-client environment.

So, using QS in practice, the user may setup his/her master device
configuration, save it to a spacial device description file, and make it
persistant over the linuxsampler server cycle. Loading a device
description file, which is a plain LSCP script, implies a complete reset
of any existing device configuration--all existing device instances are
destroyed, the new ones created by submitting the LSCP device description
script file.

Does this sound reasonable? As I said before, I'm asking your opinion or
leveraging this up to discussion, as I'm probably lacking ideas.

Would you comment on this?

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

[Linuxsampler-devel] [ANNOUNCE] QSampler 0.0.3 released!

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

Hi,

I think you'll like to know that Qsampler 0.0.3 has been released, along
with liblscp-0.2.0.

Once again, this third alpha-release serves as a checkpoint to the
corresponding CVS modules on linuxsampler.org. Please find the respective
tarballs and selected RPMs on the following sites:

    http://sourceforge.net/projects/qsampler
    http://qsampler.sourceforge.net
    http://www.rncbc.org/ls

Soon this will be officially featured on the linuxsampler.org downloads
section, as soon as I get organized ;)

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

[Linuxsampler-devel] [qsampler] Lastest CVS commit

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

Hi,

qsampler 0.0.2.98:

* Channel dialog gets sensible engine and driver defaults
  on create time.

* Implied channel reset on successful instrument load.


liblscp 0.1.9.108:

* Milestone on integral implementation of draft-protocol v.11.

* New lscp_get_channel_stream_usage() helper function.


I'll package an alpha-release very soon: qsampler-0.0.3 and liblscp-0.2.0
will be out later today ;)

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

Re: [Linuxsampler-devel] [linuxsampler] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hi Everybody,

Weekend was way too short.
I've checked in some infrastructure changes.
This is basically to address the issues we've discussed previously about 
creating devices with parameters.
I've applied a bit more patterns in a few places . . . created new 
factory that is responsible for creating parameters. Device factory now 
creates parameters first and then creates a device. Once device is up 
and running parameters are attached to it.
Device parameters are now registered (just like drivers) so that device 
driver doesn't need to deal with parameters at all(like supplying 
available parameters, parsing them on device creation, etc). It can just 
read them when it wants to, always assuming that they are there.

So basically stuff like:
CREATE MIDI_INPUT_DEVICE Alsa ports=10
works OK now. (that includes the active/inactive state too).

Generally speaking, a design (especially when patterns are involved) is 
not created in a single step but rather gets massaged in over some time. 
This design is not perfect yet, but i hope it is a step in the right 
direction.
If something doesn't make sense please drop me a line maybe i missed 
something or didn't think of some features that we'll need later.
If you have questions on how something works don't hesitate to write also.
Any feedback will be appreciated. Constructive or not :)

I still haven't had any time to fix the MacOS MIDI stuff. or to do 
testing, or updating the spec.
Hopefully next weekend. Next weekend is the last weekend for me in a 
while . . . after that i'll be travelling for abount a month with little 
or no access to the net :(

Regards,
Vladimir.

Re: [Linuxsampler-devel] [linuxsampler] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hi All,

I've checked some stuff in a few minutes ago.
Changes include: multiple connection support and event subsctiption support.

I left the tokenizer/parser largely intact for now.
LSCPServer remains singlethreaded and i think it will be sufficient for 
what we use it for.
The only issue is that execution of a command could take a long time 
(for example, loading an instrument) but i think we have already 
established that the client will not like that and we will have things 
of that nature done in the background anyway.

As far as events go i've added the infrastructure but i have not made 
all the changes to the code everywhere to actually start sending events 
(yet). I've provided a quick sample on how this could be done by sending 
a MISCELLANEOUS (debugging) event when a new client connection is 
established and when an existing connection is terminated. This is just 
an example for how to use those "guts" and we should be able to add 
actual event sending very easily.
I've spent most of the energy in trying to not block any thread that is 
originating a notification even LSCPServer thread is busy. I've added 
Trylock() support to Mutex class to be able to do that.
If we need to in the future we'll be able to create new event types in 
real time. I've left some hooks for that in case we need to do that.

Please check it out and let me know where the bugs are. I haven't done 
much testing on it yet, but i've got a long weekend ahead so i hope i'll 
do some later (after i make check more stuff in).

My plans for this weekend are:
1) Refactor the factories :) a little bit to avoid issues with 
constructors and parameters (as discussed previously)
2) Look at the audio device/audio channel stuff. (card parameters, 
mixing channels, etc)
3) Maybe look at converting the MacOS MIDI drivers.
4) Testing, playing with the GUI, updating the spec (if there is enough 
time).

Let me know what you think. Plans will be altered depending on feedback 
received.

Regards,
Vladimir.

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Christian,
>>
>
> Btw, you could also commit the Borland/Win stuff. Maybe you create a
> win32 directory or something for the fake headers. Once gigextract's
> dependency to libaudiofile is replaced by libsndfile, then even
> gigextract will conveniently be compilable on Windows.
>

I'll do that when I get back to my workplace, where I do the windoze dance
:) and look closer to a bunch of warnings the compiler spitted out.

As I said it's not a priority.

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

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

[Christian S. <chr...@ep...>]

Es geschah am Freitag, 2. Juli 2004 23:36 als Rui Nuno Capela schrieb:
> >> Is it also OK to remove from CVS all those auto-generated files? I mean
> >> the ones generated after a 'make -f Makefile.cvs' ? I don't see the
> >> point having it on the repository, do you?
> >
> > Yes I do. The advantage is you can compile the library even without
> > having to install the auto tools. That's why they are there.
> >
> > It's like the same with the parser in LS. You can regenerate it if you
> > have lex & yacc installed by doing 'make parser', or just stick with our
> > pregenerated parser source files.
>
> Oops, about too late. Already committed. Damn, it was just minutes ago.
>
> To save the day, I can always do the autocrap-bootstrap myself and check
> in the regenerated files, if it pleases you. Must I?

Np, forget it. I forgot the libtool aspect. You need to have libtool installed 
to create the lib and libtool has a dependency to parts of autotools. so ...

> OTOH, I've already packaged all my stuff, which is available on the usual
> place (http://www.rncbc.org/ls). You might build your (official) tarball
> now :)

Yeah, maybe tomorrow.

Btw, you could also commit the Borland/Win stuff. Maybe you create a win32 
directory or something for the fake headers. Once gigextract's dependency to 
libaudiofile is replaced by libsndfile, then even gigextract will 
conveniently be compilable on Windows.

CU
Christian