linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

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

[Linuxsampler-devel] [qsampler] latest CVS commit

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

qsampler 0.0.1.91:

* A channel context menu is now featured, by right-clicking over
  each sampler channel strip.

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

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] 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!

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

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

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

Re: [Linuxsampler-devel] [qsampler, liblscp] latest CVS commit.

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

Es geschah am Dienstag, 8. Juni 2004 00:09 als Rui Nuno Capela schrieb:
> There's also some linuxsampler back-end issues as follows.
> Although the GET CHANNEL INFO command is now implemented,
> some of the returned field values are not up to par:
>
> * VOLUME: is initially set to zero (0.0), it does not match
>   the value set by SET CHANNEL VOLUME;
>
> * ENGINE_NAME: the "GigEngine" string is being returned here,
>   but the legal engine name known by GET AVAILABLE_ENGINES
>   and LOAD ENGINE commands seems to be just "gig";

Yes, sorry, our mistake, will be fixed. Everything's still a big construction 
site.

>   MIDI_INPUT_CHANNEL: seems to be fixed on 1, no matter the
>   value set by the SET CHANNEL MIDI_INPUT_CHANNEL command;

Many fields in GET CHANNEL INFO just return fix values at the moment, due to 
the ongoing driver / device configuration implementation. Don't worry... will 
work very soon...

CU
Christian

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

[Linuxsampler-devel] [qsampler, liblscp] latest CVS commit.

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

Hi,

Just to note about my latest CVS commit.

--
qsampler 0.0.1.90:

* Commented the SET CHANNEL MIDI_INPUT_PORT command from
  qsamplerMainForm::saveSessionFile(), it has no effect atm.

* Insert an #include <unistd.h> on qsamplerMessages.cpp, between
  a #if !defined(WIN32) clause.

* An initial non zero value should be set for the channel volume.

* The order to load/save and setup channel settings has changed to
  the following sequence:

    SET CHANNEL AUDIO_OUTPUT_TYPE ...
    SET CHANNEL MIDI_INPUT_TYPE ...
    SET CHANNEL MIDI_INPUT_CHANNEL ...
    LOAD ENGINE ...
    LOAD INSTRUMENT ...
    SET CHANNEL VOLUME ...

--
liblscp 0.1.9.99:

* New lscp_socket_herror() wrapper function has been added for
  proper gethostbyname() error messages.

--
There's also some linuxsampler back-end issues as follows.
Although the GET CHANNEL INFO command is now implemented,
some of the returned field values are not up to par:

* VOLUME: is initially set to zero (0.0), it does not match
  the value set by SET CHANNEL VOLUME;

* ENGINE_NAME: the "GigEngine" string is being returned here,
  but the legal engine name known by GET AVAILABLE_ENGINES
  and LOAD ENGINE commands seems to be just "gig";

  MIDI_INPUT_CHANNEL: seems to be fixed on 1, no matter the
  value set by the SET CHANNEL MIDI_INPUT_CHANNEL command;


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

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

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

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] problems with starting linuxsampler and qsampler

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

>
> these messages repeat quickly in qsampler:
>
> 19:53:04.957 Client connecting...
> 19:53:04.992 Server is starting...
> 19:53:04.994 linuxsampler
> 19:53:04.997 Server was started with PID=7291.
> lscp_client_create: gethostbyname: Sukces
> Starting network server...OK
> LinuxSampler initialization completed.
> LSCPServer: Server running.
> 19:53:07.210 Client connecting...
> 19:53:07.239 Could not connect to server as client. Sorry.
> lscp_client_create: gethostbyname: Sukces

Apparently you're trying to connect to a host that does not get properly
resolved:

   lscp_client_create: gethostbyname: Sukces

(Does "Sukces" means "Success" on your language? That seems that
gethostbyname returned a null value, but kept errno value to zero. Weird.
Oops it's not errno but h_errno that should be set. OK, the message is
misleading but the problem is the same.)

Please check the hostname in the view/options dialog, it should be
localhost and the port 8888. If you haven't changed this at all, please
check your /etc/host.conf, /etc/resolv.conf and finally the /etc/hosts
file where the localhost name should be mapped to the canonical 127.0.0.1
address.

Ultimately, you must have your lo interface up and running. Check it with
the /sbin/ifconfig comand. Of course, you must be running in a network
enabled run level (3 or 5) otherwise you'll not get the mandatory tcp/ip
stack up and running.

Please, forgive me if this all seems too much, but they're just hints.

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

Re: [Linuxsampler-devel] problems with starting linuxsampler and qsampler

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

Scrive Piotr Sawicki <pe...@pl...>:


> 
> When I run linuxsampler in the console, I get this:
> [root@localhost root]# linuxsampler
> Starting network server...OK
> LinuxSampler initialization completed.
> LSCPServer: Server running.
> 
> but it does not appear in qjackctl window as midi or audio device, so I 
> guess it is not working properly, or maybe I should give linuxsampler 
> some parameters when starting, but typing linuxsampler -help, or --h 
> does not give any possibilites as in previous versions of linuxsampler, 
> so please help.


LS does not create jackd or midi ports by default so this is normal.
To check if LS is working properly try the following:

start LS and then in a separate shell
do 
telnet localhost 8888

