linuxsampler-devel

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

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

Hi,

Qsampler is a work in progress for a Qt GUI interface for LinuxSampler.
It's been under development, and still is, as there's still plenty to do.

However I would like to announce a very primordial alpha release:

Qsampler 0.0.1 is now made available. You can check it out from the
following places:

    http://qsampler.sourceforge.net
    http://www.rncbc.org/ls

From the later site you can even choose to download and install from RPM,
which are available for some major distros (Mandrake 10.0, SUSE 9.1 and
Fedora core 1). Remember to install the liblscp package as it's required
for qsampler.

Of course you need linuxsampler installed in the first place, but that's
quite obvious ;)

Please note that qsampler is barely functional, and in it's current state
only relies on the current linuxsampler server LSCP implementation and
features.

In fact, it's missing some important LSCP commands (e.g. GET CHANNEL INFO)
for the frontend being in pretty sync status with the server backend. So
don't be alarmed it you don't get it straight first time you try. Please,
do explore and expose just every simple feature or bug it has to give or
take.

For example, even though the volume slider works as expected, while
sending the proper SET CHANNEL VOLUME commands to the backend, you will
not hear any evidence of it. After all, is all still alpha software.

This release is mainly for all those who couldn't cope with Sourceforge's
anonymous CVS access. So rejoice :)

Now, what can you do with qsampler? You can already start the server
automatically, if there's one of course, then create one or more sampler
channels, load the only available sampler engine ;) and any other gig
instrument file, with corresponding MIDI/audio drivers (ALSA or JACK). You
can follow the stream buffer fill and voice usage on screen while you play
 or feed the MIDI input driver. You may also save sampler sessions as LSCP
script files and reload them back later. All initially proposed features
are in place.

Last but not least, you still have to connect the proper ALSA and/or JACK
device ports by yourself, e.g. using qjackctl ;) if you ever want to play
and listen anything at all.

Hope you enjoy as much as I,

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

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

[Mark K. <mk...@co...>]

Rui,
    Very exciting!

Rui Nuno Capela wrote:
<SNIP>
> 
> Of course you need linuxsampler installed in the first place, but that's
> quite obvious ;)

To sync up with you I am now using liblscp, linuxsampler and qsampler 
all from your web site, just to ensure you and I are at the same place. 
(Or could be. I get that you probably have more advanced code than has 
been released.)

<SNIP>
> 
> For example, even though the volume slider works as expected, while
> sending the proper SET CHANNEL VOLUME commands to the backend, you will
> not hear any evidence of it. After all, is all still alpha software.

Cool.
> 
> This release is mainly for all those who couldn't cope with Sourceforge's
> anonymous CVS access. So rejoice :)

:-) I tried CVS ths morning but the blank password wasn't accepted. 
You're tar files are a big, big help.

> 
> Now, what can you do with qsampler? You can already start the server
> automatically, if there's one of course, then create one or more sampler
> channels, load the only available sampler engine ;) and any other gig
> instrument file, with corresponding MIDI/audio drivers (ALSA or JACK). You
> can follow the stream buffer fill and voice usage on screen while you play
>  or feed the MIDI input driver. You may also save sampler sessions as LSCP
> script files and reload them back later. All initially proposed features
> are in place.

OK, it's basically working for me alsthough I've consistently ran into 
what is likely a LS problem, not a QS problem. Using Takashi's vkeybd, 
if I hit notes slowly and carefully, then I get notes correctly from 
QS/LS. However, if I run the mouse up and down over the keyboard I lock 
up QS/LS and sound doesn't stop until I kill the server.

I don't really understang the black bar with the percentage in it, nor 
do I quite understand the green numbered area at the right. The black on 
seems more indicative of stuff happening with samples streaming, and 
possibly the green one is supposed to be notes or something? The number 
on the left keeps growing, thile the one on the right goes with the 
number of keys I hit. I think the left of the two in green should be 
going back to 0 over time, but for me it isn't. This is all a guess.

Save and restore is not working. It's telling me is cannot load some 
setting in the file and then does nothing as far as I can tell.
> 
> Last but not least, you still have to connect the proper ALSA and/or JACK
> device ports by yourself, e.g. using qjackctl ;) if you ever want to play
> and listen anything at all.
> 
> Hope you enjoy as much as I,
> 
> Cheers.

This is a big help. Once the save and restore works a bit better, and 
when this stuck note problem is addressed, this will make LS far easier 
to use.

I'll test things like MIDI channels later. I'll also try to use it with 
Rosegarden and see how that goes.

Exciting!

Thanks!

- Mark

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

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

Mark,
>
> To sync up with you I am now using liblscp, linuxsampler and qsampler
> all from your web site, just to ensure you and I are at the same place.
> (Or could be. I get that you probably have more advanced code than has
> been released.)
>

As of today, nothing is more advanced than the released code :) I will
bring it also to the linuxsampler.org cvs repository later on.

