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

Re: [Linuxsampler-devel] SFZ engine Polyphony Opcodes

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

On Montag, 6. April 2020 17:24:08 CEST joo bian wrote:
>  Thank you Christian for the detailed reply,
> I kept changing the JACK and LS buffer, polyphony, etc, but I am still
> getting the X-Runs. So at this point, I think it's time to go back to your

Not JACK, use ALSA! Like I mentioned before, start with a simple setup by 
using ALSA. If it works for you (without dropouts) with ALSA, go ahead with 
JACK.

If you still get dropouts with ALSA, name the concrete parameters that you 
were using for a) sample rate, b) buffer size, c) max. voices, d) max. streams 
and e) precise sound device being used.

What file format are your samples in (wav, ogg vorbis, flac, ...)?

Have you tried a .gig file instead for comparison?

What about trying to install an OS that is already preconfigured for low 
latency like Ubuntu Studio for instance?

> But from now on, I couldn't figure out what happens on my Arch Linux
> (Manjaro 18). I saved the file but after compiling, it seems it is
> compiling it with "-o2" optimization. 

That's OK. It is probably not the root of your problem there. -O in general 
means optimization and the number after it means the level of optimization 
where 3 is usually the maximum optimization level.

CU
Christian

Re: [Linuxsampler-devel] SFZ engine Polyphony Opcodes

[joo b. <joo...@ya...>]

 Thank you Christian for the detailed reply,
I kept changing the JACK and LS buffer, polyphony, etc, but I am still getting the X-Runs. So at this point, I think it's time to go back to your previous comment whether LinuxSampler was compiled with optimization flag turned on. I had never came across the optimization requirement until you mentioned it.
- I checked the building files on AUR for installing LinuxSampler within Pamac. They only apply './configure && make' as the README says. Therefore, if the optimization flag is not turned on by default (which I think it is not), none of them is built with optimization. 

Optimizing LinuxSampler installation------------------------------------------------
- I googled about optimizing LinuxSampler and I landed on a document for compiling for Debian http://www.linuxsampler.org/debian.html#build_backend. 

I edited the "./debian/rules" file and added the arguments relevant to my machine:
"CXXFLAGS="-O3 -march=x86-64 -mtune=native -msse -march=x86-64 -mfpmath=sse -ffast-math -fomit-frame-pointer -funroll-loops" ./configure " ./configure --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info"

But from now on, I couldn't figure out what happens on my Arch Linux (Manjaro 18). I saved the file but after compiling, it seems it is compiling it with "-o2" optimization. I can't figure it out how to make the compilation take these changes into account. I also noticed that in the "./debian/rules" file, there are two occasions where the CXXFLAGS are mentioned, one under "configure-stamp" and the other under "clean:" sections. The file does not give a hint how to progress here. 
Could you please help me get this setting to run for compiling LS?
Disk streams usage----------------------------------
As a general question, if I have 32GB of DDR4 2133 RAM which is much faster than my M2.0 SSD. I wish to dedicate all of this RAM (as long as my computer is functioning)  to LinuxSampler. Is this something recommended by you? I am preparing my instrument for playing live on stage and this is why I am trying to push the limits as much as possible. 
Would it be alright to load the entire sample library in RAM, if I have enough RAM to do so? And would that help me to optimize the performance for very rapid melodies with sustain pedal on? My understanding was that it is preferable to make use of the RAM as much as possible, which is why I invested in hardware with capacity of 32GB of RAM... 

Thank you again for your time



| 
| 
|  | 
LinuxSampler for Debian


 |

 |

 |







    On Saturday, April 4, 2020, 12:52:18 PM GMT+2, Christian Schoenebeck <sch...@li...> wrote:  
 
 On Freitag, 3. April 2020 20:23:00 CEST joo bian wrote:
>  Thank you Christian,
> You pointed out several things. I will focus in this reply on disc stream
> and polyphony in the LinuxSampler setting and will touch on the other, when
> I am sure I am getting the settings right.
> 
> So I use Arch linux because I can install LinuxSampler (stable and svn
> releases) from Pamac. I recently switched to SVN development releases and I
> am currently using the SVN version (r3751-1) from <AUR (en) -
> linuxsampler-svn>. That said, I did not compile LinuxSampler with any
> additional argument. Everything should have been the default installation.

You can certainly check whether you see -O3 in the output while the sampler is 
compiling. The sampler must be compiled with optimization turned on, which 
only happens if the compiler flags (which you see on the console) include
"-O3".

> I also note that I only use the SFZ engine.
> 
> Based on what you wrote, it seems I should not really mention my Hardware
> (for reference: I am using Linux Manjaro 18 with a 3500mb/s M2.0 ssd, 16GB
> Ram, RME soundcard, and 2.2 Ghz quadcore CPU.
> 
> I get xruns when playing intricate piano solos with sustain pedal down when
> I reach the polyphony limit (I believe). I never get x-runs with simpler
> piano solos. The SFZ pianos I am developing for SFZ have multiple sounds
> per key so I reach the limit much faster than basic piano sound libraries.

It would make sense to start with a simple setup first, i.e. start by using 
ALSA as audio output instead of JACK.

Another important thing is the actual latency setting (i.e. buffer size 
setting). Start with higher latencies first (e.g. 50ms), and if you don't get 
dropouts, lower the latency setting step by step.

If you are running with an extreme low latency setting of e.g. <1ms then it is 
not as simple as buying the most powerful and most expensive hardware on the 
market, you also have to tweak the system to actually being able to deliver 
within that small time frame (at least on Linux). Keep in mind Linux' default 
environment were servers, and many default settings are hence not suitable for 
low latency / a.k.a. realtime applications by default.

> 
>  X-Runs
> ======
> I have tried to figure out why these x-runs happen. Interestingly, the disk
> streams do not seem to have any role on my x-runs. I get the X-runs
> "frequently" with the default settings of "64" polyphony and "90" disk
> streams. 

As a rule of thumb: the most important setting here is the max. voices, which 
you have to balance accordingly with your audio driver's buffer size (latency 
setting).

For the amount of max. streams setting you would usually simply always choose 
a value approximately 30% higher than your max. voices setting.

> The only way I could completely avoid x-runs is to reduce the
> polyphony to 48 voices. Anything above this number would cause me x-runs. I
> get the x-runs with higher disk streams (as high as 9000 and as low as 64
> streams).  If I understand it correctly, disk streams load more data on the
> Ram? I see that because when I increase the disk stream LinuxSampler begins
> to take much more Ram in the system. But I am not sure what is actually
> happening. 

Disk streaming is used to read as much sample data as possible in real-time 
from the underlying HD/SSD on demand. Without disk streaming, entire sample 
data would need to be preloaded into RAM. So without disk streaming, if you'd 
load a sample library being 20 GB in size, you would accordingly need >20 GB 
RAM just for loading the sound. With disk streaming enable, only a small 
portion of the sample data needs to be preloaded into RAM, the rest is 
directly read from disk whenever required.

