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

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

Scrive Rui Nuno Capela <rn...@rn...>:
 
> >> [...] LOAD INSTRUMENT command returning an incremental
> >> status instead of blocking until it's complete [...]
> >>
> >
> > Sure, will be added, but at a later stage. It's not that important at the
> > moment and means a lot of work. And I would prefer to implement it using
> > the event (UDP) mechanism of LSCP then.
> >
> 
> Let me suggest an immediate if not a good-enough solution:
> 
> The linuxsampler server, upon receiving the LOAD INSTRUMENT command
> request, will just check if the file is accessible and if it is of the
> correct and readable type or format. Of course, it already does. But right
> before it starts really loading the file, it will return the OK status
> code to the client. The real load operation would be run in the
> background.
> 
> Meanwhile, the GET CHANNEL INFO command response would include an
> additional field, e.g. INSTRUMENT_STATUS, that would hold the current load
> progress in percentage. And just to hurry up things, the server loader
> might just set this status to 100% when it's done. I think everyone can
> live with an initial 0% and a final 100% as the only values in that field,
> that is for the time being ;)
> 
> This way, it is client's responsability to query for the current status of
> the loading instrument file, and acting as it sees fit (as showing up a
> progress bar?).
> 
> Think this solution is not hard to code in the server and it would solve
> the question.
> 

I think both event based load progress infos and INSTRUMENT_STATUS are way too
messy for this simple purpose of showing a progress meter.
What's wrong with returning the percentage lines after a LOAD INSTRUMENT ?
Christian about your, "lot of work" statement. Are you refering to the 
implementation of events (with UDP etc) or to the part of libgig returning
a serie of percentage points (or sample index being loaded).
If you mean the former then I agree but the latter is quite simple.

Two possible solutions:

1)
add two parameters to the LoadInstrument() function
LoadInstrument(...., int *current_sample, int *num_samples)


When it calls InstrumentResourceManager::Create
it first traverses the region/dimensionregion list and calculates
the total number of samples in the instrument and then places it into
*num_samples
then when the real loading is done just update the *current_sample value

of course the LSCP server will be blocked during the loading so
if we want to be able to send loading percentage progress to the client
we need to temporarily fire up a new thread and then read
current_sample and simply return  (current_sample/num_samples) 
(sleeping eg 500msec between sending new values).
Then when we achieve 100% the thread should exit and the main LSCP
thread can continue and send the OK status to the client.
This approach is really simple since it requires minimal modification
to the gig loader (10-20 lines of code).

2)
The other solution is to modify LoadInstrument and add a function to
ask how many samples the instrument that we want to load contain.
eg
num_samples = InstumentGetNumSamples(...);
and then modify LoadInsturment
so that it must be called for each sample.
so the application would call something like:
for(sample_index = 0 ; sample_index < num_samples ; sample_index++) 
  LoadInstrument(...., sample_index);

But this is way too messy and would require lots of modifications.

Solution 1) is very simple and I have already the percentage progress
output working on the LS console (not via LSCP yet).
Took me only a couple of mins and about 10 lines of code.
I'll try to add the background thread for the LSCP LOAD INSTRUMENT command
and provide a patch in the next days so that you guys can try it out and express
your opinion on my solution.

The problem is simple: large GIG files can take long time to load
up to 30-40secs or so and not having a progress counter is very annoying
for both the user which does not know how long it will take to load and
for the GUI developer not knowing what's going on on the server side.
This is why loading progress should be supported from the beginning.

comments, ideas ?

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







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