>
> OK, it's basically working for me alsthough I've consistently ran into
> what is likely a LS problem, not a QS problem. Using Takashi's vkeybd,
> if I hit notes slowly and carefully, then I get notes correctly from
> QS/LS. However, if I run the mouse up and down over the keyboard I lock
> up QS/LS and sound doesn't stop until I kill the server.
>

Hmmm. I've been doing that kind of tests too but never got anything stuck
as you're saying. Guess I have to harness that a lil'bit more :)

> I don't really understang the black bar with the percentage in it, nor
> do I quite understand the green numbered area at the right. The black on
> seems more indicative of stuff happening with samples streaming, and
> possibly the green one is supposed to be notes or something? The number
> on the left keeps growing, thile the one on the right goes with the
> number of keys I hit. I think the left of the two in green should be
> going back to 0 over time, but for me it isn't. This is all a guess.
>

The black bar shows the least filled audio stream buffer, in percentage.
On the far right, the green numbers show the current stream count and
current active voice count. If you hover the mouse pointer over those
they'll show you a tip, won't they?

However I do also find that, most of the time, the counter of active
streams (the first green number) always grows, never returning to zero, as
I would expect. That would only happen if I reset the channel. Less
frequently however the stream usage percentage (your black bar) stalls
high around 98%, only releasing to zero or lower percentages either after
a long period o inactivity and some more notes are played or the channel
is reset, of course.

These are things to account with the linuxsampler server backend, if not a
terrible mistake of mine, wither of liblscp or qsampler's.

> Save and restore is not working. It's telling me is cannot load some
> setting in the file and then does nothing as far as I can tell.
>

Yes, there's a serious flaw in this area, and I'll look forward to it.
However you couldn't get far if it were working as advertised anyway,
since this is where the mentioned GET CHANNEL INFO command server
implementaion is most missed.

>
> This is a big help. Once the save and restore works a bit better, and
> when this stuck note problem is addressed, this will make LS far easier
> to use.
>
> I'll test things like MIDI channels later. I'll also try to use it with
> Rosegarden and see how that goes.
>

We're all counting on your precious feedback. Thanks for the report.

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

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

[Vladimir S. <ha...@so...>]

Rui,

Nice!!! I was able to get it up and running in no time.
I've noticed one little issue . . . when i load the instrument for the 
first time it thinks there is a timeout and will not show the instrument 
name on that channel.
If i then create another channel with the same instrument (ls loads it 
instantly since it is already loaded) then the GUI works correctly.
I think timeout may be a bit too low. It takes a while to load some 
instruments on my old pc :)

Regards,
Vladimir.

Rui Nuno Capela wrote:

>Hi,
>
>Qsampler is a work in progress for a Qt GUI interface for LinuxSampler.
>It's been under development, and still is, as there's still plenty to do.
>
>However I would like to announce a very primordial alpha release:
>
>Qsampler 0.0.1 is now made available. You can check it out from the
>following places:
>
>    http://qsampler.sourceforge.net
>    http://www.rncbc.org/ls
>
>From the later site you can even choose to download and install from RPM,
>which are available for some major distros (Mandrake 10.0, SUSE 9.1 and
>Fedora core 1). Remember to install the liblscp package as it's required
>for qsampler.
>
>Of course you need linuxsampler installed in the first place, but that's
>quite obvious ;)
>
>Please note that qsampler is barely functional, and in it's current state
>only relies on the current linuxsampler server LSCP implementation and
>features.
>
>In fact, it's missing some important LSCP commands (e.g. GET CHANNEL INFO)
>for the frontend being in pretty sync status with the server backend. So
>don't be alarmed it you don't get it straight first time you try. Please,
>do explore and expose just every simple feature or bug it has to give or
>take.
>
>For example, even though the volume slider works as expected, while
>sending the proper SET CHANNEL VOLUME commands to the backend, you will
>not hear any evidence of it. After all, is all still alpha software.
>
>This release is mainly for all those who couldn't cope with Sourceforge's
>anonymous CVS access. So rejoice :)
>
>Now, what can you do with qsampler? You can already start the server
>automatically, if there's one of course, then create one or more sampler
>channels, load the only available sampler engine ;) and any other gig
>instrument file, with corresponding MIDI/audio drivers (ALSA or JACK). You
>can follow the stream buffer fill and voice usage on screen while you play
> or feed the MIDI input driver. You may also save sampler sessions as LSCP
>script files and reload them back later. All initially proposed features
>are in place.
>
>Last but not least, you still have to connect the proper ALSA and/or JACK
>device ports by yourself, e.g. using qjackctl ;) if you ever want to play
>and listen anything at all.
>
>Hope you enjoy as much as I,
>
>Cheers.
>  
>

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

[Jesse C. <je...@es...>]

Rui Nuno Capela wrote on Sat, 05-Jun-2004:

 > Qsampler is a work in progress for a Qt GUI interface for LinuxSampler.
 > It's been under development, and still is, as there's still plenty to do.
 > 
 > However I would like to announce a very primordial alpha release:
 > 
 > Qsampler 0.0.1 is now made available. You can check it out from the
 > following places:
 > 
 >     http://qsampler.sourceforge.net
 >     http://www.rncbc.org/ls
 
