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

Re: [Linuxsampler-devel] compiling nki.c with zlib 1.2.5

[Frank N. <bea...@we...>]

Hi Nick,

> what am i doing wrong?
> 
> cc -c nki.c
> 
> chmod +x nki.o
> 
> ./nki.o
> 
> gives:
> bash: ./nki.o: cannot execute binary file

You are telling the compiler to just build an object file from a source
file ("-c"), but that does not build (link) the final executable.

Instead, try

gcc nki.c -o nki -lz

"Works for me."

Hope that helps,
Frank

[Linuxsampler-devel] compiling nki.c with zlib 1.2.5

[Nick H. <nic...@gm...>]

what am i doing wrong?

cc -c nki.c

chmod +x nki.o

./nki.o

gives:
bash: ./nki.o: cannot execute binary file

-- 
Check out my music and let me know if you like any of it:
https://soundcloud.com/nickleus

Re: [Linuxsampler-devel] Possible Bug report - LinuxSampler Windows, latest weekly build

[Kevin U. <kv...@fr...>]

> 
> You know, I believe I've been having a similar problem likethis for quite a few versions now! I'm sorry I haven't contributed any bug reports, but it doesn't happen consistantly enough to reproduce dependably, and I've always been buisy with musical projects at the time, and never took the time I should have. On both WinXP and Win7 for quite awhile, when using big config files with around 32 or so channels, if something goes wrong, I've always been better off to kill everything and start over. Running the .LSCP file again would often cause a lock-up, or at least generate errors about devices that couldn't be created. I must try a new update and see if this takes care of my difficulties also. Thanks all for so much good work on such a great project.

Kevin
>  

Re: [Linuxsampler-devel] Possible Bug report - LinuxSampler Windows, latest weekly build

[Andreas P. <and...@br...>]

On 2013-05-06 19:00, Graham Goode wrote:
> 5. Some kind of crash occurs immediately after all the
>     "Freeing..." messages have displayed (likely as a result
>     of the RESET command).  Something in what happens AFTER
>     the RESET seems to cause the crash...but no indicative
>     messages appear in either the back-end or the "client".

I couldn't reproduce exactly the same behaviour, but I did find a bug in
the LS MME midi driver. When you delete the LS driver (as is done by the
RESET command for example), the midi connection wasn't closed properly.

Please test if the problem is gone with the latest version
(linuxsampler_20130509_setup.exe).

/Andreas

Re: [Linuxsampler-devel] Possible Bug report - LinuxSampler Windows, latest weekly build

[Andreas P. <and...@br...>]

On 2013-05-06 19:00, Graham Goode wrote:
> I recently released a jOrgan - LinuxSampler Theatre Pipe Organ sample
> set to some Alpha testers, and we have an issue with LinuxSampler
> standalone crashing.
> 
> Lynn Walls describes it as follows:
> 
> I conducted some more experiments on this problem. The sequence is as follows:
> 1. Start linuxsampler back-end.
> 2. Start "client" and run the Barton ASIO4ALL .lscp script

Can you send me this script?

/Andreas

[Linuxsampler-devel] Possible Bug report - LinuxSampler Windows, latest weekly build

[Graham G. <ggo...@gm...>]

I recently released a jOrgan - LinuxSampler Theatre Pipe Organ sample
set to some Alpha testers, and we have an issue with LinuxSampler
standalone crashing.

Lynn Walls describes it as follows:

I conducted some more experiments on this problem. The sequence is as follows:
1. Start linuxsampler back-end.
2. Start "client" and run the Barton ASIO4ALL .lscp script
3. Shutdown "client".
4. Re-launch "client" and run the script again on the same
    running instance of the linuxsampler back-end.
5. Some kind of crash occurs immediately after all the
    "Freeing..." messages have displayed (likely as a result
    of the RESET command).  Something in what happens AFTER
    the RESET seems to cause the crash...but no indicative
    messages appear in either the back-end or the "client".

Here are the test results specific to each "client":

   "Client"   Test Results
-----------  ---------------------------------------------------
jOrgan       back-end crashes and/or jOrgan crashes and system
              hangs; System must be re-booted after physical
              power-off.

QSampler     QSampler crashes, but back-end may be terminated
              with Ctrl-C, and system continues to run normally
              (does not hang/freeze).

