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

[Linuxsampler-devel] [linuxsampler-devel] Paulstretch engine?

[Andrew C <cou...@gm...>]

Hi guys,

A bit of a "non-trivial" feature to implement in Linuxsampler would be an
implementation of paulstretch for voice-stretching.

It already produces really cool effects and it'd be interesting to see it
in linuxsampler(assuming it could process samples in real-time!).

Would be cool to see it as an option in gigedit/opcodes for sfz where you
could select stretch amount up/down from its root note (then stretch X%
up/down for each note accumulatively)

I wouldn't opposed to contributing monetarily to the project for some R&D
into this, but I probably should bring that off-list. :O

Andrew.

Re: [Linuxsampler-devel] Hello and a question: Running LinuxSampler on MacOS High Sierra

[Robert O. <rob...@gm...>]

On 2018. May 4., at 12:11, Christian Schoenebeck <sch...@li...> wrote:
> So just reboot your Mac, add a LinuxSampler AU track in Logic, then open
> QSampler/Fantasia and load the gig instrument.
That did it. I was able to load and play a patch from the Garritan Orchestra. Logic’s incompatible plugin warning shows up at every startup, but at least it works now. Huge thanks for your help!

I am wondering, is there a way to control the engine via the command line, or via other means besides the two frontends? Unfortunately, choosing an instrument index in the loaded file in Fantasia is quite cumbersome with VoiceOver, as it pops up a separate window. Other parts, such as the directory browser are also not exposing their content properly.

Essentially, since I have a few hundred giga files, what I would like is a way to print the available indexes and to load an instrument via that index from a .gig file. This can be through the database as well.

QSampler might work better, however, it fails to start on my system. From the console:

