Re: [Linuxsampler-devel] [ANNOUNCE] QSampler 0.0.1 released!

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

Christian Schoenebeck wrote:

>
> No audio channel volume will be part of the driver command set, but it
> will of course be added soon. Most probably:
>
> SET AUDIO_OUTPUT_CHANNEL_PARAMETER <device-id> <audio-chan>
> VOLUME=<volume>
>

I think what Mark would really like is if this could be a realtime
parameter. Will it be? :)

I think that would depend on the audio device infrastructure, therefore I
would suggest this realtime property would be a plus, like a new field in
the GET AUDIO_OUTPUT_CHANNEL_PARAMETER INFO command response. Don't really
know if this is the exact purpose of the FIX property, but a REALTIME one
would be handy. Don't you think?


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

>
>> Again, that will be OK when LSCP implementation get's over it. The
>> abstract device driver model which is in the latest draft might come to
>> the rescue.
>
> Yes, device / driver configuration is not yet finished, but I'm working
> hard on it, so very soon...
>

I'm working on it too. liblscp has already all the stubs for this :) it's
just a matter of time now.

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