I needed to #include <unistd.h>  in qsamplerMessages.cpp to get
it compiled on my gentoo gcc-3.2.2 system.  I assume you want
to put that in an #if !defined(WIN32).

Otherwise works great!

jlc

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

[Mark K. <mk...@co...>]

Rui Nuno Capela wrote:
> Hi,
> 
> Qsampler is a work in progress for a Qt GUI interface for LinuxSampler.
> It's been under development, and still is, as there's still plenty to do.
> 

Hi Rui,
    This is just a short report from the build I did yesterday. It was a 
Harry Potter day today with the kid so I'm just getting back to this 
now. (5PM here)

1) One repeatable failure I always get goes like this:

    a) Create QSampler and a single channel. Set that channel up with a 
working gig on MIDI channel 1, in my case a drum gig, and then trigger 
it to make some sound.

    b) Edit that channel in QS and switch the MIDI channel to channel 2. 
Try to trigger it. It doesn't sound.

    c) Switch the channel back to channel 1. It still doesn't work.

 From here I have to kill LS and start over with QS to get audio again.

2) I'm gettting the left channel only on the version of LS on your web 
site. I need to review the archives to find the solution to that. IIRC 
there was a copy/paste problem in the code and solution posted. I'll 
check that afer I send this, but I report it just in case it's specific 
to my system.

3) Some gigs that have always loaded under LS are not loading under 
QSampler. The Bardstown Bosendorfer piano is one. I have not yet checked 
whether they still load under LS or whether this is a QSampler problem 
only. Hopefully I can try that later tonight.

4) There is a failure mode with this version of LS/QS having to do with 
tracking of voices. Sometimes the tools work correctly. The active voice 
count goes up and then dies out slowly back to 0. Other times it just 
keeps climbing. In the case where it keeps climbing then eventually 
LS/QS start failing. In the case where it goes back to 0 they seem to 
keep working just fine.

5) One other (probably) LS problem is that often I will kill LS with a 
Ctrl-C. At that point often I cannot restart LS. I get a message hat it 
cannot bind the server channel. (I think that's the message.) I have to 
wait about 2 minutes for some sort of timeout and then I can restart. 
This does not happen every time I kill LS, but it happens often.

    I have run LS/QS for a couple of hours with Rosegarden. If I don't 
get the failure mode in #4 then things work pretty well, but due to #1 I 
Can only run a single channel in QS.

    Overall this is a big step forward for user types like me and I 
think it will lead to better testing over the next few months.

    Thanks so much for doing this! Very cool!

Cheers,
Mark

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

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

Hi Mark,

>
>     This is just a short report from the build I did yesterday. It was a
> Harry Potter day today with the kid so I'm just getting back to this
> now. (5PM here)
>

:-)

>
> 1) One repeatable failure I always get goes like this:
>
>     a) Create QSampler and a single channel. Set that channel up with a
> working gig on MIDI channel 1, in my case a drum gig, and then trigger
> it to make some sound.
>
>     b) Edit that channel in QS and switch the MIDI channel to channel 2.
> Try to trigger it. It doesn't sound.
>
>     c) Switch the channel back to channel 1. It still doesn't work.
>
>  From here I have to kill LS and start over with QS to get audio again.
>

Same here. But I usualy don't need to kill LS (or restart it if it's
launched whithin QS); in my tests, a channel reset should do the trick.
However I think the MIDI channel switching is currently flawed, as I get
only channel 1 to work at all (or 0 as for omni mode). Think this is a
well known issue of latest LS.

>
> 2) I'm gettting the left channel only on the version of LS on your web
> site. I need to review the archives to find the solution to that. IIRC
> there was a copy/paste problem in the code and solution posted. I'll
> check that afer I send this, but I report it just in case it's specific
> to my system.
>

No, it's just that bug of my linuxsampler build. Please try one of
yesterday's, where the volume slider would also been fixed
(http://www.rncbc.org/ls).

>
> 3) Some gigs that have always loaded under LS are not loading under
> QSampler. The Bardstown Bosendorfer piano is one. I have not yet checked
> whether they still load under LS or whether this is a QSampler problem
> only. Hopefully I can try that later tonight.
>

Sometimes I get a very similar problems when loading some instrument files
too. However I always manage for them to show up correctly only after a
second try (via channel setup dialog). Bear in mind that the file may load
correctly on LS, but QS always fails to get it to a OK response from it,
at least whithin the allowed time.

I suspect this is due to the long time these gigs take to load by
linuxsampler, and the qsampler timeout interval is way too short for it
(500ms is the default, you may try to set it longer). Of course, this
varies with the system where you're running QS and LS (if not the same).

In my limited experience however, this kind of behaviour only tends to
happen the very first time that particular file is loaded. If some time
later, loading the very same files, is almost instantly.