By increasing the max. streams setting, RAM usage will increase, yes, because 
each disk stream uses a buffer (in RAM) which is used for reading sample data 
from disk, while the voice is reading from the other end of that buffer.

> In anyway, unfortunately, 48 voice polyphony is relatively low
> for a complex instrument where each key has several layers of voices.
> 
> I am not quite sure what is going on. I have a real-time kernel, JACK2 runs
> without a problem in real-time, and I even tried running LinuxSampler with
> real-time priority but basically nothing could help with x-runs but
> reducing polyphony.

Well, depends on what you mean with "JACK2 runs without a problem". Obviously 
you get xruns when system load increases. So the question is whether your JACK 
use cases so far ever involved high system loads.

CU
Christian




_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
  

[Linuxsampler-devel] Thread changes

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

Hi guys,

I've been working on fixing some dead locks that were occurring once in a 
while. The problem was that threads were restarted while holding mutex 
lock(s), which inevitably leads to dead locks even if the thread resumes later 
on.

To address this, I changed the way all thread loops work in LS, which 
basically is now:

int SomeThread::Main() {
	while (true) {
		// custom & safe cancellation point for thread
		TestCancel();

		// prevent thread from being cancelled
		// (e.g. to prevent deadlocks while holding a mutex lock)
		pushCanelable(false);

		// enter critical section involving locks and syscalls, e.g.:
		mutex.Lock();
		doSomeWork();
		usleep(100); //NOTE: defined as cancellation point by POSIX!
		mutex.Unlock();

		// now allow thread being cancelled again
		popCancelable();
	}
}

So threads use now "well defined", safe cancellation points. Accordingly the 
code base now relies on pthread_testcancel() being available, and if it is 
avilable then threads are no longer created as being asynchronously 
cancellable.

Since this meant quite a bunch of sensible changes, please let me know if 
things start to hang somewhere!

CU
Christian

Re: [Linuxsampler-devel] SFZ engine Polyphony Opcodes

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

On Freitag, 3. April 2020 20:23:00 CEST joo bian wrote:
>  Thank you Christian,
> You pointed out several things. I will focus in this reply on disc stream
> and polyphony in the LinuxSampler setting and will touch on the other, when
> I am sure I am getting the settings right.
> 
> So I use Arch linux because I can install LinuxSampler (stable and svn
> releases) from Pamac. I recently switched to SVN development releases and I
> am currently using the SVN version (r3751-1) from <AUR (en) -
> linuxsampler-svn>. That said, I did not compile LinuxSampler with any
> additional argument. Everything should have been the default installation.

You can certainly check whether you see -O3 in the output while the sampler is 
compiling. The sampler must be compiled with optimization turned on, which 
only happens if the compiler flags (which you see on the console) include
"-O3".

> I also note that I only use the SFZ engine.
> 
> Based on what you wrote, it seems I should not really mention my Hardware
> (for reference: I am using Linux Manjaro 18 with a 3500mb/s M2.0 ssd, 16GB
> Ram, RME soundcard, and 2.2 Ghz quadcore CPU.
> 
> I get xruns when playing intricate piano solos with sustain pedal down when
> I reach the polyphony limit (I believe). I never get x-runs with simpler
> piano solos. The SFZ pianos I am developing for SFZ have multiple sounds
> per key so I reach the limit much faster than basic piano sound libraries.

It would make sense to start with a simple setup first, i.e. start by using 
ALSA as audio output instead of JACK.

Another important thing is the actual latency setting (i.e. buffer size 
setting). Start with higher latencies first (e.g. 50ms), and if you don't get 
dropouts, lower the latency setting step by step.

If you are running with an extreme low latency setting of e.g. <1ms then it is 
not as simple as buying the most powerful and most expensive hardware on the 
market, you also have to tweak the system to actually being able to deliver 
within that small time frame (at least on Linux). Keep in mind Linux' default 
environment were servers, and many default settings are hence not suitable for 
low latency / a.k.a. realtime applications by default.

> 
>  X-Runs
> ======
> I have tried to figure out why these x-runs happen. Interestingly, the disk
> streams do not seem to have any role on my x-runs. I get the X-runs
> "frequently" with the default settings of "64" polyphony and "90" disk
> streams. 

As a rule of thumb: the most important setting here is the max. voices, which 
you have to balance accordingly with your audio driver's buffer size (latency 
setting).

For the amount of max. streams setting you would usually simply always choose 
a value approximately 30% higher than your max. voices setting.

> The only way I could completely avoid x-runs is to reduce the
> polyphony to 48 voices. Anything above this number would cause me x-runs. I
> get the x-runs with higher disk streams (as high as 9000 and as low as 64
> streams).  If I understand it correctly, disk streams load more data on the
> Ram? I see that because when I increase the disk stream LinuxSampler begins
> to take much more Ram in the system. But I am not sure what is actually
> happening. 

Disk streaming is used to read as much sample data as possible in real-time 
from the underlying HD/SSD on demand. Without disk streaming, entire sample 
data would need to be preloaded into RAM. So without disk streaming, if you'd 
load a sample library being 20 GB in size, you would accordingly need >20 GB 
RAM just for loading the sound. With disk streaming enable, only a small 
portion of the sample data needs to be preloaded into RAM, the rest is 
directly read from disk whenever required.

By increasing the max. streams setting, RAM usage will increase, yes, because 
each disk stream uses a buffer (in RAM) which is used for reading sample data 
from disk, while the voice is reading from the other end of that buffer.

> In anyway, unfortunately, 48 voice polyphony is relatively low
> for a complex instrument where each key has several layers of voices.
> 
> I am not quite sure what is going on. I have a real-time kernel, JACK2 runs
> without a problem in real-time, and I even tried running LinuxSampler with
> real-time priority but basically nothing could help with x-runs but
> reducing polyphony.

Well, depends on what you mean with "JACK2 runs without a problem". Obviously 
you get xruns when system load increases. So the question is whether your JACK 
use cases so far ever involved high system loads.

CU
Christian

Re: [Linuxsampler-devel] SFZ engine Polyphony Opcodes

[joo b. <joo...@ya...>]

 Thank you Christian,
You pointed out several things. I will focus in this reply on disc stream and polyphony in the LinuxSampler setting and will touch on the other, when I am sure I am getting the settings right. 

So I use Arch linux because I can install LinuxSampler (stable and svn releases) from Pamac. I recently switched to SVN development releases and I am currently using the SVN version (r3751-1) from <AUR (en) - linuxsampler-svn>. That said, I did not compile LinuxSampler with any additional argument. Everything should have been the default installation. I also note that I only use the SFZ engine. 