and type the following commands:

ADD CHANNEL
SET CHANNEL AUDIO_OUTPUT_TYPE 0 JACK
SET CHANNEL MIDI_INPUT_TYPE 0 ALSA
LOAD ENGINE gig 0
LOAD INSTRUMENT /your/sample.gig 0 0
SET CHANNEL VOLUME 0 0.8

now a jackd port and a midi port should show up.
connect the LS jack port to your ALSA out and then
send midi notes to the LS MIDI port which should
cause to make LS sound.

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



> 
> Thanks
> Piotr
> 


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

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

[Linuxsampler-devel] problems with starting linuxsampler and qsampler

[Piotr S. <pe...@pl...>]

Hi,
I have installed linuxsampler form source (cvs20040530) and qsampler=
=20
=66rom rpm's. I use fc1. When I run qjackctl and then qsampler,
(qjackctl parameters)
creating alsa driver ... hw:0|hw:0|512|2|44100|0|0|nomon|swmeter|-|32=
bit
control device hw:0
configuring for 44100Hz, period =3D 512 frames, buffer =3D 2 periods
19:44:53.323 Server configuration saved to "/root/.jackdrc"
19:44:53.324 Statistics reset.
19:44:53.332 Client activated.
19:44:53.337 Audio connection change.
19:44:53.346 Audio connection graph change.

these messages repeat quickly in qsampler:

19:53:04.957 Client connecting...
19:53:04.992 Server is starting...
19:53:04.994 linuxsampler
19:53:04.997 Server was started with PID=3D7291.
lscp_client_create: gethostbyname: Sukces
Starting network server...OK
LinuxSampler initialization completed.
LSCPServer: Server running.
19:53:07.210 Client connecting...
19:53:07.239 Could not connect to server as client. Sorry.
lscp_client_create: gethostbyname: Sukces
19:53:21.949 Client connecting...
19:53:21.981 Could not connect to server as client. Sorry.
lscp_client_create: gethostbyname: Sukces
19:53:36.085 Client connecting...
19:53:36.115 Could not connect to server as client. Sorry.
lscp_client_create: gethostbyname: Sukces



When I run linuxsampler in the console, I get this:
[root@localhost root]# linuxsampler
Starting network server...OK
LinuxSampler initialization completed.
LSCPServer: Server running.

but it does not appear in qjackctl window as midi or audio device, so=
 I=20
guess it is not working properly, or maybe I should give linuxsampler=
=20
some parameters when starting, but typing linuxsampler -help, or --h=
=20
does not give any possibilites as in previous versions of linuxsample=
r,=20
so please help.

Thanks
Piotr

--=20
Kopalnia D=BCwi=EAku
Piotr Karol Sawicki email: pe...@pl...
strona domowa: www.piotr.art.pl

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!

[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

[Linuxsampler-devel] QSampler and liblscp CVS import

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

Hi,

This is just about to note that I've already imported qsampler and liblscp
source trees into linuxsampler.org CVS repository, being now official.

From now on I'll try to post here the summary of every commit; the same I
would expect from anyone else, fairly avoiding clashes or duplicate
efforts.

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

Re: [Linuxsampler-devel] QSampler - A LinuxSampler Qt GUI interface

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

Rui,

You're right default can be on the server. it may even be better this 
way (unless GUI has it configured in options gialog that user could save 
. . .)
I think it would be nice if both max and default were set in options 
dialog . . .
I'm trying to finish some preliminary implementation of GET CHANNEL INFO 
asap.
I'm getting some weird linking issues, then i need to do some testing . 
. . should be done shortly.

Regards,
Vladimir.

Rui Nuno Capela wrote:

>Hi Vladimir,
>
>  
>
>>Now that Christian has fixed the volume bug . . . maybe it's a good idea
>>to change the default volume in the GUI to something other than 0? Some
>>folks may get confused and may think that it is not working at all . . .
>>
>>    
>>
>
>That one adds to the missed GET CHANNEL INFO command implementation on the
>server-side. Qsampler channel's initial value should match the initial
>volume multiplier value as seen by the server engine.
>
>Meanwhile, yes, you're right. Qsampler should fix for a default initial
>value, and...
>
>  
>
>>Does 20% sound good? 50%? 100%??? What do you think?
>>    
>>
>
>Could it be 100%. You tell me :) As I said above it would depend on the
>initial channel engine gain coefficient. If it's unity, than GET CHANNEL
>INFO should return VOLUME: 1.0 immediately after channel creation time,
>and qsampler would show 100% by default.
>
>  
>
>>Also, values between 0 and 1 map to 0..100%, but what about values
>>higher than 1? I personally never use them, but maybe some folks do . .
>>. how high should we go there? 150% maybe? There should definitely be a
>>reasonable limit there.
>>    
>>
>
>May it be a global configuration value? That is, the maximum value is set
>on the options dialog, and from that all channel volume sliders would be
>limited to.
>
>  
>
>>GSt as far as i remember sets default to 90 and let's a user go up to
>>100 . . .
>>
>>    
>>
>
>And what's the opinion of the other members of the list? All this seems
>quite trivial to code in qsampler, but better be consensual... ;)
>
>Cheers.
>  
>