Re: [Linuxsampler-devel] LSCP event notification notes

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

Rui,

I'm sorry, i forgot about this . . . I've added this event to illustrate 
how this *could* be done with events :)
I have nothing against your proposal to load instruments in the 
background and have an extra status field in CHANNEL_INFO.
I'm not sure about the implementation on the server though . . . might 
be a bit more difficult. I'll look into that at some point.
Any other comments?

Regards,
Vladimir.

Rui Nuno Capela wrote:

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