Based on what you wrote, it seems I should not really mention my Hardware (for reference: I am using Linux Manjaro 18 with a 3500mb/s M2.0 ssd, 16GB Ram, RME soundcard, and 2.2 Ghz quadcore CPU. 

I get xruns when playing intricate piano solos with sustain pedal down when I reach the polyphony limit (I believe). I never get x-runs with simpler piano solos. The SFZ pianos I am developing for SFZ have multiple sounds per key so I reach the limit much faster than basic piano sound libraries. 

 X-Runs 
======
I have tried to figure out why these x-runs happen. Interestingly, the disk streams do not seem to have any role on my x-runs. I get the X-runs "frequently" with the default settings of "64" polyphony and "90" disk streams. The only way I could completely avoid x-runs is to reduce the polyphony to 48 voices. Anything above this number would cause me x-runs. I get the x-runs with higher disk streams (as high as 9000 and as low as 64 streams).  If I understand it correctly, disk streams load more data on the Ram? I see that because when I increase the disk stream LinuxSampler begins to take much more Ram in the system. But I am not sure what is actually happening. In anyway, unfortunately, 48 voice polyphony is relatively low for a complex instrument where each key has several layers of voices. 

I am not quite sure what is going on. I have a real-time kernel, JACK2 runs without a problem in real-time, and I even tried running LinuxSampler with real-time priority but basically nothing could help with x-runs but reducing polyphony. 

Any idea?
Cheers,
Ebad

    On Wednesday, April 1, 2020, 11:29:44 AM GMT+2, Christian Schoenebeck <sch...@li...> wrote:  
 
 On Dienstag, 31. März 2020 18:16:38 CEST joo bian wrote:
> The main problem with lacking note_polyphony is that playing a 3-voice chord
> repeatedly with a sustain pedal down is enough to bump into severe XRuns,
> even on my studio computer and RME soundcard. There is no way to avoid the
> XRuns for such a playing if the note_polyphony is not implemented... 

Which makes me wonder whether you are mixing here sound design aspects with 
what looks like a fundamental issue with your installation there. I mean it is 
not normal that you encounter any xruns by just playing a piano with LS, even 
not with a 20 year old hardware and $5 built-in sound chip. As soon as you hit 
the current polyphony limit setting the sampler's voice stealing kicks in to 
prevent any xruns.

Are you overriding the default setting for max. polyphony and max. disk 
streams? If yes, what values have you picked?

Did you compile LS with optimization turned on (i.e. with compiler flag -O3)?

> I wonder if anyone has written a NKSP program to tackle note polyphony?

Well you could also release notes by NKSP script of course, sure, with any 
customized logic you might think of. Such a script would just need like 6 
lines of NKSP code, so it should not be a big deal for you to try out.

However as mentioned, it looks like you rather have a problem with your LS 
installation there.

> Or if there is a plan to implement it?

At least not on my side. Usually new feature appear only when people decide to 
implement them by themselves and providing a patch for their changes.

CU
Christian




_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel  

Re: [Linuxsampler-devel] SFZ engine Polyphony Opcodes

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

On Dienstag, 31. März 2020 18:16:38 CEST joo bian wrote:
> The main problem with lacking note_polyphony is that playing a 3-voice chord
> repeatedly with a sustain pedal down is enough to bump into severe XRuns,
> even on my studio computer and RME soundcard. There is no way to avoid the
> XRuns for such a playing if the note_polyphony is not implemented... 

Which makes me wonder whether you are mixing here sound design aspects with 
what looks like a fundamental issue with your installation there. I mean it is 
not normal that you encounter any xruns by just playing a piano with LS, even 
not with a 20 year old hardware and $5 built-in sound chip. As soon as you hit 
the current polyphony limit setting the sampler's voice stealing kicks in to 
prevent any xruns.

Are you overriding the default setting for max. polyphony and max. disk 
streams? If yes, what values have you picked?

Did you compile LS with optimization turned on (i.e. with compiler flag -O3)?

> I wonder if anyone has written a NKSP program to tackle note polyphony?

Well you could also release notes by NKSP script of course, sure, with any 
customized logic you might think of. Such a script would just need like 6 
lines of NKSP code, so it should not be a big deal for you to try out.

However as mentioned, it looks like you rather have a problem with your LS 
installation there.

> Or if there is a plan to implement it?

At least not on my side. Usually new feature appear only when people decide to 
implement them by themselves and providing a patch for their changes.

CU
Christian

[Linuxsampler-devel] SFZ engine Polyphony Opcodes

[joo b. <joo...@ya...>]

Dear All,
So far, it seems the SFZ engine is not supporting any Opcode for polyphony, note polyphony, or self masking.  This has been coming up in the mailing list every now and then, but yet the Opcodes are unsupported. 

The main problem with lacking note_polyphony is that playing a 3-voice chord repeatedly with a sustain pedal down is enough to bump into severe XRuns, even on my studio computer and RME soundcard. There is no way to avoid the XRuns for such a playing if the note_polyphony is not implemented... I wonder if anyone has written a NKSP program to tackle note polyphony? Or if there is a plan to implement it?

I know that some might suggest using "off_by" Opcode, but that is really not a working solution when my Piano sample has 30 layers of velocity and I cannot meaningfully turn some groups off... 

Cheers (and be safe!)

Ebad

[Linuxsampler-devel] [ANN] A QStuff* Spring'20 Release batch #1

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

Greetings

The first batch of the so called 'QStuff*', QjackCtl [1], Qsynth
[2], Qsampler [3], QXGEdit [4], QmidiCtl [5] and QmidiNet [6], are all
moving up a notch to **version 0.6.2** on this early Spring'20 (and
under quarentine).

Time to stay and still have fun at home, nevertheless ;)


** QjackCtl - JACK Audio Connection Kit Qt GUI Interface [1] **

  QjackCtl 0.6.2 (spring'20) released!

QjackCtl is a(n ageing yet modern, not so 'simple' anymore) Qt [7]
application to control the JACK [8] sound server, for the Linux Audio
[12] infrastructure.

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

Project page:
  https://sourceforge.net/projects/qjackctl

Downloads:
  https://sourceforge.net/projects/qjackctl/files
- source tarball:
  https://download.sf.net/qjackctl/qjackctl-0.6.2.tar.gz
- source package:
  https://download.sf.net/qjackctl/qjackctl-0.6.2-42.rncbc.suse.src.rpm
- binary package:
  https://download.sf.net/qjackctl/qjackctl-0.6.2-42.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  https://download.sf.net/qjackctl/qjackctl-0.6.2-42.x86_64.AppImage

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

Change-log:
- A scalable (.svg) icon version has been added.
- Make man page compression reproducible (after request by Jelle van der
Waa, while on the Vee-Ones, thanks).
- Ditching deprecated QTime methods for QElapsedTimer's (in compliance
to Qt >= 5.14.0).
- Bumped copyright headers into the New Year (2020).


