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

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

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

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.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] QSampler screenshot, website updates etc

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

Hi,
first of all, very nice work Rui, bravo !
I added a screenshot ryanpg sent me on our screenshots page:
http://www.linuxsampler.org/screenshots.html

Plus I made some updates in the features page and added
developers names if someone that contributed to LS is missing please
let me know. 
If you want your email addressed added near the names (and get more
spam :) ) le me know. At time Marek produced a few gifs with the email
address of me,Christian and Steve (to avoid spam) but I don't have
the time to make such gifs so let me know if I should add

I did not try the latest GUI yet so I cannot comment on the glitches
Mark described, anyway I'll try to summarize a few things:
the stream usage bar should show the buffer percentage fill of the 
least filled buffer.
If you play lots of notes it should constantly jump to 0 and then
quickly go up to almost 100% (if no new notes appear).
When notes disappear I guess the stream bar remains on the
last position where at least one stream was active.

as for stream / voice counters, they should almost always show
more or less the same value (eg when you fire up a voice a stream
is created, when a voice disappears the associated stream disappears too).

Just try to play one single note. voice and streams should be 1 and then
when you release the note (after the EG has faded out the note) or after
the note decays naturally (eg in case of non looped sounds) the 
voice/stream count number should go to 0.
If that does not happen then there is a bug in either the LS engine
not exporting the correct value via LSCP or the Qt GUI misinterpreting it.
I will try to debug it in the next days but I guess someone will
fix this sooner :)

Meanwhile I did not sit idle, more benchmarks, ported most of the low level
code including optimized file I/O to win32 so which ease a future LS port on
Windows.

I wrote a benchmark that simulates the stress that a softsampler puts
on the disk subsystem. The code is optimized for both linux and win32
(standard win32 I/O calls (buffered) are slow).
I'm thinking to wrap it in a GUI and release a crossplatform "sampler benchmark"
that would work on Linux, Windows and Mac OS X.
Future LS versions will come with such a benchmark builtin so that
the user can tune the engine to squeeze out the most of his hardware.
But the question is would audio users (in general) like such a benchmark ?
I think it would be handy since it would allow people to get an idea
how many voices/audio tracks one can get out of his box, how big
buffers you need, what's the real world disk seeking performance etc, 
regardless if a Mac, a Linux box or a Windows box.
Ok you could run a softsampler on each box and stress it till it chokes
you box but not all softsamplers are crossplatform and often users
don't want to buy a softsampler only for benchmarking purposes or after
they discovered that their box is not up to the task and they cannot
afford a new one.

Plus the benchmark could be hosted on this site and if it gets widely used
it would give us a bit more visibility :)


Anyway I'm pretty excited too, the GUI will bring fresh wind 
(developers, users, lurkers) to LS :)

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




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

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!

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

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

[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

[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] Sampler quality comparison...

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

be...@ga... wrote:
> I did not interpret your message as a feature request.
> it's just that a decent softsampler should support independent
> sample rates for libraries and audio output and since
> this feature is very easy to implement and does not use additional
> CPU when library sample rate = audio card sample rate 
> so I see no reason not to implement it :)
> I'm still wondering why GSt does not support it.
> 
> Mark a question: if you have a sound card that can do up to 96Khz
> (44,48,88,96).
> Assume you use a 44.1kHz GIG.
> What happens if you want to work with higher sample rates because
> your other audio files are all using this higher sample rate ?
> As you said in the library SR=44kHz, souncard SR=48kHz you experience
> the nasty pitch transpose effect.

I can't say exactly, but one of these days I could setit up and try it. 
Here's the reason:

Pro Tools <===> 002R <<============>> RME HDSP9652 <==>GSt
                  48K    ADAT Cable     96KHz Card
                       Digital sync-->

Since I use an ADAT optical cable between Pro Tools and GSt the only 
options I have are 44.1K and 48K. Since, for digital sync reasons, the 
GSt machine runs as a slave to the Pro Tools clock, all I can work in 
are 44.1K or 48K. ADAT (on the Pro Tools system) won't send 88.2K & 96K.