Is it a matter of cache-on-demand from linuxsampler server?

>
> 4) There is a failure mode with this version of LS/QS having to do with
> tracking of voices. Sometimes the tools work correctly. The active voice
> count goes up and then dies out slowly back to 0. Other times it just
> keeps climbing. In the case where it keeps climbing then eventually
> LS/QS start failing. In the case where it goes back to 0 they seem to
> keep working just fine.
>

As mentioned before, the green numbers are for the current stream count /
voice count. I think it's the stream count (the one to left of the slash)
that is always growing. The voice count (the other one, on the right of
the slash) works fairly well, as one would expect at least.

In my ignorance, this seems that the stream count reported by LS is
showing out the total number of stream buffers allocated since the start
of the channel. The count never shrinks. Strangely enough, this isn't
always true. Some other times that I could not determine how or when, both
numbers seems to play very well. Beats me :)

>
> 5) One other (probably) LS problem is that often I will kill LS with a
> Ctrl-C. At that point often I cannot restart LS. I get a message hat it
> cannot bind the server channel. (I think that's the message.) I have to
> wait about 2 minutes for some sort of timeout and then I can restart.
> This does not happen every time I kill LS, but it happens often.
>

I assume you're starting linuxsampler from outside of QS. You probably
know that it can be started locally, under the control of QS. That way LS
server starts automagically when QS starts, and stops accordingly. You can
even restart the server when you please, whithout leaving QS.

IIUC this problem occurs when linuxsampler is killed abruptally and the
listener socket is not being closed nicely and is kept lingering around
for some time, until the kernel decides to shutting it down. Other that LS
crashing for other reason, hitting Ctrl-C on the console where LS was
started is prone for this to happen, at least on my linux boxes. Perhaps a
signal handler is not being correctly trapped on LS?

OTOH the 2 minute timeout might be a kernel/tcp-stack parameter that I
don't remember right now (somewhere accessible under /proc :) but better
yet, one should try to terminate LS with something in the lines of `kill
<pid>` or `killall linuxsampler` instead of just Ctrl-C.

>
>     I have run LS/QS for a couple of hours with Rosegarden. If I don't
> get the failure mode in #4 then things work pretty well, but due to #1 I
> Can only run a single channel in QS.
>

In time, all these issues will be narrowed out. But, bear with me: it will
not happen just by itself; it is after your unvaluable help that will make
it better.


>     Overall this is a big step forward for user types like me and I
> think it will lead to better testing over the next few months.
>
>     Thanks so much for doing this! Very cool!
>

Thaks for your report. Keep on.


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

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

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

Scrive Rui Nuno Capela <rn...@rn...>:
 
> 
> Sometimes I get a very similar problems when loading some instrument files
> too. However I always manage for them to show up correctly only after a
> second try (via channel setup dialog). Bear in mind that the file may load
> correctly on LS, but QS always fails to get it to a OK response from it,
> at least whithin the allowed time.
> 
> I suspect this is due to the long time these gigs take to load by
> linuxsampler, and the qsampler timeout interval is way too short for it
> (500ms is the default, you may try to set it longer). Of course, this
> varies with the system where you're running QS and LS (if not the same).
> 
> In my limited experience however, this kind of behaviour only tends to
> happen the very first time that particular file is loaded. If some time
> later, loading the very same files, is almost instantly.
> 
> Is it a matter of cache-on-demand from linuxsampler server?

it's not cache on demand it's the linux file cache that if you have
enough RAM caches the sections that LS preloads so loading of even
a big GIG file (eg a 1.5GB piano which preloads 100-200MB loads in a couple of
secsthe second time you load it).

Regarding the timeout in QS, I think we need an approache where the
user is informed about the progress of loading since with very big instruments
it can take a while, especially if the disk is not that fast.
The ideal would be if the LSCP command LOAD INSTRUMENT would
not only return OK after the loading is completed but
a sequence of percentage numbers separated by \n
eg 
client: LOAD INSTRUMENT .....
LS:
0
1
2
.....
99
100
OK

That way the client could show a progress bar during loading so the
users always know what's going on. Other softsamplers do that too.
Regarding the server side implementation, since LS knows how many
samples an instrument preloads it's just a matter of
returning a sequence of:

percentage=(100 * sample_index_being_loaded) / total_samples;

in that way QS should timeout only if it does not get new percentage
infos for 10-20 secs. 



> 
> In my ignorance, this seems that the stream count reported by LS is
> showing out the total number of stream buffers allocated since the start
> of the channel. The count never shrinks. Strangely enough, this isn't
> always true. Some other times that I could not determine how or when, both
> numbers seems to play very well. Beats me :)

I did not try it yet so I cannot comment but I think it's a server side
problem.