JSampler     System hangs/freezes...no messages or dialog boxes;
              system must be re-booted after physical power-off.

The freeze/hang of the whole computer bothers me in terms of whether
or not this is a
wholly a linuxsampler problem or a combination of linuxsampler and a
MIDI open/close
problem.  I have seen other situations where a catastrophic crash or
hang of a program
that has opened one or more MIDI devices with hang/freeze the whole
system.  Sometimes the system instance can be saved, using taskmanager
to kill the offending apps, and sometimes nothing but a re-boot works.

-----------------------------

Is there a log file that we could load to see what is happening? Or
something else that would help find out what is happening?

Kind regards,
GrahamG

Re: [Linuxsampler-devel] SFZ Library

[Graham G. <ggo...@gm...>]

There is an opensource looping application available on Sourceforge -
perhaps you could use that or see how Lars Palo does crossfades in his
code?

See: https://sourceforge.net/projects/loopauditioneer/

Kind regards,
GrahamG

On 4/17/13, fede <for...@gm...> wrote:
> Hi all! I'm new in this mailing list and I'm italian, so sorry for my
> english.
> I'm developing a sfz library based on samples from London Philarmonia (I
> think that they are the best free sample library available in this
> moment). I aim to create a script that mixes samples and creates sfz
> file, so that we can distribute it indipendently by the license of
> London Philarmonia.
>
> I have writed a little c program to help me to find loop points for  the
> samples. To test it I would need to insert the crossfade function. So I
> would ask you where are the lines of code in the LinuxSampler source
> tarball in which this function is defined.
> Also, I would use flac format. Where is the code to decompress flac
> files? (I would be totally sure that I'm using the same data of
> linuxsampler).
>

[Linuxsampler-devel] SFZ Library

[fede <for...@gm...>]

Hi all! I'm new in this mailing list and I'm italian, so sorry for my 
english.
I'm developing a sfz library based on samples from London Philarmonia (I 
think that they are the best free sample library available in this 
moment). I aim to create a script that mixes samples and creates sfz 
file, so that we can distribute it indipendently by the license of 
London Philarmonia.

I have writed a little c program to help me to find loop points for  the 
samples. To test it I would need to insert the crossfade function. So I 
would ask you where are the lines of code in the LinuxSampler source 
tarball in which this function is defined.
Also, I would use flac format. Where is the code to decompress flac 
files? (I would be totally sure that I'm using the same data of 
linuxsampler).

Re: [Linuxsampler-devel] sf2 instrument index

[Kaspar B. <kas...@gm...>]

Just to make this a bit clearer:

LS reads:

   - 0   - "Gunshot"
   - 125 - "Yamaha Grand Piano"


FS reads

   - 0,0   - "Yamaha Grand Piano"
   - 0,127 - "Gunshot"

[Linuxsampler-devel] sf2 instrument index

[Kaspar B. <kas...@gm...>]

Hi,

I am having some trouble relating the instrument index that LS uses to the
one that FluidSynth (FS) displays.

For instance, for the FluidR3GM.SF2 that comes with FS, FS reads bank 0,
program 0 as being "Yamaha Grand Piano" and bank 0, program 127 being
"Gunshot". LS reads FluidR3GM.SF2 as having "Gunshot" as instrument index 0
and 125 being "Yamaha Grand Piano". What logic is LS using to determine
these indexes?

Regards,

Kaspar

Re: [Linuxsampler-devel] message

[Ban Jo <nas...@ya...>]

http://www.chantalmione-therapieholistique.com/reger/li/my 






,   

 


___

















       

[Linuxsampler-devel] Multi-tonal sampling ?

[Håken H. <krb...@on...>]

I have a idea, is it possible to include a function that i call
"multi-tonal sampling"(or a better word).
I dont know if this feature already exists..

The function works as this:
You have a wav file with a instrument playing a scale from the bottom
tone and up to the highest tone possible, a example is C, D, E, G, A.
It should the be possible to sample the tones at different points, the
points will in the example used be 
C
D
E
G
A

That function should provide Linuxsampler with a method of
synthesising more natural sounding instruments.


A sound example for a quite old scala played on one of the the Revheim
Lurs can be heard here :
http://abel.hive.no/trumpet/lur/bronze/revheim_tone_series.mp3