** Qsynth - A fluidsynth Qt GUI Interface [2] **

  Qsynth 0.6.2 (spring'20) released!

Qsynth is a FluidSynth [10] GUI front-end application written in C++
around the Qt framework [7] using Qt Designer.

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

Project page:
  https://sourceforge.net/projects/qsynth

Downloads:
  https://sourceforge.net/projects/qsynth/files
- source tarball:
  https://download.sf.net/qsynth/qsynth-0.6.2.tar.gz
- source package:
  https://download.sf.net/qsynth/qsynth-0.6.2-42.rncbc.suse.src.rpm
- binary package:
  https://download.sf.net/qsynth/qsynth-0.6.2-42.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  https://download.sf.net/qsynth/qsynth-0.6.2-42.x86_64.AppImage

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

Change-log:
- A scalable (.svg) icon version has been added.
- Make man page compression reproducible (after request by Jelle van der
Waa, while on the Vee-Ones, thanks).
- Ditching deprecated QTime methods for QElapsedTimer's (in compliance
to Qt >= 5.14.0).
- Bumped copyright headers into the New Year (2020).


** Qsampler - A LinuxSampler Qt GUI Interface [3] **

  Qsampler 0.6.2 (spring'20) released!

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

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

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

Downloads:
  https://sourceforge.net/projects/qsampler/files
- source tarballs:
  https://download.sf.net/qsampler/qsampler-0.6.2.tar.gz
- source package:
  https://download.sf.net/qsampler/qsampler-0.6.2-42.rncbc.suse.src.rpm
- binary package:
  https://download.sf.net/qsampler/qsampler-0.6.2-42.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  https://download.sf.net/qsampler/qsampler-0.6.2-42.x86_64.AppImage

Git repos:
  https://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:
- Make man page compression reproducible (after request by Jelle van der
Waa, while on the Vee-Ones, thanks).
- Ditching deprecated QTime methods for QElapsedTimer's (in compliance
to Qt >= 5.14.0).
- If connection to server aborted, try to automatically reconnect (if
server was not started by QSampler).
- Fixed crash when a device disappeared on server side (caused by
iterator invalidation).
- Bumped copyright headers into the New Year (2020).