> 
> IIUC this problem occurs when linuxsampler is killed abruptally and the
> listener socket is not being closed nicely and is kept lingering around
> for some time, until the kernel decides to shutting it down. Other that LS
> crashing for other reason, hitting Ctrl-C on the console where LS was
> started is prone for this to happen, at least on my linux boxes. Perhaps a
> signal handler is not being correctly trapped on LS?
> 
> OTOH the 2 minute timeout might be a kernel/tcp-stack parameter that I
> don't remember right now (somewhere accessible under /proc :) but better
> yet, one should try to terminate LS with something in the lines of `kill
> <pid>` or `killall linuxsampler` instead of just Ctrl-C.

Yes, it's not a problem of LS it's an issue of the TCP/IP stack of Linux
which waits a 1-2min before closing the socket if it was shutdown
uncleanly.
If the signal 15 handler of LS is closing it correctly then
a 
killall lt-linuxsampler 
should do it.

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


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

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

[Mark K. <mk...@co...>]

Rui Nuno Capela wrote:
<SNIP>
Not messing with MIDI for now. Would certainly appreciate someone 
looking at this sooner vs. later, but I can wait.
<SNIP>

>>2) I'm gettting the left channel only on the version of LS on your web
>>site. I need to review the archives to find the solution to that. IIRC
>>there was a copy/paste problem in the code and solution posted. I'll
>>check that afer I send this, but I report it just in case it's specific
>>to my system.
>>
> 
> 
> No, it's just that bug of my linuxsampler build. Please try one of
> yesterday's, where the volume slider would also been fixed
> (http://www.rncbc.org/ls).

All fixed. Much better. Volume slider actually works very nicely in real 
time. I can trigger a note with a long decay and then raise and lower 
volume. Seems to work nicely. (What about a pan control?) ;-)

> 
> 
>>3) Some gigs that have always loaded under LS are not loading under
>>QSampler. The Bardstown Bosendorfer piano is one. I have not yet checked
>>whether they still load under LS or whether this is a QSampler problem
>>only. Hopefully I can try that later tonight.
>>
> 
> 
> Sometimes I get a very similar problems when loading some instrument files
> too. However I always manage for them to show up correctly only after a
> second try (via channel setup dialog). Bear in mind that the file may load
> correctly on LS, but QS always fails to get it to a OK response from it,
> at least whithin the allowed time.
> 
> I suspect this is due to the long time these gigs take to load by
> linuxsampler, and the qsampler timeout interval is way too short for it
> (500ms is the default, you may try to set it longer). Of course, this
> varies with the system where you're running QS and LS (if not the same).
> 
> In my limited experience however, this kind of behaviour only tends to
> happen the very first time that particular file is loaded. If some time
> later, loading the very same files, is almost instantly.

I think Benno is right. It's the large gigs that never load for me. The 
small ones do what you say - sometimes don't load the first time then 
load fine the second time.

> 
> As mentioned before, the green numbers are for the current stream count /
> voice count. I think it's the stream count (the one to left of the slash)
> that is always growing. The voice count (the other one, on the right of
> the slash) works fairly well, as one would expect at least.
> 
> In my ignorance, this seems that the stream count reported by LS is
> showing out the total number of stream buffers allocated since the start
> of the channel. The count never shrinks. Strangely enough, this isn't
> always true. Some other times that I could not determine how or when, both
> numbers seems to play very well. Beats me :)

Actually this version of LS seems a bit better behaved, up to a point. 
The stream/voice counts seem to be doing as we expect. Start at 0 - 
climb - stop hitting notes - slowly back to 0.

What I'm noticing about the count not going back down is when I'm 
hitting some limit in LS. As I get up to about 40 streams & voices I 
start getting audio cutting in and out. Also the audio sounds like it's 
looping. When this starts happening, if I stop hitting notes and wait 
then LS recovers. (S/V count back to 0/0.) However, if I don't stop 
hitting notes then the S/V count keeps climbing, the audio stays messed 
up and if I go far enough LS just gets sort of hung. At that point it 
may recorver, or it may fail. (Fail == S/V count staying high and audio 
not working right.) I've had both happen.