So, is that feature possible to implement

PS:
More info on the Revheim Lures can be read here:
http://abel.hive.no/trompet/lur/bronze/revheim/


-- 
Håken Hveem
Hamar
Norway
PGP/GPG Key ID : 0CD02A30

[Linuxsampler-devel] multi tonal sampling idea

[Håken H. <krb...@on...>]

I have a idea, is it possible to include a function that i call
"multi-tonal sampling"(or a better word).
I dont know if this feature already exists..

The function works as this:
You have a wav file with a instrument playing a scale from the bottom
tone and up to the highest tone possible, a example is C, D, E, G, A.
It should the be possible to sample the tones at different points, the
points will in the example used be 
C
D
E
G
A

That function should provide Linuxsampler with a method of
synthesising more natural sounding instruments.

So, is that feature possible to implement?


-- 
Håken Hveem
Hamar
Norway
PGP/GPG Key ID : 0CD02A30

Re: [Linuxsampler-devel] About commit to Linuxsampler 2013-01-08

[Christian S. <sch...@li...>]

On Friday 01 February 2013 00:24:56 Jostein Chr. Andersen wrote:
> I'm verry sorry for the late reply. I had to much to do and the last week
> and a half has been dedicated to fluefighting.

No problem. I also had no chance yet to follow this topic. Was distracted with 
some other work.

> The ride is tricky, because different parts of the ride can give noise at
> the same time (IE. bell and edge). But in the real life,the ride's context
> will usually be in a mix, so I think that a new hit it should mute the
> previous one, but let it decay over let's say 60-100 ms or something.
[snip]
> A dynamic and natural HH really demands that the previous sample are muted
> when it gets a new hit.

Both solutions, killing and not killing voices at all are both suboptimal. 
However I was also experimenting in a studio with a professional drummer, and 
we both found that the sound is much more worse and unrealistic, if a previous 
voice gets killed too quickly. No matter what kind of samples one is using, it 
would always sound like a digital toy.

> Maybe a Linuxsampler specific opcode or two will fix that? Is it possible
> to do somthing like this in stead of having nomuting as default: A global
> flag (ls_nomute=yes (default?)) and an override opcode that is valid in a
> region (ls_nomute=no) ?
> 
> I think that this way, Linuxsampler can handle a "real" drumset.

Currently I think about using the following 2 changes:

1. hard code a default release time for exclusive groups, which is not too 
fast and not too long, like you said, something around 100ms. GigaStudio seems 
to behave like this. And it would already be a bearable workaround for 
drumkits IMO.

2. Adding extensions to the gig as well as to the sfz format engines, allowing 
to optionally define 2 exact release times for exclusive group kills:

	- 1 parameter for release time for exclusive group killing voices on the 
	same note and

	- 1 release time for exclusive group killing voices on a foreign note.

Maybe Garritan or somebody already invented some opcode for this already?

CU
Christian

Re: [Linuxsampler-devel] About commit to Linuxsampler 2013-01-08

[Jostein C. A. <jo...@va...>]

Hi again Christian,


Just to get you in the mood and potentially been bitten by any problem that 
can occure when dealing with drum samples: Here is info about the 
UFIP 13" "Bionic Series" HH (3504 samples!) and anythin els in Natural drum 
Kit:

   http://naturaldrum.com/docs/NDKManual.pdf

The presets in the NDK are for Halion and Kontakt.


Two interesting HH related pages is 36 (mapping chart) 33 (openness, Halion) 
29 (articulation map).



If you look at page 36, then you can see that the left hand HH is at F0 
(MIDI note 17) and the right one at F3 (41) and that the modulation wheel 
will control (0-46) are controlling the openness of the HH. It's more that 
20 degrees of openness for the ordinary stics samples!


One serious problem with NDK is that panning (stereo samples) are chopped 
out in stone, so I extracted the strongest channel of each sample and 
monoized it, making it possible to "record" every drum item in mono as in 
most real life situation. Then I made  one gig for each drum item (one for 
HH, one for snare, one for each tom and so one), but not on every sample. 
NDK consists of many kits and I've been vaiting nearly 3 years (if I 
remember right) for a mature enough implementation of SFZ in LS. I'm glad I 
did not have the time to make SFZs of NDK the last year. :-)