I'm not sure what GSt would do if I set the system to 96K.
> 
> But if you use 88kHz on the soundcard ?
> Can GSt avoid pitch transpose in that case since it's just twice
> the original sample rate (44.1kHz) ?
> Or does it play all notes at twice of the pitch ?

If the 44.1/48K experiment holds then it will play at twice the pitch. 
My experience is that GSt doesn't know what the sample rate it. It jsut 
receives clocks and plays samples. The fact that the pitch is 2X is my 
problem.

> 
> just curious  :)
> 
> PS: please when replying reply only to the list otherwise the poster
> always gets two messages.
> 
> cheers,
> Benno

Re: [Linuxsampler-devel] Sampler quality comparison...

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

I did not interpret your message as a feature request.
it's just that a decent softsampler should support independent
sample rates for libraries and audio output and since
this feature is very easy to implement and does not use additional
CPU when library sample rate = audio card sample rate 
so I see no reason not to implement it :)
I'm still wondering why GSt does not support it.

Mark a question: if you have a sound card that can do up to 96Khz
(44,48,88,96).
Assume you use a 44.1kHz GIG.
What happens if you want to work with higher sample rates because
your other audio files are all using this higher sample rate ?
As you said in the library SR=44kHz, souncard SR=48kHz you experience
the nasty pitch transpose effect.

But if you use 88kHz on the soundcard ?
Can GSt avoid pitch transpose in that case since it's just twice
the original sample rate (44.1kHz) ?
Or does it play all notes at twice of the pitch ?

just curious  :)

PS: please when replying reply only to the list otherwise the poster
always gets two messages.

cheers,
Benno



Scrive Mark Knecht <mk...@co...>:

> be...@ga... wrote:
> > Hi Mark,
> > A few points on the matter:
> > 
> 
> Benno,
>     I was only relating a story. I was not asking for a feature request 
> or any changes to your development plans.
> 
>     If you guys *want* to support stuff like this then that's cool, but 
> please remember that I did not request it. If it's there eventually I 
> *may* use it, of course.
> 
> Good luck,
> Mark
> 


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

Re: [Linuxsampler-devel] Sampler quality comparison...

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

be...@ga... wrote:
> Hi Mark,
> A few points on the matter:
> 

Benno,
    I was only relating a story. I was not asking for a feature request 
or any changes to your development plans.

    If you guys *want* to support stuff like this then that's cool, but 
please remember that I did not request it. If it's there eventually I 
*may* use it, of course.

Good luck,
Mark

Re: [Linuxsampler-devel] Sampler quality comparison...

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

Hi Mark,
A few points on the matter:

playing samples transposed by 48000/44100 = 1.088
will not cause only a pitch transpose but a shifting
in the formants too (eg pitch up a voice and you hear the mickey mouse 
effect).
So those big sample libraries that are sampled key by key (chromatically)
would technically suffer since the formant frequencies are not
like in the original, so they sound a bit worse.
Its strange that GSt does not support this since it's not so hard to do.

incorporating the feature in LS is quite easy, from a technical point
of view you just do the following.
let's make an example:
library_samplerate = 44100;
soundcard_samplerate = 48000;

when playing a note you do (for example)

root_note_frequency = 440  ( 440Hz note)
the A above middle C

I want to play the sample one octabe higher (+12 semitones),
pitch = +12
we need to calculate the speedup factor. (the position increment per sample).

so you do 
factor=2^(pitch/12) * library_samplerate / soundcard_samplerate;
if the library and soundcard sample rates are the same then the resulting
factor would be 2.0 (playing the sample one octave higher).
if the sample rates differ the factor would be adjusted for the new sample
rate.
And contrary to your belief Mark if you use decent interpolation algorithms
(like cubic and higher order ones) the resulting sound quality would not
suffer since the shape of curves are smoothly interpolated.
If you play high Hz sounds (eg 10Khz and up) of a 44.1kHz sample through
a 96KHz audio card it sounds crisper since the waves are mode of more
sample points.
But keep in mind that doubling the sample rate doubles the CPU load too
since the sampler has to process twice the amount of samples per time unit.