> 
> 
>>5) One other (probably) LS problem is that often I will kill LS with a
>>Ctrl-C. At that point often I cannot restart LS. I get a message hat it
>>cannot bind the server channel. (I think that's the message.) I have to
>>wait about 2 minutes for some sort of timeout and then I can restart.
>>This does not happen every time I kill LS, but it happens often.
>>
> 
> 
> I assume you're starting linuxsampler from outside of QS. You probably
> know that it can be started locally, under the control of QS. That way LS
> server starts automagically when QS starts, and stops accordingly. You can
> even restart the server when you please, whithout leaving QS.

I didn't know I could run LS from within QS. I read it but it didn't 
register. That seems to work pretty nicely actually. All results above 
and below are done that way using the 6/6/04 version from your web site 
this morning. I haven't had the 2-minute timeout doing it this way. 
(yet...)

<SNIP>
> 
> Thaks for your report. Keep on.
> 

OK, so with the current versions things are working a bit better. Volume 
control works great. S/V count is a bit better.

Enhancement request - a command line option to make default channel 
audio connection with Alsa or Jack for this instance of QS.

qsampler -a {alsa:jack}


Problem Report - CPU usage - I'm apparently able to overrun my 3GHz 
machine with just a single note on the mouse. If I continually play a 
single note so that QS says I'm up to 43 voices, then gkrellm is showing 
CPU usage jumps up to 100%. Top shows about 90% of the CPU going to LS 
and 10% to QS. This only takes about 2-3 clicks per second and happens 
in about 15 seconds. I think something is really not right about this. 
There is no disk activity. The note is a cymbal crash which is probably 
100% in RAM.

Why should CPU usage be so high at this point?

The note I'm hitting has about a 7-8 second tail. If I hit a single note 
and watch LS then the S/V count goes to 1 and stays for 7-8 seconds 
before it drops back to 0.

In my mind, when I start hitting lots of the same note the ones I hit at 
t=0 should not be playing after t=9 but it appears to me that they are 
not being released by LS. At 2-3 notes/second I should never be able to 
make the S/V count go higher than 27 on this sample.

I bet when we figure this out LS will work better. (Assuming I'm not 
totally messed up and wrong about how it should operate!)

There was something else I was going to report or ask for but I cannot 
remember it right now.

Thanks,
Mark

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

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

Mark,

>
>>>2) I'm gettting the left channel only on the version of LS
>>>on your web site. [...]
>>
>> Please try one of yesterday's, [...] (http://www.rncbc.org/ls).
>
> All fixed. Much better. Volume slider actually works very nicely in real
> time. I can trigger a note with a long decay and then raise and lower
> volume. Seems to work nicely. (What about a pan control?) ;-)
>

Unfortunately there's no way to have such a pan control by current LSCP
command interface, nor it's in the v.07 protocol draft. Meanwhile, it's
also assuming that sampler channels are stereo, which might not always be
true.

Perhaps in some other way, as audio channel routing becomes effective, it
could include individual volume per audio mix channel. That could be handy
in implemeting a pan control. Suggestion: extending SET CHANNEL
AUDIO_OUTPUT_CHANNEL command with an additional gain/attenuation
coefficient?

>
> I think Benno is right. It's the large gigs that never load for me. The
> small ones do what you say - sometimes don't load the first time then
> load fine the second time.
>

Yeah. Something in the lines of Benno proposition might be the definitive
solution. That is, the LOAD INSTRUMENT command returning an incremental
status instead of blocking until it's complete, which is annoying to say
the least, even if you set the timeout value too high, making the GUI
quite unresponsive while the file is being loaded by the server.

Let's see what comes about this. votes++ on the incremental load protocol :)

>
> OK, so with the current versions things are working a bit better. Volume
> control works great. S/V count is a bit better.
>
> Enhancement request - a command line option to make default channel
> audio connection with Alsa or Jack for this instance of QS.
>
> qsampler -a {alsa:jack}
>

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.

Meanwhile, you can take advantage of qjackctl's active patchbay feature
for just exactly what you want. Let me show you how:

1. Setup a QS/LS session the way you want, the way you play and hear some
notes, of course. That includes the MIDI source program (e.g. vkeybd). By
this time you'll still have to connect all the ALSA and JACK ports
manually, probably using qjackctl's Connections facility.

2. When you have everything working as you like, open up the Patchbay
window from qjackctl. Press the "New" button and answer "Yes" to the
snapshot question.

3. Hopefully, you'll get a model of all current ALSA and JACK connections.
Edit them as you please in such a way that you end only with the
LinuxSampler connections you want.

3. Save to a pachbay definition file (it's plain xml).

4. Activate the patchbay.

5. That's it. From now on, provided you're running qjackctl, the active
patchbay will be kind of persistent. Whenever LinuxSampler's JACK/ALSA
clients shows up, the respective connections get wired up automagically :)

Hope you enjoy it.

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

[Linuxsampler-devel] LS/QS CPU Activity - looking at note counts vs. bpm

[Mark K. <mk...@co...>]

Mark Knecht wrote:
  > Problem Report - CPU usage - I'm apparently able to overrun my 3GHz
> machine with just a single note on the mouse. If I continually play a 
> single note so that QS says I'm up to 43 voices, then gkrellm is showing 
> CPU usage jumps up to 100%. Top shows about 90% of the CPU going to LS 
> and 10% to QS. This only takes about 2-3 clicks per second and happens 
> in about 15 seconds. I think something is really not right about this. 
> There is no disk activity. The note is a cymbal crash which is probably 
> 100% in RAM.
> 
> Why should CPU usage be so high at this point?
> 
> The note I'm hitting has about a 7-8 second tail. If I hit a single note 
> and watch LS then the S/V count goes to 1 and stays for 7-8 seconds 
> before it drops back to 0.
> 
> In my mind, when I start hitting lots of the same note the ones I hit at 
> t=0 should not be playing after t=9 but it appears to me that they are 
> not being released by LS. At 2-3 notes/second I should never be able to 
> make the S/V count go higher than 27 on this sample.
> 
> I bet when we figure this out LS will work better. (Assuming I'm not 
> totally messed up and wrong about how it should operate!)
> 
> There was something else I was going to report or ask for but I cannot 
> remember it right now.
> 
> Thanks,
> Mark
> 

