[Linuxsampler-devel] LSCP event notification notes

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

Hi,

   After reading the latest LSCP document draft (v.08), I would like to
expose my early thoughts about the new event protocol specification,
suggestions for discussion and correction where applicable.

   This event protocol has changed quite radically in this last draft, so
we may consider we're drawing it again from scratch. So there's no
better time than now to start it's discussion, having immediate
implementation in mind, of course.

   Let's get started.


   A client registers or subscribes to event types it whishes to be
notified for. The subscription command is (4.5.1):

   SUBSCRIBE <event-id>

   Where <event-id> is a generic event type identifier, being one of the
following, as proposed on current draft:

   CHANNELS           (6.1 Number of sampler channels changed)
   VOICE_COUNT        (6.2 Number of active voices changed)
   STREAM_COUNT       (6.3 Number of active disk streams)
   BUFFER_FILL        (6.4 Disk stream buffer fill state changed)
   CHANNEL_INFO       (6.5 Channel information changes)
   INSTRUMENT_LOADING (6.6 Instrument loading progress)
   MISCELLANEOUS      (6.7 Miscellaneous and debugging events)

   One thing I'm kind of dislike is the INSTRUMENT_LOADING event. As
I've stated before, my favorite approach is having a specific status field
on the CHANNEL_INFO result set, that indicates the loading status of the
instrument file.

   Remember that I've been suggesting that the LOAD INSTRUMENT comand
would return an immediate OK result iff the file is accessible and of the
correct format and type. The loading process is taken on the
background and would just keep it's progress internally by the server.
That progress state would be just queried by any client via the GET
CHANNEL_INFO command. A new field, e.g. INSTRUMENT_STATUS, shall then be
included for that particular purpose.

   Possible values for this new field would vary from "0" to "100"
percent, and finally "OK", implying whether the sampler channel is
perfectly operational.

   So, no need for klunky LOAD INSTRUMENT with INSTRUMENT_LOADING event
processing. On the server side, the background progress processing would
have to be done anyway, so I hope my proposal looks simpler and surely
does make clients snappy!

   Note that I'm not completely against the INSTRUMENT_LOADING event
existence. I'm only for having it as an option. It's the responsability of
the client to decide what to do, if any better. Then, what I wish to
propose is exactly the following:

   1) Pseudo-asynchronous behaviour of the LOAD INSTRUMENT command, making
it completely independant of the instrument sample file size or
complexity. The channel instrument load process is always run in the
background, and the client *must* not wait blocked for the load
operation to complete. Never.

   2) A new information field on the GET CHANNEL_INFO result set,
INSTRUMENT_STATUS, where the current instrument load progress
percentage and overall operationality of the corresponding sampler channel
can be queried.

   Assuming this is acceptable, I therefore question the existence of the
INSTRUMENT_LOADING event type. If my proposal is found viable, then the
instrument loading progress events may have it's notifications
broadcasted to the subscribers of the CHANNEL_INFO event type. Is that
simple :)

   Bottom line is: a client doesn't have to subscribe to event delivery to
check if the channel load instrument command has completed. Also,
showing a visual progress bar is an option, not a rule. Either way, my
suggestion satisfies both the option and the rule :)

   Think I've made myself any clear.


Comments please?

Nuff said.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...