Don't worry LS will provide this feature.

(it does not support that feature yet so and if you play some non 44kHz GIG
files in LS they sound wrong).

PS: the advantage of using the same sample rate for the library and
for the audio out is that you can in some cases skip interpolation 
completely (especially in those chromatically sampled instruments)
which can greatly speed up the sampling routines thus leading to 
much higher polyphony (assuming that the disk can keep up :) )

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




Scrive Mark Knecht <mk...@co...>:

> 
> I agree with the both of you. Resampling is generally not the way to go. 
> I will relate one problem I ran into a while back with GSt where this 
> would have been useful.
> 
> I got a message from a guy in Europe somewhere about wanting to 
> collaborate on a tune. He sent me a Pro Tools session, both MIDI and 
> audio. I didn't notice that the session was at 48K. I do all of mine at 
> 44.1K, which is the sample rate of all GSt libraries that I own. 
> However, since I connect Pro Tools and GSt, which are on different 
> computers, through an ADAT digital sync supplied over optical cables, 
> GSt started running at 48K, the Pro Tools session speed, instead of 
> 44.1K, the sample rate of the libraries. It turns out that this 
> frequency change is almost exactly a whole note high, being just a bit 
> out of tune (try it yourself some time) so I thought he had just made a 
> mistake in his guitar tunings. It wasn't until later that I was using 
> both GSt and my guitars that I discovered the problems.
> 
> It would have been nice, in this specific case, to have a way for GST 
> (now LS) to accept a 48K clock and resample the 44.1K library into that 
> rate to keep the tuning correct. Granted it would never sound as good as 
> if the session had been done at 44.1K, but it would make LS more useful 
> to do this.
> 
> What I ended up doing was taking the MIDI tracks that went to LS and 
> transposing them by a whole step and then creating off-tuning GSt 
> session files to get the thing tuned into the audio from Pro Tools. what 
> a mess! ;-)
> 
> This is not an issue when you use and audio connection as LS will run at 
> 44.1K in stand alone mode.
> 
> - Mark
> 
> 





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

Re: [Linuxsampler-devel] Sampler quality comparison...

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

be...@ga... wrote:
> I agree with Sebastien here, resampling by too big factors causes
> bad shifting of formants even if you use the highest quality 
> resampling method and natural instruments would sound very bad.
> (try to span a piano sample over 2 octaves or so).
> 
> sfz+ uses bandlimited interpolation which is very high quality
> (no aliasing if you upsample high frequency content) but this method
> of interpolation can consume an unlimited amount of CPU as you
> go higher with resampling factors.
> I think cubic interpolation is the best compromise because it is 
> fast and offers good quality when downsampling or upsampling in ranges
> where you don't hit the nyquist frequency. 
> eg a 15KHz sine upsampled by 1 octave (played at speed factor 2) would
> sound good with bandlimited interpolation since it would filter
> the frequencies above 15kHz.
> 15KHz * 2 = 30kHz, apply the samplerate/2 (about 20KHz) filter and
> what you get is silence, which is better than those ghost frequencies
> eg (22 - 15 = 7kHz).
> But as Sebastien said, if you sample each 2-5 semitones you don't run
> into these problems plus you avoid that too much formant shifting causes
> unnatural sound.
> 
> cheers,
> Benno
> http://www.linuxsampler.org

I agree with the both of you. Resampling is generally not the way to go. 
I will relate one problem I ran into a while back with GSt where this 
would have been useful.

I got a message from a guy in Europe somewhere about wanting to 
collaborate on a tune. He sent me a Pro Tools session, both MIDI and 
audio. I didn't notice that the session was at 48K. I do all of mine at 
44.1K, which is the sample rate of all GSt libraries that I own. 
However, since I connect Pro Tools and GSt, which are on different 
computers, through an ADAT digital sync supplied over optical cables, 
GSt started running at 48K, the Pro Tools session speed, instead of 
44.1K, the sample rate of the libraries. It turns out that this 
frequency change is almost exactly a whole note high, being just a bit 
out of tune (try it yourself some time) so I thought he had just made a 
mistake in his guitar tunings. It wasn't until later that I was using 
both GSt and my guitars that I discovered the problems.

