linuxsampler-devel

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

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

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

[Linuxsampler-devel] Load Instrument patch (was: LSCP event notification notes)

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

Hi,

Myself wrote:
>
>   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 :)
>

Not hard at all ;)

As a proof-of-concept, on attachment to this post, you may find a
diff-patch to the linuxsampler_0_2_0_cvs20040613 tarball on ls.org,
corresponding to the source tree just before the latest CVS revolution.
Maybe it's applicable to current CVS HEAD too, however I didn't tested it
yet myself.

Specifically, this patch makes the LOAD INSTRUMENT command to return
immediately, almost/always with an "OK" response, while spawning the
proper instrument file loading in the background.

The new INSTRUMENT_STATUS item from GET CHANNEL INFO inquiry command is
where one checks for a successfull load. The instrument status value holds
the load progress percentage if positive, currently only "0" and "100" ;)
Otherwise, in case of a load exception error, the instrument status
variable will hold a negative value.

As proposed, the instrument file load is considered successful and
complete when and only when INSTRUMENT_STATUS holds a "100" value.


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

Just hoping this patch gets tested and reviewed, and ultimately found
applicable, I'll start making the document changes in no time.

Hope to hear from you.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] Load Instrument patch (2)

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

Hi,

Second round. In the attachment there's a cleaned up version for LOAD
INSTRUMENT / GET CHANNEL INFO commands diff-patch, which is supposed to be
applicable to current linuxsampler CVS HEAD (patch -p1).

If nothing stands against, I'll may commit it soon, while testing the
latest bleeding-edge server code and updating the LSCP document-draft.

>
> Specifically, this patch makes the LOAD INSTRUMENT command to return
> immediately, almost/always with an "OK" response, while spawning the
> proper instrument file loading in the background.
>
> The new INSTRUMENT_STATUS item from GET CHANNEL INFO inquiry command is
> where one checks for a successfull load. The instrument status value holds
> the load progress percentage if positive, currently only "0" and "100" ;)
> Otherwise, in case of a load exception error, the instrument status
> variable will hold a negative value.
>
> As proposed, the instrument file load is considered successful and
> complete when and only when INSTRUMENT_STATUS holds a "100" value.
>
>>   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.
>>
>
> Just hoping this patch gets tested and reviewed, and ultimately found
> applicable, I'll start making the document changes in no time.
>

BTW, the current CVS HEAD linuxsampler server it's pretty unstable
nowadays, as I find it segfaulting on any ocasion I try to load an
instrument file. These crashes are highly reproducable, whether this patch
is applied or not. So don't start flaming about that :)

Likewise, qsampler is being always brought to the floor, being quite
unusable at this moment with the latest server CVS. Despite server's
crashing quite deterministicaly, these client issues are being taken care
on the liblscp side, so soon this may improve a liltle.

Hope to hear your comments. Is everybody left on exams ? ;)

Take care.
--
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Load Instrument patch (2)

[<be...@ga...>]

Hi,
yeah I tried to apply your patch to the current CVS but hunks got rejected,
I'll try again with this patch.
I did not try it yet but I took a peek at the patch and since you
don't seem to do anything particularily hackish (which could upset
 our dictator, aka cuse) :) I'd say if noone complains within 24h or so
 just go ahead and commit it.

PS: regarding qsampler, liblscp  since I want to keep /usr/local clean
I want to put qsampler and liblscp into my own dirs but the problem is
when compiling qsampler you have to hack the configure script and/or
the .pro file so that it detects the presence of liblscp and then sets 
the paths for -I and -L when compiling.
Would it be possible to add a configure option to qsampler so that
you can specify --liblscp-dir=/tmp/mydir or something like that ?
It's not strictly needed but would make it a bit easier to keep
liblscp/qsampler in different dirs eg, giving the possibility to the user
to keep multiple version and compare them against each other for debugging
purposes etc.

cheers,
Benno
http://www.linuxsampler.org