Termination Reason:    DYLD, [0x1] Library missing
Dyld Error Message:
  Library not loaded: /home/*/libgig.7.dylib
  Referenced from: /Applications/LinuxSampler/qsampler.app/Contents/MacOS/qsampler
  Reason: image not found

Once again, thank you very much for your help, it would have been really impossible to make all this work otherwise!

Rob

Re: [Linuxsampler-devel] Hello and a question: Running LinuxSampler on MacOS High Sierra

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

On Donnerstag, 3. Mai 2018 16:11:19 CEST Robert O. wrote:
> > On 2018. May 3., at 14:31, Christian Schoenebeck
> > <sch...@li...> wrote: 3. Launch Logic and add your track
> > with LinuxSampler as AU.
> 
> Unfortunately, When I add the AU instrument, Logic freezes. The track is not
> created, and the LinuxSampler engine does not print anything additional to
> the screen. The last line is: LinuxSampler initialization completed. :-)

Sorry, I gave you one wrong information: omit step 2. described in my previous 
email. I forgot that by default the AU also launches the sampler backend 
(including LSCP server).

So just reboot your Mac, add a LinuxSampler AU track in Logic, then open 
QSampler/Fantasia and load the gig instrument.

If that is still causing Logic to freeze then please check if you find any 
useful or suspicious information with the Mac's "Console" utility
(Applications -> Utilities -> Console).

CU
Christian

Re: [Linuxsampler-devel] Hello and a question: Running LinuxSampler on MacOS High Sierra

[Robert O. <rob...@gm...>]

> On 2018. May 3., at 14:31, Christian Schoenebeck <sch...@li...> wrote:
> 3. Launch Logic and add your track with LinuxSampler as AU.
Unfortunately, When I add the AU instrument, Logic freezes. The track is not created, and the LinuxSampler engine does not print anything additional to the screen. The last line is:
LinuxSampler initialization completed. :-)

Best,
Rob

Re: [Linuxsampler-devel] Hello and a question: Running LinuxSampler on MacOS High Sierra

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

On Mittwoch, 2. Mai 2018 18:36:13 CEST you wrote:
> > First of all, which version of the sampler installer have you used?
> 
> I used linuxsampler_20180210.
> 
> Since then, I think I made some progress. I was able to launch
> “linuxsampler” from the terminal, and load a .gig file, however my daw
> (Logic) seems to freeze when I try to add a track which uses LinuxSampler
> as the sampler engine.
> 
> Having said that, I am not sure if the defaults are okay when creating a
> Midi device, audio device, or loading an instrument. Unfortunately, I am
> unable to change some settings (such as port, audio device, instrument
> index in a bank, etc) in Fantasia, because the value does not change in the
> dropdown menus when the arrow keys are used.

The AU Plugin creates the MIDI device and audio device on its own. So that's 
an important aspect to know about. Because when you create audio / MIDI 
devices manually i.e. with QSampler/Fantasia (i.e. before you can actually 
create a LinuxSampler track in Logic) then the sampler will directly access 
your CoreAudio hardware, and that's only what you want to do if you use the 
sampler as stand-alone application.

So please try the following:

1. Reboot your Mac (just to get a clear ground for resolving this for now).

2. Launch the LinuxSampler engine, which will launch a text-only window on 
   your Mac. Don't do any further setup at this point i.e. with QSampler/
   Fantasia or something.

3. Launch Logic and add your track with LinuxSampler as AU.

4. Launch your favorite LinuxSampler frontend app (QSampler/Fantasia).

5. The AU should now already have created the audio and MIDI device (special
   ones for AU usage) and the AU should also already have a created one 
   sampler part (or two if you added two tracks in Logic) . 

6. Now just edit the respective sampler part and load your gig instrument. 
   Make sure that a) "Giga" engine is selected and b) that for audio/MIDI 
   device the AU device is selected, not CoreAudio or CoreMIDI!

CU
Christian

Re: [Linuxsampler-devel] Hello and a question: Running LinuxSampler on MacOS High Sierra

[Robert O. <rob...@gm...>]

> First of all, which version of the sampler installer have you used?
I used linuxsampler_20180210.

Since then, I think I made some progress. I was able to launch “linuxsampler” from the terminal, and load a .gig file, however my daw (Logic) seems to freeze when I try to add a track which uses LinuxSampler as the sampler engine.

Having said that, I am not sure if the defaults are okay when creating a Midi device, audio device, or loading an instrument. Unfortunately, I am unable to change some settings (such as port, audio device, instrument index in a bank, etc) in Fantasia, because the value does not change in the dropdown menus when the arrow keys are used.

Rob


> On 2018. Apr 29., at 15:17, Christian Schoenebeck <sch...@li...> wrote:
> 
> On Freitag, 27. April 2018 16:49:00 CEST Robert O. wrote:
>> Hello all,
>> This is Robert. I am new to the list and to LinuxSampler.
> 
> Hi Robert!
> 
>> I have found that none of the existing sample converters work well with my
>> existing Giga libraries, so you can imagine my delight to find that there
>> is a sampler that works on OSX and has decent Giga support from the start.
> 
> Yeah, currently I do not know of any converter which handles the gig format
> correctly. The majority will simply convert that samples, but that's pretty
> much it.
> 
>> Unfortunately, I am facing issues in using LinuxSampler, and since the
>> documentation seems a bit outdated, I was wondering if anyone could point
>> me in the right direction.
> 
> The Mac docs are not old, they are ancient. :)
> 
>> I have tried to open the Sampler.app program, however it just terminates
>> unexpectedly. I am  unsure about what my next step should be, any help is
>> greatly appreciated.
> 
> First of all, which version of the sampler installer have you used? Can you
> paste the precise file name of the installer which you downloaded and
> installed? The installer file names contain either the sampler's release
> version (on official releases) or a date (on automatic snapshot builds) as part
> of the installer's file name.
> 
> CU
> Christian
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Hello and a question: Running LinuxSampler on MacOS High Sierra

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

On Freitag, 27. April 2018 16:49:00 CEST Robert O. wrote:
> Hello all,
> This is Robert. I am new to the list and to LinuxSampler.

Hi Robert!

> I have found that none of the existing sample converters work well with my
> existing Giga libraries, so you can imagine my delight to find that there
> is a sampler that works on OSX and has decent Giga support from the start.

Yeah, currently I do not know of any converter which handles the gig format 
correctly. The majority will simply convert that samples, but that's pretty 
much it.

> Unfortunately, I am facing issues in using LinuxSampler, and since the
> documentation seems a bit outdated, I was wondering if anyone could point
> me in the right direction.

The Mac docs are not old, they are ancient. :)

> I have tried to open the Sampler.app program, however it just terminates
> unexpectedly. I am  unsure about what my next step should be, any help is
> greatly appreciated.

First of all, which version of the sampler installer have you used? Can you 
paste the precise file name of the installer which you downloaded and 
installed? The installer file names contain either the sampler's release 
version (on official releases) or a date (on automatic snapshot builds) as part 
of the installer's file name.

CU
Christian

[Linuxsampler-devel] Hello and a question: Running LinuxSampler on MacOS High Sierra

[Robert O. <rob...@gm...>]

Hello all,
This is Robert. I am new to the list and to LinuxSampler.

I have found that none of the existing sample converters work well with my existing Giga libraries, so you can imagine my delight to find that there is a sampler that works on OSX and has decent Giga support from the start.

Unfortunately, I am facing issues in using LinuxSampler, and since the documentation seems a bit outdated, I was wondering if anyone could point me in the right direction.

I am using MacOS High Sierra 10.13.4 and Logic Pro X version 10.4.1. I also have to point out that I am blind, so I am using VoiceOver, the built-in screen reader of the MAc.

After installing the AU version of LinuxSampler and restarting Logic, I am warned that the AU plugin is incompatible and it did not pass validation. I can ignore this, and enable the plugin, however, I do not see any controls thus I am unable to load any .gig file via the plugin overlay.

I have tried to open the Sampler.app program, however it just terminates unexpectedly.
I am  unsure about what my next step should be, any help is greatly appreciated.

Best,
Rob

Re: [Linuxsampler-devel] [linuxsampler-devel] Many thanks for Linuxsampler!

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

On Donnerstag, 26. April 2018 10:20:43 CEST Andrew C wrote:
> Just wanted to express my thanks for the existence and continued
> development of Linuxsampler, by the many contributors to the project.

Hey, thank you! Always a pleasure to also hear some appreciation once in a 
while. :-)

> Thanks again to Christian for actually *extending* the gig (and sfz) format
> with NKSP.. Like damn, the possibilities this alone opens up!

Yep, a load of potential. You can definitely achieve a lot more with NKSP than 
anything Tascam tried with their iMIDI rules, their legato rules, etc. Those 
solutions always had some kind of limitations which you do not have with 
scripts. And it also adds a load of new possibilites to the SFZ format as 
well, which would be not possible with SFZ opcodes alone.

> Guess giga as a format isn't quite dead yet on Linux? ;-)

Yeah, I mean SFZ became quite popular nowadays, but I still like some benefits 
of the gig format, for example the monolithic storage (everything needed 
stored in the same file) and of course that most tasks simply require a few 
clicks in gigedit.

However we have both formats, and I try to keep them on par with new features.

> As a side note, I'll have to learn how to send commands via lscp.. I am
> painfully aware there may come a time Linuxsampler's engine features will
> far outstrip Fantasia's current GUI programming!

Unfortunately Fantasia is not maintained for several years now. So yes, for 
missing features neither covered by Fantasia nor by QSampler you might want to 
do that more directly with LSCP. You could try out the "LSCP shell" which 
comes with the sampler:

http://doc.linuxsampler.org/LSCP_Shell/

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] Many thanks for Linuxsampler!

[Andrew C <cou...@gm...>]

Hi all,

Just wanted to express my thanks for the existence and continued
development of Linuxsampler, by the many contributors to the project.

Fantastic sampler I can run headless, with multiple instances on the same
PC, all streaming from disk!

Thanks again to Christian for actually *extending* the gig (and sfz) format
with NKSP.. Like damn, the possibilities this alone opens up!

Guess giga as a format isn't quite dead yet on Linux? ;-)

As a side note, I'll have to learn how to send commands via lscp.. I am
painfully aware there may come a time Linuxsampler's engine features will
far outstrip Fantasia's current GUI programming!

Andrew.

Re: [Linuxsampler-devel] [linuxsampler-devel] Simple and stupid crossfade creator?

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

On Freitag, 13. April 2018 17:37:16 CEST Andrew C wrote:
> Fair points, I was just hoping to bring some automation, but I'm sure
> that's not worth the development time on your side :-)

Yes, personally I simply would not need such a feature.

In the end you have the libgig sources, which also come with a bunch of 
command line tools. So you could try simply copy paste gig2stereo.cpp (or any 
other one of the tools) as a starting point and adjust it to create your 
personal tailored conversion tool which nails down exactly what you need it to 
do. Be brave, you can do that! ;-)

> Also started another "think-tank" on the smartmidi legato scripting for
> westgate woodwinds and other(VSL giga instruments? Same principles)
> smartmidi instruments.
> After a few days investigation into 'how' the legato should sound/be
> scripted, I'm nearly ready to write some code.. (making plans for plans!)
> Watch this space? ;-)

That's how it works. The concept always first.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Simple and stupid crossfade creator?

[Andrew C <cou...@gm...>]

Fair points, I was just hoping to bring some automation, but I'm sure
that's not worth the development time on your side :-)

Also started another "think-tank" on the smartmidi legato scripting for
westgate woodwinds and other(VSL giga instruments? Same principles)
smartmidi instruments.
After a few days investigation into 'how' the legato should sound/be
scripted, I'm nearly ready to write some code.. (making plans for plans!)
Watch this space? ;-)

Andrew.

On Sat, Apr 7, 2018 at 12:34 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Dienstag, 3. April 2018 19:24:58 CEST Andrew C wrote:
> > Would it be out of the question for me to enquire about the future
> > development of a "simple and stupid" automatic crossfade creator for
> > Gigedit?
> >
> > Based on the prerequistes that all velocity layers are "layer" types,
> would
> > it be a reasonable idea  for all layers of all dimensions have their
> > 'crossfade' data start and end points sliced up and split from the
> > available 127 crossfade points, evenly across all layers?
>
> Mmmm, not sure if that would make sense. There are already features in
> gigedit
> to achieve that. You can either use gigedit's "combine tool" to combine
> existing sounds to one crossfade layered sound, or you can simply change
> the
> dimension type of such an existing instrument from dimension type
> "velocity"
> to type "layer".
>
> Then the only task left would be to fine tune the crossfade points of that
> layered instrument. In practice almost all sounds on the market use the
> same
> velocity split points for all regions. Accordingly you can just
>
> 1. enable check boxes "all regions"
>
> 2. uncheck check box "all dimension splits"
>
> 3.1. select the respective layer
>
> 3.2 adjust/fine tune selected layer's crossfade points
>
> Then condinue with 3.1 until all few layers are adjusted.
>
> That's probably a 2 minute job or even less.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [linuxsampler-devel] Simple and stupid crossfade creator?

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

On Dienstag, 3. April 2018 19:24:58 CEST Andrew C wrote:
> Would it be out of the question for me to enquire about the future
> development of a "simple and stupid" automatic crossfade creator for
> Gigedit?
> 
> Based on the prerequistes that all velocity layers are "layer" types, would
> it be a reasonable idea  for all layers of all dimensions have their
> 'crossfade' data start and end points sliced up and split from the
> available 127 crossfade points, evenly across all layers?

Mmmm, not sure if that would make sense. There are already features in gigedit 
to achieve that. You can either use gigedit's "combine tool" to combine 
existing sounds to one crossfade layered sound, or you can simply change the 
dimension type of such an existing instrument from dimension type "velocity" 
to type "layer".

Then the only task left would be to fine tune the crossfade points of that 
layered instrument. In practice almost all sounds on the market use the same 
velocity split points for all regions. Accordingly you can just

1. enable check boxes "all regions"

2. uncheck check box "all dimension splits"

3.1. select the respective layer

3.2 adjust/fine tune selected layer's crossfade points

Then condinue with 3.1 until all few layers are adjusted.

That's probably a 2 minute job or even less.

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] Simple and stupid crossfade creator?

[Andrew C <cou...@gm...>]

HI all,

Long time no see. :-)

I have an older sample gig library (Dan Dean Solo Woodwinds) that I'm
interested in creating modwheel crossfades for.

Would it be out of the question for me to enquire about the future
development of a "simple and stupid" automatic crossfade creator for
Gigedit?

Based on the prerequistes that all velocity layers are "layer" types, would
it be a reasonable idea  for all layers of all dimensions have their
'crossfade' data start and end points sliced up and split from the
available 127 crossfade points, evenly across all layers?

i.e
Instrument with 3 velocity layers:
CF in-start: 0
CF in-end: 0
CF out-start: 15
CF out-end: 72

CF in-start: 8
CF in-end: 56
CF out-start: 80
CF out-end: 120

CF in-start: 73
CF in-end: 113
CF out-start: 127
CF out-end: 127

Cheers,

Andrew.

Re: [Linuxsampler-devel] Cracks and xruns in audio

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

On Freitag, 9. Februar 2018 19:36:19 CET Thomas Howe wrote:
> I tried setting the maximum number of voices and disk streams to 1000 each
> and this has helped a lot with one sample library (Maestro Concert Grand
> v2). There are still occasional note drop outs, but only in extreme
> circumstances, and no more xruns.

The xruns you got are most probably because your system is not configured to be 
real-time stable. And considering the very small period size you want to 
achieve, makes this configuration task even more challenging. Please note 
though that configuring a real-time stable system goes beyond the scope of this 
list. I am sure you find newbie howto's for that on the net or ask on the web 
forum or on the LAD mailing list for help on that topic.

> I store the sample libraries in RAM to avoid disk speed problems. Maybe the
> RAM isn't fast enough, or pitch-shifting (for the Salamander Grand Piano
> v3) is causing ‘disk stream’ errors? I'm also running Jack at a higher

Very unlikely.

> Regarding the voice stealing cut-offs, have I got this right? If it turns
> out to be impossible for me to get full polyphony at a lower buffer size
> without xruns, I would need to set a voice limit. Reaching the voice limit
> set in linuxsampler causes clicks, so I'd need this to be done through an
> external MIDI voice limiting program sending note off messages when the
> limit is reached. I might also need to modify the release samples in cases
> like the Salamander Grand which has a slightly percussive release sound.

Or you simply decrease the value of the compile time option 
EG_MIN_RELEASE_TIME to your period size, like I already told you in the 
previous email.

There are plenty of experiments you could try out, but in the end the easiest 
solution is to simply configure your audio session with 1ms latency which works 
right out of the box.

I mean it depends whether you really just want to make some theoretical 
experiments there, or whether you are seeking for a practical solution. 
Because in practice it is quite unlikely that you can feel the latency 
difference between an audio period duration of 0.6ms vs. 1ms. Plus in practice 
the various hardware components involved (i.e. your MIDI keyboard) often add 
latencies of several ms and people don't even realize that.

You should also be aware that the smaller the audio period size, the higher 
the CPU overhead will be. So CPU utilization grows significantly more than 
anti-propopertional the lower you set the perdiod size. And in practice the 
negative impact of the latter is usually much higher to the user than the 
advantage you get by gaining 0.5ms latency.

> htop reports that only one of the linuxsampler threads runs at realtime
> priority by default, so I'll experiment with setting the others to realtime
> priority too.

The priority has nothing to do with that. The disk thread is most of the time 
waiting for I/O to complete and modifying the priority will not change that.

> Also, linuxsampler asked me to report this (I think number of voices and
> disk streams was set to 200?):

I also explained that to you in the previous email already as well: you always 
have to set max streams higher than max. voices, otherwise it will lead to 
exactly what you just encountered.

CU
Christian

Re: [Linuxsampler-devel] Cracks and xruns in audio

[Thomas H. <tho...@gm...>]

Thank you for your reply!


I tried setting the maximum number of voices and disk streams to 1000 each
and this has helped a lot with one sample library (Maestro Concert Grand
v2). There are still occasional note drop outs, but only in extreme
circumstances, and no more xruns.


I store the sample libraries in RAM to avoid disk speed problems. Maybe the
RAM isn't fast enough, or pitch-shifting (for the Salamander Grand Piano
v3) is causing ‘disk stream’ errors? I'm also running Jack at a higher
sample rate, but I'm guessing that resampling all the libraries to 96 kHz
would increase rather than decrease the total processing?


Regarding the voice stealing cut-offs, have I got this right? If it turns
out to be impossible for me to get full polyphony at a lower buffer size
without xruns, I would need to set a voice limit. Reaching the voice limit
set in linuxsampler causes clicks, so I'd need this to be done through an
external MIDI voice limiting program sending note off messages when the
limit is reached. I might also need to modify the release samples in cases
like the Salamander Grand which has a slightly percussive release sound.


htop reports that only one of the linuxsampler threads runs at realtime
priority by default, so I'll experiment with setting the others to realtime
priority too.



Also, linuxsampler asked me to report this (I think number of voices and
disk streams was set to 200?):


Jack: JackClient::ClientNotify ref = 11 name = LinSmPSR16 notify = 1

Jack: JackClient::RemoveClient name = LinSmPSR16, ref = 11

Jack: JackClient::kRemoveClient fName = LinuxSampler name = LinSmPSR16

Jack: JackClientSocket::Close

Jack: JackClientSocket::Close

Jack: JackLibClient::~JackLibClient

Jack: JackShmReadWritePtr1::~JackShmReadWritePtr1 11

Jack: Succeeded in unlocking 422 byte memory area

Jack: jack_client_close res = 0

Jack: JackClient::ClientNotify ref = 9 name = LinuxSampler notify = 18

Jack: JackClient::ClientNotify ref = 9 name = LinuxSampler notify = 18

04:57:29.542 Channel 1 Mute: 1.

No unused stream found (OrderID:128) - report if this happens, this is a
bug!

No unused stream found (OrderID:130) - report if this happens, this is a
bug!

Disk stream not available in time!

Disk stream not available in time!

No unused stream found (OrderID:170) - report if this happens, this is a
bug!

No unused stream found (OrderID:184) - report if this happens, this is a
bug!

No unused stream found (OrderID:190) - report if this happens, this is a
bug!

Disk stream not available in time!

No unused stream found (OrderID:4) - report if this happens, this is a bug!

Disk stream not available in time!

Disk stream not available in time!

No unused stream found (OrderID:25) - report if this happens, this is a bug!

Disk stream not available in time!

No unused stream found (OrderID:35) - report if this happens, this is a bug!

Disk stream not available in time!

Disk stream not available in time!

No unused stream found (OrderID:46) - report if this happens, this is a bug!

Disk stream not available in time!


I added a second instrument on the same channel, muted the first one, and
got a bunch of xruns while playing. I don't think I need multiple
linuxsampler instruments running at the same time, so this isn't really a
problem for me.


Tom


On 8 February 2018 at 18:18, Christian Schoenebeck <
sch...@li...> wrote:

> On Donnerstag, 8. Februar 2018 16:00:53 CET Thomas Howe wrote:
> > Hi all,
> >
> > Please let me know if there's a better place to be sending these
> messages...
>
> The list is fine for that, it just became a bit more silent over here than
> it
> used to be. When it comes to newbie questions, those might probably quicker
> being answered on the web forum instead:
>
>         https://bb.linuxsampler.org/
>
> > I think I've identified the problems a bit more clearly now:
> >
> > 0.0025 ms isn't a long enough fadout to prevent an audible click in some
> > cases, yet it is also too long to fit within a realtime buffer size. To
> > prevent the clicks ruining a performance, the fadeout time for voice
> > stealing needs to be quite a lot higher than the period size. Maybe
> around
> > 20ms to be on the safe side?
>
> Voice stealing is bound to the same audio fragment cycle. For one reason:
> if
> it was posponed to a subsequent audio fragment cycle then it would add
> (audible) latency to the newly spawned note/voice.
>
> So when voice stealing kicks in, it picks an old voice, "kills" the old
> voice,
> which means it ramps its volume down as fast as possible (as defined by
> CONFIG_EG_MIN_RELEASE_TIME), renders its audio, then the voice object is
> immediately conquered by the new note, which immediately starts to render
> its
> audio with the same voice (C++) object. So the trick is, when this is done
> in
> the same audio fragment, then you are using one voice (C++) object for
> actually two audible voices simultaniously, and hence it adds no latency
> for
> the new note/voice.
>
> Accordingly CONFIG_EG_MIN_RELEASE_TIME must not be bigger than your period
> size, otherwise you will see that mentioned warning message and you hear
> clicks. CONFIG_EG_MIN_RELEASE_TIME is a compile time option which you may
> lower to a certain degree. But obviously as soon as you make it soo small
> it
> results in audible clicks.
>
> > The maximum number of audio streams should never be reached, as voice
> > stealing should keep the number of audio streams to a sane level. But if
> > enough notes are played in too short a time to release within 20ms,
> maybe a
> > fadeout based on the period size should be used as a last resort?
>
> Streams and voices are dynamically assigned to each other. That's because
> the
> two are handled by two separate threads (disk thread and audio thread). So
> a
> voice requests a stream when it needs it and releases it when no longer
> needed. Due to the latency involved for handling this, the amount of max.
> streams should be higher than the amount of max. voices in practice.
>
> > I also notice that “Least buffer fill stream usage” in Qsampler exceeds
> 50%
> > fairly often, the linuxsampler process never takes up more than 10 CPU.
> > Maybe there's some internal limit on how much processing linuxsampler
> gets,
> > which could be removed?
>
> The performance bottle neck is usually the disk, not the CPU. But as long
> as
> you don't get audio dropouts then you can try to increase max. voices (and
> max. streams) to achieve a higher polyphony and reduce the potential
> requirement for voice stealing. You can easily play around with that i.e.
> from
> QSampler's settings dialog.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] Cracks and xruns in audio

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

On Donnerstag, 8. Februar 2018 16:00:53 CET Thomas Howe wrote:
> Hi all,
> 
> Please let me know if there's a better place to be sending these messages...

The list is fine for that, it just became a bit more silent over here than it 
used to be. When it comes to newbie questions, those might probably quicker 
being answered on the web forum instead:

	https://bb.linuxsampler.org/

> I think I've identified the problems a bit more clearly now:
> 
> 0.0025 ms isn't a long enough fadout to prevent an audible click in some
> cases, yet it is also too long to fit within a realtime buffer size. To
> prevent the clicks ruining a performance, the fadeout time for voice
> stealing needs to be quite a lot higher than the period size. Maybe around
> 20ms to be on the safe side?

Voice stealing is bound to the same audio fragment cycle. For one reason: if 
it was posponed to a subsequent audio fragment cycle then it would add 
(audible) latency to the newly spawned note/voice.

So when voice stealing kicks in, it picks an old voice, "kills" the old voice, 
which means it ramps its volume down as fast as possible (as defined by 
CONFIG_EG_MIN_RELEASE_TIME), renders its audio, then the voice object is 
immediately conquered by the new note, which immediately starts to render its 
audio with the same voice (C++) object. So the trick is, when this is done in 
the same audio fragment, then you are using one voice (C++) object for 
actually two audible voices simultaniously, and hence it adds no latency for 
the new note/voice.

Accordingly CONFIG_EG_MIN_RELEASE_TIME must not be bigger than your period 
size, otherwise you will see that mentioned warning message and you hear 
clicks. CONFIG_EG_MIN_RELEASE_TIME is a compile time option which you may 
lower to a certain degree. But obviously as soon as you make it soo small it 
results in audible clicks.

> The maximum number of audio streams should never be reached, as voice
> stealing should keep the number of audio streams to a sane level. But if
> enough notes are played in too short a time to release within 20ms, maybe a
> fadeout based on the period size should be used as a last resort?

Streams and voices are dynamically assigned to each other. That's because the 
two are handled by two separate threads (disk thread and audio thread). So a 
voice requests a stream when it needs it and releases it when no longer 
needed. Due to the latency involved for handling this, the amount of max. 
streams should be higher than the amount of max. voices in practice.

> I also notice that “Least buffer fill stream usage” in Qsampler exceeds 50%
> fairly often, the linuxsampler process never takes up more than 10 CPU.
> Maybe there's some internal limit on how much processing linuxsampler gets,
> which could be removed?

The performance bottle neck is usually the disk, not the CPU. But as long as 
you don't get audio dropouts then you can try to increase max. voices (and 
max. streams) to achieve a higher polyphony and reduce the potential 
requirement for voice stealing. You can easily play around with that i.e. from 
QSampler's settings dialog.

CU
Christian

Re: [Linuxsampler-devel] Cracks and xruns in audio

[Thomas H. <tho...@gm...>]

Hi all,

Please let me know if there's a better place to be sending these messages...


I think I've identified the problems a bit more clearly now:

0.0025 ms isn't a long enough fadout to prevent an audible click in some
cases, yet it is also too long to fit within a realtime buffer size. To
prevent the clicks ruining a performance, the fadeout time for voice
stealing needs to be quite a lot higher than the period size. Maybe around
20ms to be on the safe side?

The maximum number of audio streams should never be reached, as voice
stealing should keep the number of audio streams to a sane level. But if
enough notes are played in too short a time to release within 20ms, maybe a
fadeout based on the period size should be used as a last resort?

I also notice that “Least buffer fill stream usage” in Qsampler exceeds 50%
fairly often, the linuxsampler process never takes up more than 10 CPU.
Maybe there's some internal limit on how much processing linuxsampler gets,
which could be removed?


I'll try to make some example recordings of when errors occur soon, to make
this a bit clearer. I'm also happy to sponsor these issues if fixes are
manageable. My setup is glitchy at the moment, but apart from that it
sounds amazing.

(~: Tom

On 25 January 2018 at 14:46, Thomas Howe <tho...@gm...> wrote:

> Update:
>
>
> I have found that setting the maximum number of voices to 1 seems to
> eradicate the xruns completely! I hope this will be true for some higher
> numbers of voices too. It was previously set to something like 60.
>
>
> The non-xrun clicks are still present, every time I play a note before
> another has died (including release time I think). I also get this error
> message in Qsampler:
>
> EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current audio
> fragment size & sampling rate! May lead to click sounds if voice stealing
> chimes in!
>
>
> Which suggests my period size of 64 samples at 96kHz (0.67ms) is too low.
> So I will look into decreasing CONFIG_EG_MIN_RELEASE_TIME and report back
> when I find out how to. Any hints would be appreciated.
>
>
>
> I think, if this works, then to stress test my setup properly I would need
> some way to verify that the non-xrun clicks are really gone. Like some kind
> of LinuxSampler click counter. Is there a way to do this?
>
>
> On a side note, is there a way to run LinuxSampler in non-realtime mode,
> so that very polyphonic pieces or possibly even Black MIDI could be
> rendered?
>
>
>
> Please let me know if there's a better place to post this.
>
>
>
> (~: Tom
>
>
> On 24 January 2018 at 00:03, Thomas Howe <tho...@gm...> wrote:
>
>> Hi all, me again...
>>
>> Sometimes LinuxSampler's audio seems to glitch and cause xruns. Xruns
>> aren't registered by patchage and xrun-logger each time.
>>
>> Is this a normal issue? I think it might be related to polyphony (it
>> tends to occur when the sustain pedal is used in fast passages).
>>
>> I would imagine that pitch-shifting a lot of note samples at the same
>> time and then playing them all would be a very intensive task and likely to
>> cause audio glitches, but the processors don't max out or anything.
>>
>> Attached is a MIDI file (Liszt's 2nd Sonata in B Minor) which when played
>> with the SalamanderGrandPianoV3Retuned instrument, gives me a lot of audio
>> glitches.
>>
>> Also I'm using JACK2.
>>
>> Any advice still appreciated (:
>>
>> Tom
>>
>
>

Re: [Linuxsampler-devel] Cracks and xruns in audio

[Thomas H. <tho...@gm...>]

Update:


I have found that setting the maximum number of voices to 1 seems to
eradicate the xruns completely! I hope this will be true for some higher
numbers of voices too. It was previously set to something like 60.


The non-xrun clicks are still present, every time I play a note before
another has died (including release time I think). I also get this error
message in Qsampler:

EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current audio
fragment size & sampling rate! May lead to click sounds if voice stealing
chimes in!


Which suggests my period size of 64 samples at 96kHz (0.67ms) is too low.
So I will look into decreasing CONFIG_EG_MIN_RELEASE_TIME and report back
when I find out how to. Any hints would be appreciated.



I think, if this works, then to stress test my setup properly I would need
some way to verify that the non-xrun clicks are really gone. Like some kind
of LinuxSampler click counter. Is there a way to do this?


On a side note, is there a way to run LinuxSampler in non-realtime mode, so
that very polyphonic pieces or possibly even Black MIDI could be rendered?



Please let me know if there's a better place to post this.



(~: Tom


On 24 January 2018 at 00:03, Thomas Howe <tho...@gm...> wrote:

> Hi all, me again...
>
> Sometimes LinuxSampler's audio seems to glitch and cause xruns. Xruns
> aren't registered by patchage and xrun-logger each time.
>
> Is this a normal issue? I think it might be related to polyphony (it tends
> to occur when the sustain pedal is used in fast passages).
>
> I would imagine that pitch-shifting a lot of note samples at the same time
> and then playing them all would be a very intensive task and likely to
> cause audio glitches, but the processors don't max out or anything.
>
> Attached is a MIDI file (Liszt's 2nd Sonata in B Minor) which when played
> with the SalamanderGrandPianoV3Retuned instrument, gives me a lot of audio
> glitches.
>
> Also I'm using JACK2.
>
> Any advice still appreciated (:
>
> Tom
>

[Linuxsampler-devel] Cracks and xruns in audio

[Thomas H. <tho...@gm...>]

Hi all, me again...

Sometimes LinuxSampler's audio seems to glitch and cause xruns. Xruns
aren't registered by patchage and xrun-logger each time.

Is this a normal issue? I think it might be related to polyphony (it tends
to occur when the sustain pedal is used in fast passages).

I would imagine that pitch-shifting a lot of note samples at the same time
and then playing them all would be a very intensive task and likely to
cause audio glitches, but the processors don't max out or anything.

Attached is a MIDI file (Liszt's 2nd Sonata in B Minor) which when played
with the SalamanderGrandPianoV3Retuned instrument, gives me a lot of audio
glitches.

Also I'm using JACK2.

Any advice still appreciated (:

Tom

[Linuxsampler-devel] Fwd: LinuxSampler doesn't see gigedit

[Thomas H. <tho...@gm...>]

Hi all,

I've installed linuxsampler and gigedit on Arch, but qsampler won't open
gigedit when I click ‘Edit’:

Channel 0

Could not launch an appropriate instrument editor for the given instrument!

Make sure you have an appropriate instrument editor like 'gigedit'
installed and that it placed its mandatory DLL file into the sampler's
plugin directory.
/usr/lib/linuxsampler/plugins/ is empty, and copying the files from
/usr/lib/gigedit/ there doesn't make a difference.

Any advice appreciated (:

Tom

[Linuxsampler-devel] [ANN] QSampler 0.5.0, liblscp 0.6.0 - An Autumn'17 Release

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

Greetings!

On the tail but still fresh LinuxSampler 2.1.0 [2] release...

  Qsampler 0.5.0, liblscp 0.6.0 (autumn'17) released!

Qsampler [1] is a LinuxSampler [2] GUI front-end application written in
C++ around the Qt framework using Qt Designer [3].

Website:
  http://qsampler.sourceforge.net
  https://qsampler.sourceforge.io

Project page:
  http://sourceforge.net/projects/qsampler

Downloads:
  http://sourceforge.net/projects/qsampler/files
- source tarballs:
  http://download.sf.net/qsampler/qsampler-0.5.0.tar.gz
  http://download.sf.net/qsampler/liblscp-0.6.0.tar.gz
- source packages:
  http://download.sf.net/qsampler/qsampler-0.5.0-24.rncbc.suse.src.rpm
  http://download.sf.net/qsampler/liblscp-0.6.0-24.rncbc.suse.src.rpm
- binary packages:
  http://download.sf.net/qsampler/qsampler-0.5.0-24.rncbc.suse.i586.rpm
  http://download.sf.net/qsampler/liblscp6-0.6.0-24.rncbc.suse.i586.rpm
  http://download.sf.net/qsampler/liblscp-devel-0.6.0-24.rncbc.suse.i586.rpm
  http://download.sf.net/qsampler/qsampler-0.5.0-24.rncbc.suse.x86_64.rpm
  http://download.sf.net/qsampler/liblscp6-0.6.0-24.rncbc.suse.x86_64.rpm

http://download.sf.net/qsampler/liblscp-devel-0.6.0-24.rncbc.suse.x86_64.rpm
- AppImage [6] packages:
  http://download.sf.net/qsampler/qsampler-0.5.0-1.x86_64.AppImage

Git repos:
  http://git.code.sf.net/p/qsampler/code
  https://github.com/rncbc/qsampler.git
  https://gitlab.com/rncbc/qsampler.git
  https://bitbucket.com/rncbc/qsampler.git

Change-log:
- French (fr) translation added by Olivier Humbert (qsampler_fr.ts).
- Desktop entry specification file is now finally independent from
build/configure template chains.
- Updated target path for freedesktop.org's AppStream metainfo file
(formerly AppData).

License:
Qsampler [1] is free, open-source Linux Audio [4] software, distributed
under the terms of the GNU General Public License (GPL [5]) version 2 or
later.

References:

 [1] Qsampler - A LinuxSampler Qt GUI Interface
     http://qsampler.sourceforge.net

 [2] LinuxSampler - The Linux Sampler Project
     A modular, streaming capable, realtime audio sampler
     http://www.linuxsampler.org

 [3] Qt framework, C++ class library and tools for
     cross-platform application and UI development
     http://qt.io/

 [4] Linux Audio consortium of libre software for audio-related work
     http://linuxaudio.org

 [5] GPL - GNU General Public License
     http://www.gnu.org/copyleft/gpl.html

 [6] AppImage, Linux apps that run anywhere
     http://appimage.org/


Enjoy && keep the fun!
-- 
rncbc aka. Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] linuxsampler 2.10 fails to compile in ubuntu studio 2.10

[Paul C. <pau...@gm...>]

Hi all,
I'm having trouble compiling the linuxsampler project. libgig is already
installed. There is a similar error when compiling from the tar release(
www.linuxsampler.org/downloads.html) and from the svn repository. Here is
the error message from make on the tar version:

lscp.y: In function ‘bool _isRuleTerminalSymbol(int)’:
lscp.y:1386:18: error: ‘yyprhs’ was not declared in this scope
     for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i)
                  ^~~~~~
lscp.y:1386:18: note: suggested alternative: ‘yyr2’
     for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i)
                  ^~~~~~
                  yyr2
lscp.y:1386:32: error: ‘yyrhs’ was not declared in this scope
     for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i)
                                ^~~~~
lscp.y:1386:32: note: suggested alternative: ‘yyr2’
     for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i)
                                ^~~~~
                                yyr2
Makefile:448: recipe for target 'lscpparser.lo' failed
make[3]: *** [lscpparser.lo] Error 1
make[3]: Leaving directory
'/home/paul/source/linuxsampler-2.1.0/src/network'
Makefile:689: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/paul/source/linuxsampler-2.1.0/src'
Makefile:509: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/paul/source/linuxsampler-2.1.0'
Makefile:414: recipe for target 'all' failed
make: *** [all] Error 2

I installed all dependencies, configure script ran fine. Is this something
I did? Thanks for the help,
Paul

Re: [Linuxsampler-devel] Can't Launch Linux Sampler in Windows 10

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

On Sonntag, 3. Dezember 2017 21:29:51 CET Chris Pugh wrote:
> On 3 December 2017 at 05:21, Andreas Persson <and...@ou...> wrote:
> > Thanks for the report. We forgot to update the Windows installer after
> > the 2.1.0 release. It should be fixed now, in the "20171203" version.
> 
> Worth removing 'linuxsampler_20171201_setup.exe from download list?

I marked the affected binaries as not working and updated parent dir's offical 
release installer and README file.

CU
Christian

Re: [Linuxsampler-devel] Can't Launch Linux Sampler in Windows 10

[Chris P. <gli...@gm...>]

On 3 December 2017 at 05:21, Andreas Persson <and...@ou...> wrote:
> Thanks for the report. We forgot to update the Windows installer after
> the 2.1.0 release. It should be fixed now, in the "20171203" version.

Worth removing 'linuxsampler_20171201_setup.exe from download list?

Chris.