It would have been nice, in this specific case, to have a way for GST 
(now LS) to accept a 48K clock and resample the 44.1K library into that 
rate to keep the tuning correct. Granted it would never sound as good as 
if the session had been done at 44.1K, but it would make LS more useful 
to do this.

What I ended up doing was taking the MIDI tracks that went to LS and 
transposing them by a whole step and then creating off-tuning GSt 
session files to get the thing tuned into the audio from Pro Tools. what 
a mess! ;-)

This is not an issue when you use and audio connection as LS will run at 
44.1K in stand alone mode.

- Mark

Re: [Linuxsampler-devel] Sampler quality comparison...

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

I agree with Sebastien here, resampling by too big factors causes
bad shifting of formants even if you use the highest quality 
resampling method and natural instruments would sound very bad.
(try to span a piano sample over 2 octaves or so).

sfz+ uses bandlimited interpolation which is very high quality
(no aliasing if you upsample high frequency content) but this method
of interpolation can consume an unlimited amount of CPU as you
go higher with resampling factors.
I think cubic interpolation is the best compromise because it is 
fast and offers good quality when downsampling or upsampling in ranges
where you don't hit the nyquist frequency. 
eg a 15KHz sine upsampled by 1 octave (played at speed factor 2) would
sound good with bandlimited interpolation since it would filter
the frequencies above 15kHz.
15KHz * 2 = 30kHz, apply the samplerate/2 (about 20KHz) filter and
what you get is silence, which is better than those ghost frequencies
eg (22 - 15 = 7kHz).
But as Sebastien said, if you sample each 2-5 semitones you don't run
into these problems plus you avoid that too much formant shifting causes
unnatural sound.

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



Scrive Sebastien Metrot <me...@me...>:

> Sorry to get out of my hole but i think this study is pretty stupid and 
> ignorant of the actual purpose of a sampler. The purpose of a sampler is 
> to replay samples as close to their sampling frequency as possible in 
> order to acheive a high level of realism. If you want synthesis then 
> this is a whole diferent issue, and then high quality resampling with 
> filtering and multipoint interpolation not only makes sense but is also 
> a must. However in most cases linear interpolation is really good enough 
> for samplers. If you want to use your sampler as a sound creation tools 
> you WILL use the artifacts. Except this case, no sane sound bank 
> designer would use a sample more that 5 halftones from its root key 
> (actually 1 or 2 seems to be the standard).
> 
> Sebastien
> 
> 
> Tobias Erichsen wrote:
> 
> >Hi everyone,
> >
> >just came by the following site, which compares the quality of the
> >resampling-algos in the different samplers.
> >
> >Thought that perhaps this might be interesting...
> >
> >http://www.djlaser.com/public/samplers/
> >
> >Best regards,
> >Tobias
> >
> >
> >
> >  
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 




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

Re: [Linuxsampler-devel] Sampler quality comparison...

[Sebastien M. <me...@me...>]

Sorry to get out of my hole but i think this study is pretty stupid and 
ignorant of the actual purpose of a sampler. The purpose of a sampler is 
to replay samples as close to their sampling frequency as possible in 
order to acheive a high level of realism. If you want synthesis then 
this is a whole diferent issue, and then high quality resampling with 
filtering and multipoint interpolation not only makes sense but is also 
a must. However in most cases linear interpolation is really good enough 
for samplers. If you want to use your sampler as a sound creation tools 
you WILL use the artifacts. Except this case, no sane sound bank 
designer would use a sample more that 5 halftones from its root key 
(actually 1 or 2 seems to be the standard).

Sebastien


Tobias Erichsen wrote:

>Hi everyone,
>
>just came by the following site, which compares the quality of the
>resampling-algos in the different samplers.
>
>Thought that perhaps this might be interesting...
>
>http://www.djlaser.com/public/samplers/
>
>Best regards,
>Tobias
>
>
>
>  
>