** QXGEdit - A Qt XG Editor [4] **

  QXGEdit 0.6.2 (spring'20) released!

QXGEdit is a live XG instrument editor, specialized on editing MIDI
System Exclusive files (.syx) for the Yamaha DB50XG [14] and thus
probably a baseline for many other XG devices.

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

Project page:
  https://sourceforge.net/projects/qxgedit

Downloads:
  https://sourceforge.net/projects/qxgedit/files
- source tarball:
  https://download.sf.net/qxgedit/qxgedit-0.6.2.tar.gz
- source package:
  https://download.sf.net/qxgedit/qxgedit-0.6.2-32.rncbc.suse.src.rpm
- binary package:
  https://download.sf.net/qxgedit/qxgedit-0.6.2-32.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  https://download.sf.net/qxgedit/qxgedit-0.6.2-32.x86_64.AppImage

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

Change-log:
- A scalable (.svg) icon version has been added.
- Make man page compression reproducible (after request by Jelle van der
Waa, while on the Vee-Ones, thanks).
- Bumped copyright headers into the New Year (2020).


** QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast [5] **

  QmidiCtl 0.6.2 (spring'20) released!

QmidiCtl [5] is a MIDI remote controller application that sends MIDI
data over the network, using UDP/IP multicast. Inspired by multimidicast
[15] and designed to be compatible with ipMIDI [15] for Windows.
QmidiCtl [5] was long ago designed for the Maemo [17] enabled handheld
devices, namely the late Nokia N900 [18] and promoted to the Maemo
Package [18] repositories. Nevertheless, QmidiCtl [5] may still be found
effective as a regular desktop application and recently as an Android
application as well.

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

Project page:
  https://sourceforge.net/projects/qmidictl

Downloads:
  https://sourceforge.net/projects/qmidictl/files
- source tarball:
  https://download.sf.net/qmidictl/qmidictl-0.6.2.tar.gz
- source package:
  https://download.sf.net/qmidictl/qmidictl-0.6.2-22.rncbc.suse.src.rpm
- binary package:
  https://download.sf.net/qmidictl/qmidictl-0.6.2-22.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  https://download.sf.net/qmidictl/qmidictl-0.6.2-22.x86_64.AppImage
- Android packages:
  https://download.sf.net/qmidictl/qmidictl-0.6.2-22.apk
  https://download.sf.net/qmidictl/qmidictl-0.6.2-22.aab
  https://play.google.com/store/apps/details?id=org.rncbc.qmidictl

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

Change-log:
- A scalable (.svg) icon version has been added.
- Make man page compression reproducible (after request by Jelle van der
Waa, while on the Vee-Ones, thanks).
- Updated to build Android App Bundles (Qt >= 5.14.0).
- Avoid some touch-events while tracking a swipe gesture.
- Bumped copyright headers into the New Year (2020).


** QmidiNet - A MIDI Network Gateway via UDP/IP Multicast [6] **

  QmidiNet 0.6.2 (spring'20) released!

QmidiNet is a MIDI network gateway application that sends and receives
MIDI data (ALSA-MIDI [9] and JACK-MIDI [8]) over the network, using
UDP/IP multicast. Inspired by multimidicast [15] and designed to be
compatible with ipMIDI [16] for Windows.

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

Project page:
  https://sourceforge.net/projects/qmidinet

Downloads:
  https://sourceforge.net/projects/qmidinet/files
- source tarball:
  https://download.sf.net/qmidinet/qmidinet-0.6.2.tar.gz
- source package:
  https://download.sf.net/qmidinet/qmidinet-0.6.2-22.rncbc.suse.src.rpm
- binary package:
  https://download.sf.net/qmidinet/qmidinet-0.6.2-22.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  https://download.sf.net/qmidinet/qmidinet-0.6.2-22.x86_64.AppImage

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

Change-log:
- A scalable (.svg) icon version has been added.
- Make man page compression reproducible (after request by Jelle van der
Waa, while on the Vee-Ones, thanks).
- Bumped copyright headers into the New Year (2020).


License:
  All of the Qstuff* are free, open-source Linux Audio [11] software,
distributed under the terms of the GNU General Public License (GPL)
version 2 or later [12].


References:

 [1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface
     https://qjackctl.sourceforge.io

 [2] Qsynth - A fluidsynth Qt GUI Interface
     https://qsynth.sourceforge.io

 [3] Qsampler - A LinuxSampler Qt GUI Interface
     https://qsampler.sourceforge.io

 [4] QXGEdit - A Qt XG Editor
     https://qxgedit.sourceforge.io

 [5] QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast
     https://qmidictl.sourceforge.io

 [6] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast
     https://qmidinet.sourceforge.io

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

 [8] JACK Audio Connection Kit
     https://jackaudio.org

 [9] ALSA, Advanced Linux Sound Architecture
     https://www.alsa-project.org/

[10] FluidSynth - A SoundFont Synthesizer
     A real-time software synthesizer based on SoundFont 2 specifications
     https://www.fluidsynth.org

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

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

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

[14] Yamaha DB50XG
     http://www.soundonsound.com/sos/1996_articles/may96/yamahadb50xg.html

[15] multimidicast - sends and receives MIDI from ALSA sequencers over
network
     https://llg.cubic.org/tools/multimidicast

[16] ipMIDI - MIDI over Ethernet ports - send MIDI over your LAN
     https://nerds.de

[17] Maemo.org - Home of the Maemo community
     https://www.maemo.org

[18] Maemo.org Wiki - Nokia N900
     https://wiki.maemo.org/Nokia_N900

[19] Maemo.org - Downloads: QmidiCtl
     https://maemo.org/downloads/product/Maemo5/qmidictl

[20] AppImage, Linux apps that run anywhere
     https://appimage.org/


See also:
  https://www.rncbc.org/drupal/node/2075


Enjoy && Stay safe!
--
rncbc aka Rui Nuno Capela

Re: [Linuxsampler-devel] a Bug discovered

[joo b. <joo...@ya...>]

 Dear Christian, Andreas,
I installed the development version and the bug is completely fixed. All regions are played correctly. Thank you very much for your help. 

Cheers,
Ebad

    On Tuesday, March 3, 2020, 5:36:58 PM GMT+1, Christian Schoenebeck <sch...@li...> wrote:  
 
 On Montag, 2. März 2020 23:30:17 CET joo bian via Linuxsampler-devel wrote:
>  Thank you so much Andreas for looking into this. 
> I checked again and well, I have installed version 2.1.1-2, but this is not
> the version you mentioned, is it? For Arch Linux, you find the package
> details here:  https://aur.archlinux.org/packages/linuxsampler-vst
> 
> AUR (en) - linuxsampler-vst
> 
> Where can I get the 2.1.1.svn16? If you could play the correct regions on
> your computer, then probably the update is not included in 2.1.1-2, which
> says it was last updated on  2019-07-31 09:04. Cheers,
> Ebad

That explains why you have that bug there. You are using the last release 
version of LS where Andreas' fix is not included yet.

Check out the latest development version from our Subversion server like 
described here:

http://linuxsampler.org/downloads.html#svn

You need at least to get libgig and linuxsampler this way and recompile those 
two at least to fix your issue.

CU
Christian




_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel  

Re: [Linuxsampler-devel] a Bug discovered

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

On Montag, 2. März 2020 23:30:17 CET joo bian via Linuxsampler-devel wrote:
>  Thank you so much Andreas for looking into this. 
> I checked again and well, I have installed version 2.1.1-2, but this is not
> the version you mentioned, is it? For Arch Linux, you find the package
> details here:  https://aur.archlinux.org/packages/linuxsampler-vst
> 
> AUR (en) - linuxsampler-vst
> 
> Where can I get the 2.1.1.svn16? If you could play the correct regions on
> your computer, then probably the update is not included in 2.1.1-2, which
> says it was last updated on  2019-07-31 09:04. Cheers,
> Ebad

That explains why you have that bug there. You are using the last release 
version of LS where Andreas' fix is not included yet.

Check out the latest development version from our Subversion server like 
described here:

http://linuxsampler.org/downloads.html#svn

You need at least to get libgig and linuxsampler this way and recompile those 
two at least to fix your issue.

CU
Christian

Re: [Linuxsampler-devel] a Bug discovered

[joo b. <joo...@ya...>]

 Thank you so much Andreas for looking into this. 
I checked again and well, I have installed version 2.1.1-2, but this is not the version you mentioned, is it? For Arch Linux, you find the package details here: 
 https://aur.archlinux.org/packages/linuxsampler-vst

|  | 
AUR (en) - linuxsampler-vst
 |


Where can I get the 2.1.1.svn16? If you could play the correct regions on your computer, then probably the update is not included in 2.1.1-2, which says it was last updated on  2019-07-31 09:04.
Cheers,
Ebad




    On Monday, March 2, 2020, 07:49:16 AM GMT+1, Andreas Persson <and...@ou...> wrote:  
 
 joo bian via Linuxsampler-devel wrote:
> 1. bug.sfz which shows the main bug of LinuxSampler that plays the wrong
> region. There are 8 regions defined by categorizing the three pedals
> (CC64, CC66, and CC67) and LinuxSampler entirely fails to distinguish
> the categories when they are included together in a region.

I tried your test file now, and for me it works correctly (the samples
are played just as described in the comments in bug.sfz).

Are you sure you use a linuxsampler version newer than 2.1.1.svn16?

/Andreas


_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
  

Re: [Linuxsampler-devel] a Bug discovered

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

joo bian via Linuxsampler-devel wrote:
> 1. bug.sfz which shows the main bug of LinuxSampler that plays the wrong
> region. There are 8 regions defined by categorizing the three pedals
> (CC64, CC66, and CC67) and LinuxSampler entirely fails to distinguish
> the categories when they are included together in a region.

I tried your test file now, and for me it works correctly (the samples
are played just as described in the comments in bug.sfz).

Are you sure you use a linuxsampler version newer than 2.1.1.svn16?

/Andreas

Re: [Linuxsampler-devel] Some troubling behavior regarding MIDI Control Messages

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

joo bian via Linuxsampler-devel wrote:

> // use this template to reproduce the error
> <region> sample=w.wav locc64=0 locc64=63 locc67=0 locc67=63 ...
> <region> sample=x.wav locc64=0 locc64=63 locc67=64 locc67=127 ...
> <region> sample=y.wav locc64=64 locc64=127 locc67=0 locc67=63 ...
> <region> sample=z.wav locc64=64 locc64=127 locc67=64 locc67=127 ...

> Does this sound like a bug to you too or am I missing something here? I
> would very much appreciate your feedback. 

Hello,

This sounds exactly like the bug I found and thought I fixed 2019-09-02:

"2019-09-02 persson
* SFZ format engine: fixed support for regions with loccN/hiccN
conditions on more than one MIDI controller."

I'll have a look at it.

/Andreas

Re: [Linuxsampler-devel] Build errors for LinuxSampler on Mint 19.2

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

On Dienstag, 25. Februar 2020 23:02:16 CET you wrote:
> Hi Christian and all,
> 
> On Tue, 04 Feb 2020 16:13:02 +0100 you wrote (sorry for the late reply):
> > Designated initializers are actually an invention by the C language, where
> > it is very heavily used by C developers. C++ just adopted this language
> > feature after having it neglected for almost 3 decades.
> > 
> > > Greetings,
> > > Frank (who now actually started discovering nksp :-)
> > 
> > Have you by chance heard about any news on the MIDI 2.0 front? Anybody
> > working on kernel or ALSA support? Looks very promising (e.g.
> > bidirectional communication, feature support negotiation between MIDI
> > devices, setup presets and much more). Official announcement of MIDI 2.0
> > by MMA was on January 27th.
> I'm not aware of any such efforts, but I don't monitor the current
> development of ALSA or most applications very closely.

I see, times changed. :)

> However, just today I saw that the MIDI 2.0 specs are now out, and
> individuals can even get them for free (registration required, though):
> http://www.synthtopia.com/content/2020/02/24/midi-2-0-specs-now-available-fo
> r-download/
> 
> 'thought you might want to know.

Yeah, I've got that as well. I just thought you were still actively involved 
in LAD issues to some extent.

CU
Christian

Re: [Linuxsampler-devel] a Bug discovered

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

On Samstag, 29. Februar 2020 12:56:08 CET joo bian wrote:
> Dear Christian,
> Thank you for your reply.  I did more testing on the problem I reported last
> week and I am certain it is a bug that has been remained unnoticed. I have
> attached a simple SFZ instrument that reproduces the bug. Unfortunately,

Please note that I have not written the sfz code in LinuxSampler, nor am I 
very familiar with all sfz file format details, nor am I actually using the 
sfz engine personally.

If you want to get things forward, please concentrate on one particular issue, 
and strip down an example to the absolutely bare minimum to reproduce what you 
think is a bug. To me your attached sfz files more look like they were 
demonstrating your overall practical use case, not just the actual bug (e.g. 
there are many regions and probably unnecessary opcodes for demonstrating just 
this particular bug).

CU
Christian

[Linuxsampler-devel] a Bug discovered

[joo b. <joo...@ya...>]

Dear Christian,
Thank you for your reply.  I did more testing on the problem I reported last week and I am certain it is a bug that has been remained unnoticed. I have attached a simple SFZ instrument that reproduces the bug. Unfortunately, the bug is extremely serious, avoiding producing complex instruments for LinuxSampler, particularly for high-quality piano instruments... Within the current bug, there is no way to include soft-pedal samples along with sustain samples and sustained-soft samples, because LinuxSampler plays false region samples! 

Here are the list of attached files:
1. bug.sfz which shows the main bug of LinuxSampler that plays the wrong region. There are 8 regions defined by categorizing the three pedals (CC64, CC66, and CC67) and LinuxSampler entirely fails to distinguish the categories when they are included together in a region.

2. on_cc.sfz is not really important, but demonstrates why we cannot use on_loccN for categorizing (see below).3. there are eight tiny wav files, which simply say their number (0 to 7). I gave each category a number with a corresponding audio file to really simplify the bug. I hope it helps.  

The Wav files can be downloaded from my Dropbox and are about 1 mb: instruments.zip

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
instruments.zip

Shared with Dropbox
 |

 |

 |

 


1. Testing CC categorization on other SFZ players I did more testing to make sure this is indeed only happening in LinuxSampler. I tested my bug.sfz instrument on another SFZ player on Linux called liquidsfz and sfizz plugin. In Windows, I tested it with Sforzando and Aria player. All four samplers played the instrument correctly. So I am getting confident that it is a linuxsampler bug.


2. Regarding your comment on using on_loccN:There is a difference between on_loccN/on_hiccN and loccN/hiccN. We use on_loccN for triggering sounds that do not receive a particular notes. For example, if I want to add a pedal release noise sound to be played when a sustain pedal is pressed (which does not have a key number), I will write the code below:
<region> sample=sustainPress.wav on_locc64=64 on_hicc64=127 
This will trigger the noise sound anytime the cc64 is above the threshold, without requiring any key to be pressed. SFZ format defines the alternative loccN/hiccN for regions that require a note to be pressed. I put the documentations below for reference of those who like to read more about the difference:
- on_loccN/on_hiccN- loccN/hiccN





3. Solving the bug
I am willing to help with solving the bug if it requires so much effort. So please let me know how can we go about it and how can I make myself useful.

Cheers,
Ebad

Re: [Linuxsampler-devel] Build errors for LinuxSampler on Mint 19.2

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

Hi Christian and all,

On Tue, 04 Feb 2020 16:13:02 +0100 you wrote (sorry for the late reply):

> Designated initializers are actually an invention by the C language, where it
> is very heavily used by C developers. C++ just adopted this language feature
> after having it neglected for almost 3 decades.
>
> > Greetings,
> > Frank (who now actually started discovering nksp :-)
>
> Have you by chance heard about any news on the MIDI 2.0 front? Anybody working
> on kernel or ALSA support? Looks very promising (e.g. bidirectional
> communication, feature support negotiation between MIDI devices, setup presets
> and much more). Official announcement of MIDI 2.0 by MMA was on January 27th.

I'm not aware of any such efforts, but I don't monitor the current development
of ALSA or most applications very closely.

However, just today I saw that the MIDI 2.0 specs are now out, and individuals
can even get them for free (registration required, though):
http://www.synthtopia.com/content/2020/02/24/midi-2-0-specs-now-available-for-download/

'thought you might want to know.

Greetings,
Frank

Re: [Linuxsampler-devel] Some troubling behavior regarding MIDI Control Messages

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

On Montag, 24. Februar 2020 19:14:35 CET joo bian wrote:
> Dear All,
> I am developing a series of virtual instruments for SFZ v.1  and v.2, which
> are aimed for solo players and thus include many variations of each
> instrument, triggered by different pedals. Recently, I discovered a problem
> in LinuxSampler, which I am positive (but not 100% sure) that it is a bug
> (I am using the latest version of linuxsampler on Arch Linux). The problem
> is visible even within SFZ v.1 instruments. There are CC Opcodes for
> specifying each region to be triggered with particular CC messages. For
> example: // Triggering sustain pedal (CC64) samples: <region> ... locc64=64
> locc64=127 ... // Triggering soft pedal (CC67) samples: <region> ...
> locc67=64 locc67=127 ... However, when these samples are combined to create
> all four possibilities for a well-sampled instrument (i.e. no pedal
> pressed, only sustain pressed, only soft pedal pressed, both pedals are
> pressed), there are false regions triggered. It is needless to say that for
> each of these combinations, I include the full criteria: // use this
> template to reproduce the error<region> sample=w.wav locc64=0
> locc64=63 locc67=0 locc67=63 ... <region> sample=x.wav locc64=0
> locc64=63 locc67=64 locc67=127 ...
> <region> sample=y.wav locc64=64 locc64=127 locc67=0 locc67=63 ...
> <region> sample=z.wav locc64=64 locc64=127 locc67=64 locc67=127 ...
> The same problem also appears if instead of sustain or soft pedals I use the
> sostenuto pedal (e.g locc66=64 hicc66=127). Basically LinuxSampler seems to
> get confused under some of the conditions. I tried to find a workaround by
> defining groups, specifying group numbers and putting off_by opcodes, etc.,
> but the problem remains.  The error only occurs in LinuxSampler and other
> SFZ players that I have tested (so far Sforzando) played the regions
> correctly. Does this sound like a bug to you too or am I missing something
> here? I would very much appreciate your feedback.
> 
> Cheers,
> Ebad

I'm not an sfz format expert, but if you want to trigger samples by MIDI CC 
(not by note-on) then you probably need on_locc# on_hicc# somewhere. I don't 
see that in your examples.

CU
Christian

[Linuxsampler-devel] Some troubling behavior regarding MIDI Control Messages

[joo b. <joo...@ya...>]

Dear All,
I am developing a series of virtual instruments for SFZ v.1  and v.2, which are aimed for solo players and thus include many variations of each instrument, triggered by different pedals. Recently, I discovered a problem in LinuxSampler, which I am positive (but not 100% sure) that it is a bug (I am using the latest version of linuxsampler on Arch Linux).
The problem is visible even within SFZ v.1 instruments. There are CC Opcodes for specifying each region to be triggered with particular CC messages. For example:
// Triggering sustain pedal (CC64) samples: <region> ... locc64=64 locc64=127 ...
// Triggering soft pedal (CC67) samples: <region> ... locc67=64 locc67=127 ...
However, when these samples are combined to create all four possibilities for a well-sampled instrument (i.e. no pedal pressed, only sustain pressed, only soft pedal pressed, both pedals are pressed), there are false regions triggered. It is needless to say that for each of these combinations, I include the full criteria:
// use this template to reproduce the error<region> sample=w.wav locc64=0 locc64=63 locc67=0 locc67=63 ...
<region> sample=x.wav locc64=0 locc64=63 locc67=64 locc67=127 ...
<region> sample=y.wav locc64=64 locc64=127 locc67=0 locc67=63 ...
<region> sample=z.wav locc64=64 locc64=127 locc67=64 locc67=127 ...
The same problem also appears if instead of sustain or soft pedals I use the sostenuto pedal (e.g locc66=64 hicc66=127). Basically LinuxSampler seems to get confused under some of the conditions. I tried to find a workaround by defining groups, specifying group numbers and putting off_by opcodes, etc., but the problem remains. 
The error only occurs in LinuxSampler and other SFZ players that I have tested (so far Sforzando) played the regions correctly. 
Does this sound like a bug to you too or am I missing something here? I would very much appreciate your feedback. 

Cheers,
Ebad

Re: [Linuxsampler-devel] Build errors for LinuxSampler on Mint 19.2

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

On Montag, 3. Februar 2020 20:54:31 CET Frank Neumann wrote:
> Hi Christian,
> 
> > The build requirement has in fact changed after last year's release:
> > http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_1_1/
> 
> [..]
> 
> > Short: either compile with clang (works also with quite old versions of
> > clang) or update to GCC >= 8.x. You can install both clang and gcc
> > without problems.> 
> > If you have both installed, just force LS compilation with clang like this:
> > 	CXX=clang++ CC=clang ./configure && make
> 
> Great, this actually worked; thanks a lot!
> With this (and installing/using clang-6), I was able to build LinuxSampler
> on my laptop (Mint 19.2, Tara), and it runs fine there.
> On the desktop PC I still have build issues, but it's running a much older
> Mint version (18.2 "Sonya", with gcc 5.4.0) which I'll soon update anyway,
> so it's perhaps not worth the time/effort.
> 
> You might still want to add these explanations to LinuxSampler's README.txt;
> I can imagine I am not the only one tripping over this.

Sure, towards next release that will be updated appropriately. In the meantime
I just added a configure check, which should make this clear:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/configure.ac?r1=3739&r2=3738&pathrev=3739

My current assumption is that this issure requires GCC >= 8 or clang >= 5.
I am not fully sure though.

> > Background: The LS code base is now using a lot of so called "designated
> > initializers", probably better described as C-style "named initializers"
> > for
> > semantic critical functions/methods. Instead of this:
> [..]
> 
> Thanks for this insightful&instructional explanation. While I am no C++
> developer, I fully understand your point.

Designated initializers are actually an invention by the C language, where it
is very heavily used by C developers. C++ just adopted this language feature
after having it neglected for almost 3 decades.

> Greetings,
> Frank (who now actually started discovering nksp :-)

Have you by chance heard about any news on the MIDI 2.0 front? Anybody working
on kernel or ALSA support? Looks very promising (e.g. bidirectional
communication, feature support negotiation between MIDI devices, setup presets
and much more). Official announcement of MIDI 2.0 by MMA was on January 27th.

CU
Christian

Re: [Linuxsampler-devel] Build errors for LinuxSampler on Mint 19.2

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

Hi Christian,

> The build requirement has in fact changed after last year's release:
> http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_1_1/

[..]

>
> Short: either compile with clang (works also with quite old versions of clang)
> or update to GCC >= 8.x. You can install both clang and gcc without problems.
> If you have both installed, just force LS compilation with clang like this:
>
> 	CXX=clang++ CC=clang ./configure && make

Great, this actually worked; thanks a lot!
With this (and installing/using clang-6), I was able to build LinuxSampler on
my laptop (Mint 19.2, Tara), and it runs fine there.
On the desktop PC I still have build issues, but it's running a much older Mint
version (18.2 "Sonya", with gcc 5.4.0) which I'll soon update anyway, so it's
perhaps not worth the time/effort.

You might still want to add these explanations to LinuxSampler's README.txt;
I can imagine I am not the only one tripping over this.

>
> Background: The LS code base is now using a lot of so called "designated
> initializers", probably better described as C-style "named initializers" for
> semantic critical functions/methods. Instead of this:

[..]

Thanks for this insightful&instructional explanation. While I am no C++
developer, I fully understand your point.

Greetings,
Frank (who now actually started discovering nksp :-)

Re: [Linuxsampler-devel] Build errors for LinuxSampler on Mint 19.2

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

On Sonntag, 2. Februar 2020 19:54:43 CET Frank Neumann wrote:
> Hi all,

Hi Frank,

> not sure if I overlooked some recent build requirement change, but with
> Linux Mint 19.2 (gcc 7.4.0) I seem to be unable to build current
> LinuxSampler (svn r3734) from source (but thie issue might been in for a
> while already):

The build requirement has in fact changed after last year's release:
http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_1_1/

Like mentioned in those release notes, I've added a bunch of new features 
after that release, which would be hard to maintain without modern C++ 
standard support by the compiler. So current min. requirement is a compiler 
with at least C++14 support. Last year's release even compiled with pre-C++11 
compilers.

> parser.y: In function ‘int InstrScript_parse(LinuxSampler::ParserContext*)’:
> parser.y:311:25: sorry, unimplemented: non-trivial designated initializers
> not supported });
>                          ^
> parser.y:311:25: sorry, unimplemented: non-trivial designated initializers
> not supported parser.y:311:25: sorry, unimplemented: non-trivial designated
> initializers not supported parser.y:311:25: sorry, unimplemented:
> non-trivial designated initializers not supported parser.y:318:26: sorry,
> unimplemented: non-trivial designated initializers not supported });
>                           ^
> 
> There is a whole bunch more of these "sorry, unimplemented..." lines on the
> same file. Bison version is 3.0.4.
> 
> I rebuilt&installed current libgig/liblscp packages before building this
> one, all fine so far.
> 
> Do I have to run some manual "generate" step first?

