Re: [Linuxsampler-devel] LSCP event notification notes

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

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

  No problem. I'm just insisting to make it official on the draft
protocol specification. I know that's not that immediately obvious to
implement the progress notification/status on the server side, at least
without tweaking on libgig, as Christian once noted.

  Most probably, libgig has to be changed accordingly and the load process
will be spawned as an appropriate thread. A server channel instance
variable will have to be used in anyway to keep channel/instrument status
progress, that gets updated on each loaded chunk.

  I'm sure, for the time being, we can fool things up on the server and,
upon receiving a LOAD INSTRUMENT command, the server will do:

  1) Check for file validity, by checking for it's existence and naively
verify if it's of one of the supported formats (gig, dls or whatever).

  2) If yes, send the "OK" response immediately to the client, and set the
progress status variable to "0" (zero percent). Otherwise an error status
value will be set (e.g. "ERR").

  3) Load the instrument file as it would do normally, as is.

  4) Right after the load completes, just update the status variable with
a succesful "OK", or "ERR" otherwise. Let's face it, the error status may
hold the actual final response to the LOAD INSTRUMENT command, as it was
until now.

  The value stored on this server channel status variable is exactly the
one that will be held on the INSTRUMENT_STATUS field of the GET
CHANNEL_INFO command. Clear?

  Honestly, I think this isn't that hard to do on the server side. The
actual progress threading and probable libgig changes can be just left to
when Christians get back. Until then, everybody will be happier, me and
qsampler :)

  If all this is OK, I can make the changes myself to the draft document.
Yet again, it will bump to v.09. The summary preview of changes are:

  4.4.1 LOAD INSTRUMENT slight semantics change;
  4.4.9 GET CHANNEL INFO response new status field, INSTRUMENT_STATUS;
  6.6 INSTRUMENT_LOADING event type simply vanishes away.


> Any other comments?
>

Oh, just a minor: about CHANNEL_BUFFER_FILL event type (6.4), ermm...
wouldn't it be nicer to just name it BUFFER_FILL ? Note that on all other
event types a sampler channel is always implied, so why include it on the
event name on this one?

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