[Linuxsampler-devel] Sampler quality comparison...

[Tobias E. <t.e...@gm...>]

Hi everyone,

just came by the following site, which compares the quality of the
resampling-algos in the different samplers.

Thought that perhaps this might be interesting...

http://www.djlaser.com/public/samplers/

Best regards,
Tobias

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

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

Hi,

As you might know, qsampler is my work in progress as a Qt GUI interfac e
for linuxsampler. It's been under slow development but it's already
getting on par with the current LSCP implementation on the server side.

In fact, it's already missing important LSCP commands (e.g. GET CHANNEL
INFO) from the linuxsampler server, as for qsampler frontend getting in
proper sync with the backend.

Meanwhile, qsampler is already functional, essentially speaking. You can
already start the server, create a sampler channel, load an engine and a
gig instrument file, with corresponding MIDI/audio drivers (ALSA or JACK)
and follow the stream and voice usage on screen. You also may save sampler
sessions and reload them. All initially proposed features are in place.

You still have to connect the proper ALSA and/or JACK device ports
externally (e.g. by using qjackctl? ;) that's for you to play and listen
anything

Qsampler needs liblscp, available on the same CVS repository, hosted on SF
(http:/sourceforge.net/projects/qsampler). Instructions for checking out
these were already posted here twice, so you'll probably know the
thrill...

I'll try to package all or some of the stuff as RPMs, for some "major"
distros I have access (SUSE 9.1, FC1 and MDK 10.0). You can find those
under http://www.rncbc.org/ls , as time permits.

OK. All this long to just say that we're now entering feedback season :)

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

Re: [Linuxsampler-devel] LSCP (7th draft)

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

Es geschah am Sonntag, 30. Mai 2004 23:44 als Vladimir Senkov schrieb:
> Christian,
>
> Looks good. Time to start implementing?

Seems there are no more complains or suggestions regarding the protocol, so I 
guess yes, let's get it on!

CU
Christian

Re: [Linuxsampler-devel] LSCP (7th draft)

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

Es geschah am Samstag, 29. Mai 2004 19:31 als Mark Knecht schrieb:
> It would be nice IMO if instead of getting an error message concerning a
> syntax problem if LS would return the command it didn't like. When I write
> a script it's difficult to figure out which command is failing.
>
> Maybe this could be an option we tell it to use:
>
> SET VERBOSE_FEEDBACK

Agreed, applied as "SET ECHO <bool>" (4.5.3) to enable / disable echo mode,=
=20
which causes all commands immediately to be send back to the client:

=A0=A0=A0=A0=A0=A0=A0=A0http://www.linuxsampler.org/api/draft-linuxsampler-=
protocol-07.pdf
=A0=A0=A0=A0=A0=A0=A0=A0http://www.linuxsampler.org/api/draft-linuxsampler-=
protocol-07.sxw

But beside that the syntax error should also return a more meaningful error=
=20
message of course.

CU
Christian

Re: [Linuxsampler-devel] cvs.linuxsampler.org temporarily not available on wednesday (July 2nd)

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

Sorry, should be June 2nd of course, not July 2nd.

CU
Christian

Es geschah am Montag, 31. Mai 2004 19:21 als Christian Schoenebeck schrieb:
> Hi!
>
> On wednesday, cvs.linuxsampler.org will be down from 5:55 UTC and hopefully
> up again til 16:00 UTC. This is due to construction works at the university
> building where the server is placed and the mandatory power off of that
> building during these works.
>
> CU
> Christian
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] cvs.linuxsampler.org temporarily not available on wednesday (July 2nd)

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

Hi!

On wednesday, cvs.linuxsampler.org will be down from 5:55 UTC and hopefully up 
again til 16:00 UTC. This is due to construction works at the university 
building where the server is placed and the mandatory power off of that 
building during these works.

CU
Christian

RE: [Linuxsampler-devel] LSCP (7th draft)

[Mark K. <mar...@ho...>]