For me, the NDK is so good sounding that it's worth the wait having LS 
handle it.

I think that both GIG and possible SFX have some shortcomings when it comes 
to handlig a drumset like this, but as I mentioned earlier: LS spesific 
opcodes kan deal with it. ....no wonder that many sample libraries comes 
with their own players! :-)


Jostein

Re: [Linuxsampler-devel] About commit to Linuxsampler 2013-01-08

[Jostein C. A. <jo...@va...>]

Hi Christian,

I'm verry sorry for the late reply. I had to much to do and the last week 
and a half has been dedicated to fluefighting.


Christian Schoenebeck wrote:
...
> again, sounded horrible synthetically. Especially on a ride cymbal, when
> the sampler simply chops off the previous voice while playing a roll on
> the cymbal, that sounds like somebody is pressing the fast rewind button
> on a CD player, but definitely not like a natural kit.
> 
> But since a drumkit has to obey the layout of a typical MIDI drumkit, so
> it can be played with i.e. any E-Drumkit (using pads), the ride cymbal has
> to be placed into an exclusive group, right?

The ride is tricky, because different parts of the ride can give noise at 
the same time (IE. bell and edge). But in the real life,the ride's context 
will usually be in a mix, so I think that a new hit it should mute the 
previous one, but let it decay over let's say 60-100 ms or something.


>> Also, think about a hi hat that you open and close gradually when it is
>> hit, the former hits really needs to be quiet - especially when you
>> gradually close the HH while playing on it. It sounds terrible when a old
>> sample with a longer decay still sounds when the last hit HH sample (IE a
>> closed HH) already is dead a HH don't play an open and closed hit at the
>> same time!
> 
> Right, the hi hat is probably the most complicated part in a high quality
> drumkit at all. So far I have just experimented with simple two way
> open/closed versions of hi hats, but not yet version where you can control
> the openness gradually. So I still have to experiment with that these days

If I recall right, the Big Mono kit from Analogue Drums have three degrees 
of openess for the HH and it's free of charge:

   http://www.analoguedrums.com/details-bm.php

And it sounds great too! :-)

> Before I commited this change, I discussed it with Andreas, because I was
> unsure about it as well. And he said, it seems as GigaStudio is solving it
> like this: it chops off voices of the same note in an exclusive group,
> however with a longer release time than LinuxSampler (did). So I am
> wondering if that would be the best trade off for this overall problem.
> 
> What do you think?

A dynamic and natural HH really demands that the previous sample are muted 
when it gets a new hit.

Maybe a Linuxsampler specific opcode or two will fix that? Is it possible to 
do somthing like this in stead of having nomuting as default: A global flag 
(ls_nomute=yes (default?)) and an override opcode that is valid in a region 
(ls_nomute=no) ?

I think that this way, Linuxsampler can handle a "real" drumset.


Jostein

Re: [Linuxsampler-devel] Convolution files?

[Andreas P. <and...@br...>]

On 2013-01-19 21:58, James Stone wrote:
> I have some convolution files for white grand (for example) that seem to
> be .gig files, but when I use gigextract, the only sample it finds is blank.
> 
> Do any of you know if it is possible to get a usable wav file out of the
> gs3 convolution files for use in jconvolver (for example)?

The impulse data in gig and IIS (gigapulse) files is encrypted, so we
can't extract it.

/Andreas

Re: [Linuxsampler-devel] Convolution files?

[Christian S. <sch...@li...>]

On Saturday 19 January 2013 21:58:27 James Stone wrote:
> I have some convolution files for white grand (for example) that seem to be
> .gig files, but when I use gigextract, the only sample it finds is blank.
> 
> Do any of you know if it is possible to get a usable wav file out of the
> gs3 convolution files for use in jconvolver (for example)?

We never worked on supporting convolution informations, sorry. So as long as 
convolution samples are stored differently in .gig files than "normal" 
samples, libgig & gigextract won't be able to export them correctly. Actually 
I don't even have one .gig file with convolution informations, so I can't tell 
you at all.

You might also try "gigdump" and "rifftree" to investigate whether or not 
libgig recognizes those samples at all (gigdump displays all sample names 
along with the meta informations it found) and / or whether they are in a 
related data format by checking the output of rifftree.