Hi,
    I set up Rosegarden as a test platform to look at LS/QS more 
carefully. This allows me to more accurately control the number of MIDI 
events being sent.

    I think that QS's stream/voice counts are working correctly until we 
hit some problem. Once we hit the problem the readouts all start acting 
strange. Also CPU usage is just way too high for what I'm doing here. 
GSt on a 500MHz P3 wouldn't even break a sweat with this voice count. LS 
is having a very hard time on a 3GHz machine...

1) Made a single measure with 4 quarter notes triggering the ride cymbal 
in this Wizzo drum set gig file. The cymbal has (roughly) a 7 second 
tail. I then set up RG to just loop on this one measure.

2) Set the tempo to different values and logged S/V counts in QS.

NOTE 1:QS/LS is having some problems with the 'least filled stream 
buffer' numbers. The numbers are there and then they go to 0% for a 
while, then come back, and go back to 0% for a while. When they go to 0% 
the S/V count does not update. This happens (for me) before there is 
audio drop out.

NOTE 2: The 'least filled stream buffer' numbers below are visual 
readings only. The real values jump around a bit. These are just my best 
guess.

NOTE 3: With LS/QS not running RG by itself uses about 15% CPU at all 
bpm's shown below. I presume we subtract 15% from each of the readings 
to get the QS/LS CPU usage.

60bpm  - 81% - 7/7   - 25% CPU (10%)
120bpm - 81% - 13/13 - 40% CPU (25%)
180bpm - 79% - 20/20 - 55% CPU (40%)
240bpm - 82% - 27/27 - 72% CPU (57%)
300bpm - 77% - 33/33 - 87% CPU (72%)
320bpm - 76% - 35/35 - 91% CPU (76%)
340bpm - 74% - 38/37 - 96% CPU (81%)

At this point I start getting audio drop outs and afer a few seconds I 
get a message from Rosegarden telling me:

"JACK audio subsystem is losing sample frames"

If I stop RG then, with some luck, LS/QS will go back to 0/0 and work 
correctly, but it I let the audio dropouts happen for a longer time then 
they will not and LS stays messed up until I kill everything and start over.

My system may very well be a bit crippled. I'm on a 2.6.6 Gentoo 
development kernel with no patches. I'm running everything (qjackctl, 
RG, LS and QS) as a normal user, not root. Maybe some changes to that 
would help. I would expect so...

None the less I get superior results today from Win ME on a slower 
computer. Not totally unexpected due to its maturity, but I'd certainly 
hope for better numbers from LS one day soon.

Thanks,
Mark

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

[Christian S. <chr...@ep...>]

Es geschah am Montag, 7. Juni 2004 18:23 als Rui Nuno Capela schrieb:
> Perhaps in some other way, as audio channel routing becomes effective, it
> could include individual volume per audio mix channel. That could be handy
> in implemeting a pan control. Suggestion: extending SET CHANNEL
> AUDIO_OUTPUT_CHANNEL command with an additional gain/attenuation
> coefficient?

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>

> Yeah. Something in the lines of Benno proposition might be the definitive
> solution. That is, the LOAD INSTRUMENT command returning an incremental
> status instead of blocking until it's complete, which is annoying to say
> the least, even if you set the timeout value too high, making the GUI
> quite unresponsive while the file is being loaded by the server.
>
> Let's see what comes about this. votes++ on the incremental load protocol
> :)

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.

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

CU
Christian

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

[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

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

[Rui N. C. <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.

IMO Qsampler would be happier to call GET CHANNEL INFO more than once,
which it already does, instead of a specific LOAD INSTRUMENT loop.

But who am I to disagree :)

On the server side, I think your current solution is perfectly compatible
with mine.

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

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

[Christian S. <chr...@ep...>]

Es geschah am Dienstag, 8. Juni 2004 12:16 als be...@ga... schrieb:
> 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).

libgig has to be bored up, that's the problem. So guys let's do the important 
things first and a progress bar just for loading an instrument means more 
work than it actually helps. That time is better invested in other things at 
the moment, sorry.

CU
Christian

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

[Mark K. <mk...@co...>]

Rui Nuno Capela wrote:
> 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? :)
> 

Well, no, actually I winked. It's sort of unlikely that I'll actually 
use either the volume or the pan. I drive GSt audio into Pro Tools and I 
do volume and panning automation there.

I do think that someone doing a little bit of music in Rosegarden might 
want to set up a stereo space though, and to that extent panning would 
be nice in LS since audio handling in RG is not that strong yet. 
However, I'd guess someone using Ardour would likely pan within that tool.