It would be nice IMO if instead of getting an error message concerning a 
syntax problem if LS would return the command it didn't like. When I write a 
script it's difficult to figure out which command is failing.

Maybe this could be an option we tell it to use:

SET VERBOSE_FEEDBACK


>From: Christian Schoenebeck <chr...@ep...>
>To: lin...@li...
>Subject: [Linuxsampler-devel] LSCP (7th draft)
>Date: Sat, 29 May 2004 13:24:17 +0200
>
>Hi!
>
>I updated the protocol document (maybe the last time until the first 
>release
>of LS):
>
>	http://www.linuxsampler.org/api/draft-linuxsampler-protocol-06.pdf
>	http://www.linuxsampler.org/api/draft-linuxsampler-protocol-06.sxw
>
>Changes to already implemented commands (IMPORTANT):
>
>	* command "GET CHANNELS" (4.4.3) will soon return a comma separated list 
>of
>	  all created sampler channels instead of a channel count, this allows
>	  discontinuous channel numbers and brings atomicity e.g. when removing a
>	  sampler channel
>
>	* command "SET CHANNEL AUDIO_OUTPUT_TYPE" is now deprecated and will 
>probably
>	  disappear after the new command "SET CHANNEL AUDIO_OUTPUT_DEVICE" 
>(4.4.12)
>	  is implemented
>
>	* command "SET CHANNEL_MIDI_INPUT_TYPE" is now deprecated and will 
>probably
>	  disappear after the new command "SET CHANNEL MIDI_INPUT_DEVICE" (4.4.16)
>	  is implemented
>
>Changes to recent, not yet implemented commands:
>
>	* applied Vladimir's proposal to allow multiple instances of audio drivers
>	  (4.2.4, 4.2.5, 4.2.6, 4.2.7, 4.2.8, 4.2.9, 4.2.10, 4.2.11, 4.3.4, 4.3.5,
>	  4.3.6, 4.3.7, 4.3.8, 4.3.9, 4.3.10, 4.3.11)
>
>	* replaced occurences of "TYPE" which actually means driver by "DRIVER" 
>(e.g.
>	  "GET AVAILABLE_AUDIO_OUTPUT_TYPES" is now "GET
>	  AVAILABLE_AUDIO_OUTPUT_DRIVERS" - 4.2.1, 4.2.2, 4.2.3, 4.2.7, 4.3.1, 
>4.3.2,
>	  4.3.3, 4.4.8)
>
>	* fields RANGE_MIN may also appear without RANGE_MAX and RANGE_MAX may 
>also
>	  appear without RANGE_MIN respectively (4.2.3, 4.3.3)
>
>	* fixed some examples in chapter 4.2 et seqq.
>
>Additions:
>
>	* white lines and lines starting with a '#' character will be ignored, 
>thus
>	  allows to group commands and to place comments
>
>	* added field "TYPE" to parameter info commands to reflect the value type 
>of
>	  the parameter which either is "BOOL", "INT", "FLOAT" or "STRING" (4.2.3,
>	  4.2.10, 4.3.3, 4.3.10)
>
>I know that's really a bunch, but no fear; that's it. At least from my side 
>I
>won't change anything now in the protocol definition before the first 
>release
>of LS.
>
>If you dislike something in the protocol or if there's something unclear, 
>let
>me know! Otherwise we will soon start to implement all commands as 
>described
>in this 7th draft.
>
>CU
>Christian
>
>P.S. If anybody has a good idea how to convert the document to plain text
>format while keeping headers and footers (title, page count, date), etc. 
>let
>me know!
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Linuxsampler-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

[Linuxsampler-devel] Re: List archives

[Juhana S. <ko...@ni...>]

Lack of list archives seems to be a bigger problem: ardour, crystal-core,
etc. Also annoyingly sourceforge does not start the archives from the
first posting as should. It takes always a few days before I subscribe
 to a new list, and then I have already missed the non-archived starting
discussion.

I have all digests which I have received after I subscribed to
linuxsampler. I could check them out, but let me know first of what
you people think about that.