If they are in similar data format, we probably could add support for those in 
libgig (and accordingly gigextract) in short time.

CU
Christian

[Linuxsampler-devel] Convolution files?

[James S. <jam...@gm...>]

I have some convolution files for white grand (for example) that seem to be
.gig files, but when I use gigextract, the only sample it finds is blank.

Do any of you know if it is possible to get a usable wav file out of the
gs3 convolution files for use in jconvolver (for example)?

James

Re: [Linuxsampler-devel] Flac support for the SFZ sampler engine

[Graham G. <ggo...@gm...>]

On 1/13/13, Andreas Persson <and...@br...> wrote:
> I've implemented the flac support now. I thought it was easier to keep
> the the streaming buffer 24 bit instead of using floats. That also keeps
> memory usage down. The alternative, to use floats in the buffer, would
> make the code cleaner and maybe more CPU efficient. Feel free to change
> it if you want.
>
> /Andreas

Thanks Andreas,

I'll get a chance to test this again later in the week.

Kind regards,
GrahamG

Re: [Linuxsampler-devel] Flac support for the SFZ sampler engine

[Andreas P. <and...@br...>]

On 2013-01-13 14:42, Christian Schoenebeck wrote:
> On Sunday 13 January 2013 09:40:31 you wrote:
>> flac most definitely does _not_ work. I asked about this in
>> June. You might hope it would work through libsndfile, but it
>> fails because of the way the sound files are loaded and used;
>> the relevant source file is src/engines/common/SampleFile.cpp
> 
> Yes, you are right. With the current code it does not work. And you are also 
> right, that the code should be flipped there to actually use sf_readf_*() by 
> default instead of sf_read_raw(). And that code part should be cleaned a bit.
> 
> My spare time is currently very limited, and I have other priorities on my 
> TODO list regarding the sampler on top right now. But I try to handle this 
> issue after I hunted down the other issues, in case no other developer did in 
> the meantime. But no guarantee on when that will be exactly. ;-)

I've implemented the flac support now. I thought it was easier to keep
the the streaming buffer 24 bit instead of using floats. That also keeps
memory usage down. The alternative, to use floats in the buffer, would
make the code cleaner and maybe more CPU efficient. Feel free to change
it if you want.

/Andreas

Re: [Linuxsampler-devel] About commit to Linuxsampler 2013-01-08

[rosea.grammostola <ros...@gm...>]

FYI, here you can find pretty some (recent) SFZ mappings for drumkits, 
which might be nice as reference

http://www.drealm.info/sfz/AnalogueDrums/

In the Bigmono Linuxsampler sfz file I read:

======================
// Here are those off_bys - linuxsampler doesn't yet support end=-1 for 
silent regions

// closed, so off_by 2 is anything vaguely open:
<group> end=-1 ampeg_sustain=-96 volume=-48 sample=Rodgers_DynRH02.wav 
group=2
<region> key=053 hicc4=124 locc4=000
<region> lokey=056 hikey=057

// closed, so off_by 8 is anything vaguely open:
<group> end=-1 ampeg_sustain=-96 volume=-48 sample=Rodgers_DynRH02.wav 
group=8
<region> key=053 hicc4=124 locc4=000
<region> lokey=056 hikey=057

// semiOpen, so off_by 4 is anything closed:
<group> end=-1 ampeg_sustain=-96 volume=-48 sample=Rodgers_DynRH02.wav 
group=4
<region> key=053 hicc4=127 locc4=125
<region> lokey=054 hikey=055
<region> key=058

// open, so off_by 6 is anything less open:
<group> end=-1 ampeg_sustain=-96 volume=-48 sample=Rodgers_DynRH02.wav 
group=6
<region> key=053 hicc4=127 locc4=063
<region> lokey=054 hikey=056
<region> key=058
======================

I wrote Pljones about it:

PS2. I think LinuxSampler does support 'end=' now

 >> It wasn't "end=" but "end=-1" that was missing. It was in sfz.exe, 
meaning "process the region but don't play a sample at all"... It's was 
a dirty hack but very useful for mute groups. sforzando and ARIA Player 
have a much cleaner sample=*silence to mean the same thing (sfz.exe 
required a sample= reference to a file that existed, even with end=-1...).