Short: either compile with clang (works also with quite old versions of clang) 
or update to GCC >= 8.x. You can install both clang and gcc without problems.
If you have both installed, just force LS compilation with clang like this:

	CXX=clang++ CC=clang ./configure && make

Background: The LS code base is now using a lot of so called "designated 
initializers", probably better described as C-style "named initializers" for 
semantic critical functions/methods. Instead of this:

	void foo(int a, float b, char c, bool d) {
		...
	}

	...

	foo(1, 2.9, 'a', true); // function call

it's now (often) like this instead:

	struct FooOpt {
		int a;
		float b;
		char c;
		bool d;
	}

	void foo(FooOpt& opt) {
		...
	}

	...

	foo({ // function call
		.a = 1,
		.b = 2.9,
		.c = 'a',
		.d = true
	});

Reason: after a while (months, years, ...), arguments of functions/methods are 
typically changed, which can silently introduce bugs since the compiler only 
checks function calls for type correctness with the old function call style.
By binding a function argument to a name, you are binding it to a specific 
semantic when calling the function, which the compiler would immediately 
recognize with an error if function's semantics were changed without updating 
all calls appropriately, and hence prevents such kind of bugs at compilation. 
It also makes the code more readable.

I know C++>=14 requirement is quite a shift regarding backward compatibility 
of LS, but a bunch of new C++ language features reduce code complexity (and 
hence development time and bug affinity) significantly, and the LS code base 
is already quite large, so I decided to go for the "please use recent 
compilers" route after last year's release instead of investing a lot of time 
for supporting old compilers.