Regards,
Juhana

[Linuxsampler-devel] LSCP (7th draft)

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

Hi!

I updated the protocol document (maybe the last time until the first release 
of LS):

	http://www.linuxsampler.org/api/draft-linuxsampler-protocol-06.pdf
	http://www.linuxsampler.org/api/draft-linuxsampler-protocol-06.sxw

Changes to already implemented commands (IMPORTANT):

	* command "GET CHANNELS" (4.4.3) will soon return a comma separated list of
	  all created sampler channels instead of a channel count, this allows 
	  discontinuous channel numbers and brings atomicity e.g. when removing a
	  sampler channel

	* command "SET CHANNEL AUDIO_OUTPUT_TYPE" is now deprecated and will probably
	  disappear after the new command "SET CHANNEL AUDIO_OUTPUT_DEVICE" (4.4.12)
	  is implemented

	* command "SET CHANNEL_MIDI_INPUT_TYPE" is now deprecated and will probably
	  disappear after the new command "SET CHANNEL MIDI_INPUT_DEVICE" (4.4.16)
	  is implemented

Changes to recent, not yet implemented commands:

	* applied Vladimir's proposal to allow multiple instances of audio drivers
	  (4.2.4, 4.2.5, 4.2.6, 4.2.7, 4.2.8, 4.2.9, 4.2.10, 4.2.11, 4.3.4, 4.3.5,
	  4.3.6, 4.3.7, 4.3.8, 4.3.9, 4.3.10, 4.3.11)

	* replaced occurences of "TYPE" which actually means driver by "DRIVER" (e.g.
	  "GET AVAILABLE_AUDIO_OUTPUT_TYPES" is now "GET
	  AVAILABLE_AUDIO_OUTPUT_DRIVERS" - 4.2.1, 4.2.2, 4.2.3, 4.2.7, 4.3.1, 4.3.2,
	  4.3.3, 4.4.8)

	* fields RANGE_MIN may also appear without RANGE_MAX and RANGE_MAX may also
	  appear without RANGE_MIN respectively (4.2.3, 4.3.3)

	* fixed some examples in chapter 4.2 et seqq.

Additions:

	* white lines and lines starting with a '#' character will be ignored, thus
	  allows to group commands and to place comments

	* added field "TYPE" to parameter info commands to reflect the value type of 
	  the parameter which either is "BOOL", "INT", "FLOAT" or "STRING" (4.2.3,
	  4.2.10, 4.3.3, 4.3.10)

I know that's really a bunch, but no fear; that's it. At least from my side I 
won't change anything now in the protocol definition before the first release 
of LS.

If you dislike something in the protocol or if there's something unclear, let 
me know! Otherwise we will soon start to implement all commands as described 
in this 7th draft.

CU
Christian

P.S. If anybody has a good idea how to convert the document to plain text 
format while keeping headers and footers (title, page count, date), etc. let 
me know!

Re: [Linuxsampler-devel] Bear stepped on my right ear?

[<le...@gr...>]

Le 28 mai 04, =E0 15:28, Christian Schoenebeck a =E9crit :