Hth

Re: [Linuxsampler-devel] Flac support for the SFZ sampler engine

[Christian S. <sch...@li...>]

On Sunday 13 January 2013 09:40:31 you wrote:
> flac most definitely does _not_ work. I asked about this in
> June. You might hope it would work through libsndfile, but it
> fails because of the way the sound files are loaded and used;
> the relevant source file is src/engines/common/SampleFile.cpp

Yes, you are right. With the current code it does not work. And you are also 
right, that the code should be flipped there to actually use sf_readf_*() by 
default instead of sf_read_raw(). And that code part should be cleaned a bit.

My spare time is currently very limited, and I have other priorities on my 
TODO list regarding the sampler on top right now. But I try to handle this 
issue after I hunted down the other issues, in case no other developer did in 
the meantime. But no guarantee on when that will be exactly. ;-)

CU
Christian

Re: [Linuxsampler-devel] About commit to Linuxsampler 2013-01-08

[Christian S. <sch...@li...>]

On Saturday 12 January 2013 20:49:46 Jostein Chr. Andersen wrote:
> After a look at http://www.linuxsampler.org/,  I have a little comment
> about this commit:
> 
>     2013-01-08 schoenebeck
>     * Exclusive Groups: don't ever stop voices of the same note,
>       doesn't sound naturally with a drumkit.

First off, I was a bit imprecise in that comment: this change only affects the 
Gig format engine so far, not the SF or SFZ engines yet.

> This change is good for most drum items, for example when you play a ride
> cymbal, but not for a hi hat. A good professional sampled HH have many
> layers of openness - not only closed HH and open HH - but also many layers
> between this two states. And in this case, this samples with velocities and
> each velocity's level of openness be in the same note and be controlled
> with a drum pad with it's pedal or a key and a CC (for example an
> expression pedal). Another example is that a roll from the right stick
> need the be killed when you hit a roll again with the right stick. It will
> be many thing thing going on if former samples don't die when yo play roll
> samples with both right and left hands!

Actually I am not yet sure about the best way to handle that. So maybe we can 
discuss this a bit more. I was recently investigating how to make high quality 
drumkits sound as natural as possible with the sampler. And fact is, the way 
it was before the mentioned commit above, that is when voices of an exclusive 
group were killed even when triggering the same note again, sounded horrible 
synthetically. Especially on a ride cymbal, when the sampler simply chops off 
the previous voice while playing a roll on the cymbal, that sounds like 
somebody is pressing the fast rewind button on a CD player, but definitely not 
like a natural kit.

But since a drumkit has to obey the layout of a typical MIDI drumkit, so it 
can be played with i.e. any E-Drumkit (using pads), the ride cymbal has to be 
placed into an exclusive group, right?

> Also, think about a hi hat that you open and close gradually when it is
> hit, the former hits really needs to be quiet - especially when you
> gradually close the HH while playing on it. It sounds terrible when a old
> sample with a longer decay still sounds when the last hit HH sample (IE a
> closed HH) already is dead a HH don't play an open and closed hit at the
> same time!

Right, the hi hat is probably the most complicated part in a high quality 
drumkit at all. So far I have just experimented with simple two way 
open/closed versions of hi hats, but not yet version where you can control the 
openness gradually. So I still have to experiment with that these days ...

Before I commited this change, I discussed it with Andreas, because I was 
unsure about it as well. And he said, it seems as GigaStudio is solving it 
like this: it chops off voices of the same note in an exclusive group, however 
with a longer release time than LinuxSampler (did). So I am wondering if that 
would be the best trade off for this overall problem.

What do you think?

CU
Christian

Re: [Linuxsampler-devel] Flac support for the SFZ sampler engine

[Gerard J. <ju...@cy...>]

flac most definitely does _not_ work. I asked about this in
June. You might hope it would work through libsndfile, but it
fails because of the way the sound files are loaded and used;
the relevant source file is src/engines/common/SampleFile.cpp

Here is the link to that thread:
  http://sourceforge.net/mailarchive/message.php?msg_id=29408426

The response was somewhat helpful, but not enough to motivate
doing something about it. That little section of code is
probably more confusing than it should be.

--
G. Jungman