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.