Re: [Linuxsampler-devel] Load Progress meter, Was: [ANNOUNCE] QSampler 0.0.1 released!

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

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

> Hi benno
> 
> >
> > I think both event based load progress infos and INSTRUMENT_STATUS are
> > way too messy for this simple purpose of showing a progress meter.
> >
> 
> Sorry to disagree, but the INSTRUMENT_STATUS approach is the least
> intrusive, development wise. It just adds a single variable to the server
> channel instance, just one field to the LSCP channel info response (small
> change in the doc), and the client takes all responsability on what to do
> with it.

Yes your solution is nice because you require only one single TCP connection
between client and server and the commands never stall the connection for
a long time.
We need to keep in mind that there could be multiple instrument loads going on
on the LS server (eg if you have two GUIs that are loading two separate
 instruments or a single GUI loading multiple instruments at time because 
the user uses two HDs for storing the samples do you can decrease load times
by reading from both simultaneously etc).

So a good solution would probably be the following:

in the Instrument class add GetInstumentStatus() (which returns a few infos
mainly progress percentage etc).

When the LSCP server gets a LOAD INSTRUMENT command
it fires up a new thread to handle the loading and immediately returns 
the OK (or ERR in case of file not found etc) to the client.
Meanwhile the background loading thread loads the sample and constantly
updates the progress percentage (a private variable,  passing external
 int *sample_index, etc like proposed in my earlier solution is not
required anymore).

Now when the GUI issues a INSTRUMENT_STATUS this LSCP command will
call the GetInstrumentStatus() associated to the instrument
which will simply return the value of the progress percentage 
(since we use threading all variables are shared thus no additional
message passing etc is required).

everyone happy ?

Seriously, I agree with Rui this solution is the least invasive
and could be VERY beneficial for users dealing with large GIGs
(most GIGs are large :) ).

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






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