> Es geschah am Donnerstag, 27. Mai 2004 23:36 als St=E9phane LETZ =
schrieb:
>> On 27 mai 04, at 23:08, be...@ga... wrote:
>>> The offending code (probably due to a cut'n paste error)
>>> is in line 199 of Voice.h
>>>
>>>  pOutputLeft[i++] +=3D this->FilterRight.Apply(&bq_base, &bq_main,
>>> effective_volume * ((((a * pos_fract) + b) * pos_fract + c) *
>>> pos_fract + x0));
>>>
>>> It should be
>>> pOutputRight[i++] +=3D ....
>>>
>>> Stephane spotted this problem and told me about it on IRC, he said
>>> tried a patch that speeds up things a bit
>>> (reading pSrc[0]..pSrc[7] in one rush in variables and then
>>> use these variable for the stereo cubic interpolator.
>>> He said on PPC its faster.
>>>
>>> Perhaps it makes sense to commit it ? Christian ?
>>> (I sent a copy of the diff to Christian).
>>
>> What really speedup is the use of float instead of double (3.0f=20
>> instead
>> of 3.0 and so on..) *if* computing in double is not required of=20
>> course.
>> But this must be tested on X86 before committing.
>
> What do you mean with "if" computing?


Using the 3 instead of explicit 3.0f  cause float to double conversion=20=

everywhere and consume some CPU. If double precision is not required,=20
then using float explicitely is better.



>
> The patch looks ok, except:
>
>              inline void InterpolateOneStep_Mono(sample_t* pSrc, int&=20=

> i,
> [snip]
> -                    float a   =3D (3 * (x0 - x1) - xm1 + x2) / 2;
> -                    float b   =3D 2 * x1 + xm1 - (5 * x0 + x2) / 2;
> -                    float c   =3D (x1 - xm1) / 2;
> +                    float a   =3D (3.0 * (x0 - x1) - xm1 + x2) * =
0.5f;
> +                    float b   =3D 2.0 * x1 + xm1 - (5.0 * x0 + x2) *=20=

> 0.5f;
> +                    float c   =3D (x1 - xm1) * 0.5f;
>
> Intended? Why not:
>
> +                    float a   =3D (3.0f * (x0 - x1) - xm1 + x2) * =
0.5f;
> +                    float b   =3D 2.0f * x1 + xm1 - (5.0f * x0 + x2) =
*=20
> 0.5f;
> +                    float c   =3D (x1 - xm1) * 0.5f;
>

A mistake.. Yes 2.0f  instead of 2.0.


> And the patch works of course for x86 and also fixes the 'only left=20
> channel'
> bug.
>
> CU
> Christian

Stephane

Re: [Linuxsampler-devel] Bear stepped on my right ear?

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

Es geschah am Donnerstag, 27. Mai 2004 23:36 als St=E9phane LETZ schrieb:
> On 27 mai 04, at 23:08, be...@ga... wrote:
> > The offending code (probably due to a cut'n paste error)
> > is in line 199 of Voice.h
> >
> >  pOutputLeft[i++] +=3D this->FilterRight.Apply(&bq_base, &bq_main,
> > effective_volume * ((((a * pos_fract) + b) * pos_fract + c) *
> > pos_fract + x0));
> >
> > It should be
> > pOutputRight[i++] +=3D ....
> >
> > Stephane spotted this problem and told me about it on IRC, he said
> > tried a patch that speeds up things a bit
> > (reading pSrc[0]..pSrc[7] in one rush in variables and then
> > use these variable for the stereo cubic interpolator.
> > He said on PPC its faster.
> >
> > Perhaps it makes sense to commit it ? Christian ?
> > (I sent a copy of the diff to Christian).
>
> What really speedup is the use of float instead of double (3.0f instead
> of 3.0 and so on..) *if* computing in double is not required of course.
> But this must be tested on X86 before committing.

What do you mean with "if" computing?

The patch looks ok, except:

             inline void InterpolateOneStep_Mono(sample_t* pSrc, int& i,
[snip]
=2D                    float a   =3D (3 * (x0 - x1) - xm1 + x2) / 2;
=2D                    float b   =3D 2 * x1 + xm1 - (5 * x0 + x2) / 2;
=2D                    float c   =3D (x1 - xm1) / 2;
+                    float a   =3D (3.0 * (x0 - x1) - xm1 + x2) * 0.5f;
+                    float b   =3D 2.0 * x1 + xm1 - (5.0 * x0 + x2) * 0.5f;
+                    float c   =3D (x1 - xm1) * 0.5f;

Intended? Why not:

+                    float a   =3D (3.0f * (x0 - x1) - xm1 + x2) * 0.5f;
+                    float b   =3D 2.0f * x1 + xm1 - (5.0f * x0 + x2) * 0.5=
f;
+                    float c   =3D (x1 - xm1) * 0.5f;

And the patch works of course for x86 and also fixes the 'only left channel=
'=20
bug.

CU
Christian