Please note, however, that most GSt instruments are sort of weird in 
their use of stereo. For pianos the sound space is generally like your 
sitting at the piano bench. You hear low notes on the left, high notes 
on the right. This is fine if you're just using GSt as a replacement for 
playing the piano, but it's not what a piano sounds like in a mix. 
Generally I have to take the stereo output of GSt and minimize ot to 
almost a mono signal (in terms of left-right) so that I can place it 
properly in a mix.

Hope this helps,
Mark

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

[Christian S. <chr...@ep...>]

Es geschah am Dienstag, 8. Juni 2004 10:07 als Rui Nuno Capela schrieb:
> > 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? :)

Wait a second; LSCP is NOT meant for realtime operation. It's main purpose is 
to setup the sampler session, although it also provides settings like volume, 
etc. But realtime control will be part of the DMIDI Midi Input Device 
implementation.

CU
Christian

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

[Mark K. <mk...@co...>]

Christian Schoenebeck wrote:
> Es geschah am Dienstag, 8. Juni 2004 10:07 als Rui Nuno Capela schrieb:
> 
>>>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? :)
> 
> 
> Wait a second; LSCP is NOT meant for realtime operation. It's main purpose is 
> to setup the sampler session, although it also provides settings like volume, 
> etc. But realtime control will be part of the DMIDI Midi Input Device 
> implementation.
> 
> CU
> Christian
> 
Which is how it's done on GSt, correct? All control - volume, panning, 
etc., is over MIDI in my environment.

I didnt catch that distinction earlier.

However, this does raise some strangeness about the use of QS long term. 
Should my MIDI be going to LS directly, or should it be going to QS 
which is the app I actually run? In the QS model I really don't (and 
shouldn't) know anything about LS really. However, today I talk to the 
underlying LS instance in QJackCtl.

Sort of a strange model.

How would this work if QS was a Windows VSTi? The user would want to 
send MIDI to QS on the Windows box, and then QS would have to get it 
sent to LS on the Linux box somehow?

Or would QS reference the LS instance so that MIDI went directly to it? 
That would be better for latency, etc.

Sort of confusing...

- Mark

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

[Vladimir S. <ha...@so...>]

Mark,

IMHO Midi will not go to QS. Midi will go to LS. QS is a GUI that 
controls LS by speaking LSCP to it :)
When it comes to VSTi it will go to LS also . . .

Regards,
Vladimir.

Mark Knecht wrote:

> Christian Schoenebeck wrote:
>
>> Es geschah am Dienstag, 8. Juni 2004 10:07 als Rui Nuno Capela schrieb:
>>
>>>> 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? :)
>>
>>
>>
>> Wait a second; LSCP is NOT meant for realtime operation. It's main 
>> purpose is to setup the sampler session, although it also provides 
>> settings like volume, etc. But realtime control will be part of the 
>> DMIDI Midi Input Device implementation.
>>
>> CU
>> Christian
>>
> Which is how it's done on GSt, correct? All control - volume, panning, 
> etc., is over MIDI in my environment.
>
> I didnt catch that distinction earlier.
>
> However, this does raise some strangeness about the use of QS long 
> term. Should my MIDI be going to LS directly, or should it be going to 
> QS which is the app I actually run? In the QS model I really don't 
> (and shouldn't) know anything about LS really. However, today I talk 
> to the underlying LS instance in QJackCtl.
>
> Sort of a strange model.
>
> How would this work if QS was a Windows VSTi? The user would want to 
> send MIDI to QS on the Windows box, and then QS would have to get it 
> sent to LS on the Linux box somehow?
>
> Or would QS reference the LS instance so that MIDI went directly to 
> it? That would be better for latency, etc.
>
> Sort of confusing...
>
> - Mark
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

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

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

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

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

Yeah, this is exactly what I've suggested, the only bit is that
INSTRUMENT_STATUS would be a response field of the GET CHANNEL INFO
command, not a command of it's own.

>
> everyone happy ?
>

I'm happy :-)

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

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

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

Scrive Christian Schoenebeck <chr...@ep...>:

> Es geschah am Dienstag, 8. Juni 2004 12:16 als be...@ga... schrieb:
> > 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).
> 
> libgig has to be bored up, that's the problem. So guys let's do the important
> 
> things first and a progress bar just for loading an instrument means more 
> work than it actually helps. That time is better invested in other things at
> 
> the moment, sorry.

Ok no problem then, lets postpone this stuff.
But then please Rui please increase the default timeout in QS to
60 secs or so because loading these PMI pianos on slow boxes could take
really long.

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





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

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

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

benno wrote:
>
> Ok no problem then, lets postpone this stuff.
> But then please Rui please increase the default timeout in QS to
> 60 secs or so because loading these PMI pianos on slow boxes could take
> really long.
>

It's your option. On qsampler menu, go to View/Options.../Server and set
up the timeout value as you wish. But, wait a moment... it has an upper
limit of 5 secs :(

Meanwhile, you can hack a bigger maxValue property in
qsamplerOptionsForm.ui file, line 445. Try to increase to 60000
(millisecs).

I will fix that soon...

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