CU
Christian

[Linuxsampler-devel] Build errors for LinuxSampler on Mint 19.2

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

Hi all,

not sure if I overlooked some recent build requirement change, but with Linux
Mint 19.2 (gcc 7.4.0) I seem to be unable to build current LinuxSampler
(svn r3734) from source (but thie issue might been in for a while already):

Sequence up this point was "make -f Makefile.svn && ./configure && make -j4".

...
make[5]: Entering directory '/home/franky/src/audio/linuxsampler/svn/build/linuxsampler/src/scriptvm'
depbase=`echo parser.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -std=gnu++14 -DHAVE_CONFIG_H -I. -I../..    -Wreturn-type -ffast-math  -g -O2 -pthread -MT parser.lo -MD -MP -MF $depbase.Tpo -c -o parser.lo parser.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  g++ -std=gnu++14 -DHAVE_CONFIG_H -I. -I../.. -Wreturn-type -ffast-math -g -O2 -pthread -MT parser.lo -MD -MP -MF .deps/parser.Tpo -c parser.cpp  -fPIC -DPIC -o .libs/parser.o
In file included from tree.h:27:0,
                 from parser_shared.h:16,
                 from parser.y:14:
../common/ArrayList.h:67:44: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
             void remove(ssize_t iPosition) throw (Exception) {
                                            ^~~~~
In file included from tree.h:28:0,
                 from parser_shared.h:16,
                 from parser.y:14:
../common/optional.h:73:34: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
             const T& get() const throw (Exception) {
                                  ^~~~~
../common/optional.h:78:22: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
             T& get() throw (Exception) {
                      ^~~~~
../common/optional.h:105:41: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
             const T& operator *() const throw (Exception) { return get(); }
                                         ^~~~~
../common/optional.h:106:41: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
             T&       operator *()       throw (Exception) { return get(); }
                                         ^~~~~
../common/optional.h:108:42: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
             const T* operator ->() const throw (Exception) {
                                          ^~~~~
../common/optional.h:113:30: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
             T* operator ->() throw (Exception) {
                              ^~~~~
In file included from parser_shared.h:24:0,
                 from parser.y:14:
../common/global_private.h:99:40: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
 inline int ToInt(const std::string& s) throw(LinuxSampler::Exception) {
                                        ^~~~~
../common/global_private.h:106:44: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
 inline float ToFloat(const std::string& s) throw(LinuxSampler::Exception) {
                                            ^~~~~
parser.y: In function ‘int InstrScript_parse(LinuxSampler::ParserContext*)’:
parser.y:311:25: sorry, unimplemented: non-trivial designated initializers not supported
                         });
                         ^
parser.y:311:25: sorry, unimplemented: non-trivial designated initializers not supported
parser.y:311:25: sorry, unimplemented: non-trivial designated initializers not supported
parser.y:311:25: sorry, unimplemented: non-trivial designated initializers not supported
parser.y:318:26: sorry, unimplemented: non-trivial designated initializers not supported
                         });
                          ^

There is a whole bunch more of these "sorry, unimplemented..." lines on the same file.
Bison version is 3.0.4.

I rebuilt&installed current libgig/liblscp packages before building this one, all fine so far.

Do I have to run some manual "generate" step first?

Thanks for any hints,
Frank

Re: [Linuxsampler-devel] new Giga filter types

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

On Sonntag, 22. Dezember 2019 15:27:49 CET Christian Schoenebeck wrote:
> Anyway, since these new filter types are (once again) an extension to the
> official gig format, I obviously had some freedom to deviate behaviour for
> these new filter types: I always disliked the behaviour of the "minimum
> cutoff" parameter, which so far was simply handled like this:
> 
> 	finalCutoff = MAX(cutoffCCValue, minCutoff);
> 
> The problem with the latter was that you always ended up with a "dead"
> controller zone, so a certain controller value range where the controller
> would not do anything.
> 
> Instead of doing that, with the new filter types I re-interpreted this
> "minimum cutoff" parameter which still defines a "minimum cutoff", but the
> range is now automatically spanned over the entire 0..127 controller range
> instead to prevent such a dead zone.
> 
> I am not sure yet, but probably it would even make sense to apply this
> change to the official GSt filter types as well?

Since I got no vetos, I just changed this behaviour for the original GSt 
filter types as well:

http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=3721

CU
Christian

Re: [Linuxsampler-devel] GSt3: 128 3gnm chunks

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

On Montag, 20. Januar 2020 02:26:04 CET Ivan Maguidhir wrote:
> Hi Christian
> 
> On 19/01/2020 21:20, Christian Schoenebeck wrote:
> > Hi Ivan,
> > 
> > I just realized now your patch probably does not what you wanted it to:
> > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?
> > r1=3656&r2=3655&pathrev=3656
> > 
> > You see the problem?
> 
> Nothing jumped out at me straight away. The code calls SaveString for
> existing 3gnm chunks in the _3gnl list using their Chunk* as the ck
> parameter. When the end of the _3gnl list is reached SaveString is
> called, from that point onward, with NULL as the ck parameter resulting
> in new 3gnm chunks being created for those strings and appended to the
> _3gnl list. This should result in 128 3gnm chunks containing the empty
> string regardless of the number of groups in the file.
> Group::UpdateChunks should call SaveString with the group name set by
> the user, leaving the remaining 3gnm chunks set to the empty string.
> Sorry if I'm missing something obvious.

Ah, you're right! Saul goode, thanks!

CU
Christian