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