Scrive Rui Nuno Capela <rn...@rn...>:

> Hi,
> 
> Second round. In the attachment there's a cleaned up version for LOAD
> INSTRUMENT / GET CHANNEL INFO commands diff-patch, which is supposed to be
> applicable to current linuxsampler CVS HEAD (patch -p1).
> 
> If nothing stands against, I'll may commit it soon, while testing the
> latest bleeding-edge server code and updating the LSCP document-draft.
> 
> >
> > Specifically, this patch makes the LOAD INSTRUMENT command to return
> > immediately, almost/always with an "OK" response, while spawning the
> > proper instrument file loading in the background.
> >
> > The new INSTRUMENT_STATUS item from GET CHANNEL INFO inquiry command is
> > where one checks for a successfull load. The instrument status value holds
> > the load progress percentage if positive, currently only "0" and "100" ;)
> > Otherwise, in case of a load exception error, the instrument status
> > variable will hold a negative value.
> >
> > As proposed, the instrument file load is considered successful and
> > complete when and only when INSTRUMENT_STATUS holds a "100" value.
> >
> >>   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.
> >>
> >
> > Just hoping this patch gets tested and reviewed, and ultimately found
> > applicable, I'll start making the document changes in no time.
> >
> 
> BTW, the current CVS HEAD linuxsampler server it's pretty unstable
> nowadays, as I find it segfaulting on any ocasion I try to load an
> instrument file. These crashes are highly reproducable, whether this patch
> is applied or not. So don't start flaming about that :)
> 
> Likewise, qsampler is being always brought to the floor, being quite
> unusable at this moment with the latest server CVS. Despite server's
> crashing quite deterministicaly, these client issues are being taken care
> on the liblscp side, so soon this may improve a liltle.
> 
> Hope to hear your comments. Is everybody left on exams ? ;)
> 
> Take care.
> --
> rncbc aka Rui Nuno Capela
> rn...@rn...
> 




-------------------------------------------------
This mail sent through http://www.gardena.net

Re: [Linuxsampler-devel] Load Instrument patch (2)

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

hi benno,

> yeah I tried to apply your patch to the current CVS but hunks got
> rejected,
> I'll try again with this patch.

The former only applies to previous and nice working linuxsampler
snapshot, as you find on ls.org downloads section. This later applies to
CVS HEAD as of yesterday, at least.

> I did not try it yet but I took a peek at the patch and since you
> don't seem to do anything particularily hackish (which could upset
>  our dictator, aka cuse) :) I'd say if noone complains within 24h or so
>  just go ahead and commit it.

Depending on your notion of what's a hack, the patch introduces a new
class LSCPLoadInstrument, inherited from Thread, which the only purpose is
to spawn Engine::LoadInstrument() in background. No black hat hacker magic
;)

One thing I dislike is that self-delete on LSCPLoadInstrument::Main() last
line, but I think it seems safe for now.


> PS: regarding qsampler, liblscp  since I want to keep /usr/local clean
> I want to put qsampler and liblscp into my own dirs but the problem is
> when compiling qsampler you have to hack the configure script and/or
> the .pro file so that it detects the presence of liblscp and then sets
> the paths for -I and -L when compiling.
> Would it be possible to add a configure option to qsampler so that
> you can specify --liblscp-dir=/tmp/mydir or something like that ?
> It's not strictly needed but would make it a bit easier to keep
> liblscp/qsampler in different dirs eg, giving the possibility to the
> user to keep multiple version and compare them against each other for
> debugging purposes etc.
>

You can use --prefix=/whatever, but for all ABI purposes at hand wouldn't
it suffice to set LD_LIBRARY_PATH to where is that your bleeding edge
liblscp.so? Incidentally this is my preferred method for debugging, YMMV.

Nevertheless, a note has been taken for that --with-liblscp=dir configure
option.

But remember that I'm just a noob and also a complete autofool moron ;)
-- 
rncbc aka Rui Nuno Capela
rn...@rn...