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

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

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

On Freitag, 24. Mai 2019 15:53:08 CEST David Bolton wrote:
> IMO the best solution on long term would be Ardour running VST plugins in
> 
> > their own process, instead of loading VST plugins directly into the Ardour
> > process.
> 
> I will pass this information along to Ardour via my original post:
> https://discourse.ardour.org/t/linuxsampler-under-windows/89908/12

Yes, I see, expected old answer from their side on this issue.

We are in 2019, and process separation for audio plugin scales well even on 
iOS (which even wraps that into a virtualized container). I mean these days 
even nested virtualization starts to be come a topic, which is far more 
expensive than just process separation.

The thing that they probably don't see is that process separation for plugins 
is usually done by using *one* process for all instances of one particular 
plugin. So both resource consumption, as well as the required amount of 
context switches is far less than the typical performance calculation that I 
read from Ardour developers several times before. It usually requires 2 
context switches per period for all instances of one plugin, no matter how 
many tracks you have on DAW side, because a plugin like LS is not an insert 
effect.

And the argument that process separation was even unprofessional is not 
rational. Logic supports _optional_ process separation for AU plugins on macOS 
already. If you add this feature as optional setting per plugin then nobody 
gets hurt. But I don't expect their opinion to change on this issue any time 
soon.

Potential library conflicts is an issue when only supporting in-process 
plugins, which I don't expect to become less of a problem in future. Just take 
the Gtk libs as an example: Gtk currently consists of around 24 separate 
libraries, many of them are not even designed for static linking. They are 
loading modules for core functionalities at runtime (plus various resources 
with absolute pathes) which cannot be linked statically with stock gtk, at 
least not without heavily patching them (and heavy continuous maintenance of 
the gtk libs on our side).

Another fact is: plugins may crash; some(times) more, some(times) less. From 
usability point of view it is just contempoary to accept that this may indeed 
happen, and that this should not tear down the entire DAW (like it is 
inevitable with in-process plugins), only the causing plugin should crash, and 
the user should get a clear error message by the DAW which plugin crashed, and 
asking the user whether the plugin shall be reloaded.

> Thank you. The new version of qsampler opens without errors. I had a little
> trouble with setting up the audio device. Qsampler didn't explain why
> (except messages like "AudioOutputDeviceAsio (errno=100)" and "
> lscp_get_audio_device_info:
> DESCRIPTION (errno=0)").However when I opened JSampler it triggered a more
> instructive error message from linuxsampler: "AudioOutputDeviceAsio: Can't
> find any ASIO-capable sound card. Make sure you have an ASIO driver
> installed for your sound device. If you are using a consumer sound card
> that does not provide an ASIO driver to be installed, then consider
> installing an alternative like ASIO4ALL."

I hooked off from Windows years ago, and the current ASIO driver on LS side 
are more than 10 years old. So yes, there are certainly things to be improved 
on that driver. Probably there is even a better alternative than ASIO4ALL 
nowadays. Maybe people still working on Windows know more on that.

> > > If I open JSampler, it complains about not being able to find javaw.exe
> > > When it opens I get the following error
> > > message: "Connecting to LinuxSampler: Can't establish connection"
> > 
> > No idea about that one. I have to add, I am actually no longer using
> > Windows
> > for several years, same applies to Java.
> 
> These errors have gone away now.

I assume that's because you changed the PATH variable by using Windows' system 
settings graphical user interface, which requires a reboot for the PATH 
variable change to become effective. Next time you can also set the PATH 
variable immediately without rebooting from the terminal by doing:

	SET PATH=%PATH%;C:\yournewpath

That way you can experiment with PATH issues more effectively.

> In the meantime I have another sampler working on Windows, but I'm happy to
> continue testing if needed.

No problem!

As you can see, the Windows version of LS should probably receive better 
maintenance. However since I am not using Windows anymore, it is not my 
personal focus. I mean I try to fix reported issues wherever I can, but beyond 
minor changes (like the missing Qt5Network DLL discussed here) it usually 
requires testing on Windows of course as well, so ... :)

CU
Christian

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

[David B. <dav...@gm...>]

Christian,

Thank you for your detailed response.

IMO the best solution on long term would be Ardour running VST plugins in
> their own process, instead of loading VST plugins directly into the Ardour
> process.
>

I will pass this information along to Ardour via my original post:
https://discourse.ardour.org/t/linuxsampler-under-windows/89908/12


> > Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind
> > server socket, retrying for 180 seconds...gave up!
>

Rebooting fixed the issue as you suggested.


> > qsampler.exe - System Error
>
> I just fixed that in our Windows installer scripts. So when you download
> the
> latest installer, that error should be gone now.
>

Thank you. The new version of qsampler opens without errors. I had a little
trouble with setting up the audio device. Qsampler didn't explain why
(except messages like "AudioOutputDeviceAsio (errno=100)" and "
lscp_get_audio_device_info:
DESCRIPTION (errno=0)").However when I opened JSampler it triggered a more
instructive error message from linuxsampler: "AudioOutputDeviceAsio: Can't
find any ASIO-capable sound card. Make sure you have an ASIO driver
installed for your sound device. If you are using a consumer sound card
that does not provide an ASIO driver to be installed, then consider
installing an alternative like ASIO4ALL."

I installed ASIO4ALL and it appeared to work well with LinuxSampler (I
could loads the instrument samples and qsampler reacted to MIDI signals
(with the green flashing light). Maybe there's a problem with ASIO4ALL and
my sound card or setup.  I tried rebooting, but still no sound. I can try
on a different machine later.


> > If I open JSampler, it complains about not being able to find javaw.exe
> > When it opens I get the following error
> > message: "Connecting to LinuxSampler: Can't establish connection"
>
> No idea about that one. I have to add, I am actually no longer using
> Windows
> for several years, same applies to Java.
>

These errors have gone away now.

In the meantime I have another sampler working on Windows, but I'm happy to
continue testing if needed.

David

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

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

On Donnerstag, 23. Mai 2019 14:06:51 CEST David Bolton wrote:
> Here's the messages I get when I launch linuxsampler.exe from the command
> line:
> 
> C:\Program Files\LinuxSampler\64>linuxsampler.exe
> LinuxSampler 2.1.0.svn8
> Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck
> Copyright (C) 2005-2019 Christian Schoenebeck
> Binary built: Mar 11 2019
> Detected features: MMX SSE SSE2
> Automatic Stacktrace: Off
> Creating Sampler...OK

So like I expcted, the stand-alone app runs there. Then the problem you have 
with the LS VST not launching in Ardour is indeed very likely caused by a 
conflicting libstdc++ version.

Background: we are currently still using GCC as compiler on our build server 
for compiling the daily snapshot installers for Windows. And I am pretty sure 
your Ardour binary was compiled with clang. The two compilers use their own 
implementation of libstdc++, and both cannot be loaded into one process at the 
same time.

Like already suggested in the Ardour forum, one workaround would be if we 
statically link libstdc++ into our binaries (instead of letting our binaries 
load libstdc++ dynamically as DLL on startup like it is now). But that is 
tricky and may introduce new problems, since all libs used must then use our 
statically linked libstdc++ instead.

Another option would be if we just switch to clang for compiling the Windows 
installer. But then it would cause other DAWs getting the same VST issue if 
they were compiled with GCC instead.

IMO the best solution on long term would be Ardour running VST plugins in 
their own process, instead of loading VST plugins directly into the Ardour 
process. That way libs loaded by VST plugins would no longer conflict with libs 
of other plugins or host app (i.e. Ardour).  Because even if we do some of the 
workarounds mentioned above, the next issue would already be ahead: e.g. if 
you want to edit a gig file currently being played back as VST instrument in 
Ardour, then our gigedit instrument editor would try to load Gtk3 libs, and 
Ardour already loaded Gtk2 libs, hence gigedit would never show up on your 
screen.

I know the opinion of Ardour developers is that running plugins in their own 
process would be inefficient due to expensive context switches, but other DAW 
apps like Logic already switched to that new model and performance seems to be 
Ok nowadays. In the end this could also become an optional setting per plugin 
on Ardour side.

Opinions?

> Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind
> server socket, retrying for 180 seconds...gave up!

That error is probably because the LSCP server crashed with your VST plugin. 
Rebooting should fix that issue.

> If try to open the qsampler.exe stand-alone app, I get the following error:
> 
> ---------------------------
> qsampler.exe - System Error
> ---------------------------
> The code execution cannot proceed because Qt5Network.dll was not found.
> Reinstalling the program may fix this problem.

I just fixed that in our Windows installer scripts. So when you download the 
latest installer, that error should be gone now.

> If I open JSampler, it complains about not being able to find javaw.exe
> (even though I added the javaw.exe folder to the Windows path variable and
> restarted the computer). However, I can manually browse to javaw.exe at
> each start up and JSampler opens. When it opens I get the following error
> message: "Connecting to LinuxSampler: Can't establish connection"

No idea about that one. I have to add, I am actually no longer using Windows 
for several years, same applies to Java.

CU
Christian

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

[David B. <dav...@gm...>]

Christian,

Thank you for your reply.

Here's the messages I get when I launch linuxsampler.exe from the command
line:

C:\Program Files\LinuxSampler\64>linuxsampler.exe
LinuxSampler 2.1.0.svn8
Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck
Copyright (C) 2005-2019 Christian Schoenebeck
Binary built: Mar 11 2019
Detected features: MMX SSE SSE2
Automatic Stacktrace: Off
Creating Sampler...OK
Registered sampler engines: 'GIG','SF2','SFZ'
Registered MIDI input drivers: MME
Registered audio output drivers: ASIO
Loading instrument editor plugins...OK
Registered instrument editors: 'gigedit'
Registered internal effect systems: LADSPA
Could not scan LADSPA effects: library path 'C:\Program Files\ladspa'
doesn't exist
Registered internal effects: 0
Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind
server socket, retrying for 180 seconds...gave up!

If try to open the qsampler.exe stand-alone app, I get the following error:

---------------------------
qsampler.exe - System Error
---------------------------
The code execution cannot proceed because Qt5Network.dll was not found.
Reinstalling the program may fix this problem.
---------------------------
OK
---------------------------

(reinstalling the program didn't fix the issue).

If I open JSampler, it complains about not being able to find javaw.exe
(even though I added the javaw.exe folder to the Windows path variable and
restarted the computer). However, I can manually browse to javaw.exe at
each start up and JSampler opens. When it opens I get the following error
message: "Connecting to LinuxSampler: Can't establish connection"

David




On Thu, May 23, 2019 at 10:51 AM Christian Schoenebeck <
sch...@li...> wrote:

> On Dienstag, 21. Mai 2019 13:02:14 CEST David Bolton wrote:
> > I'm having trouble getting LinuxSampler to run as a plugin within Ardour
> on
> > Windows 10.
> >
> > Here's the error message as reported by Ardour:
> > The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be
> located
> > in the dynamic link library C:\Program
> > Files\Steinberg\VstPlugins\LinuxSampler64.dll.
>
> Looks like a version conflict of the C++ stdlib (i.e. clang's stdlib
> already
> been loaded by Ardour vs. GNU's stdlib attempted to be loaded by the LS
> VST
> plugin later on).
>
> Does the LS stand-alone app run?
>
> CU
> Christian
>

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

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

On Dienstag, 21. Mai 2019 13:02:14 CEST David Bolton wrote:
> I'm having trouble getting LinuxSampler to run as a plugin within Ardour on
> Windows 10.
> 
> Here's the error message as reported by Ardour:
> The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be located
> in the dynamic link library C:\Program
> Files\Steinberg\VstPlugins\LinuxSampler64.dll.

Looks like a version conflict of the C++ stdlib (i.e. clang's stdlib already 
been loaded by Ardour vs. GNU's stdlib attempted to be loaded by the LS VST 
plugin later on).

Does the LS stand-alone app run?

CU
Christian

[Linuxsampler-devel] Using LinuxSampler as plugin on Windows

[David B. <dav...@gm...>]

I'm having trouble getting LinuxSampler to run as a plugin within Ardour on
Windows 10.

Here's the error message as reported by Ardour:
The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be located
in the dynamic link library C:\Program
Files\Steinberg\VstPlugins\LinuxSampler64.dll.

I posted initially in the Ardour forum.
https://discourse.ardour.org/t/linuxsampler-under-windows/89908/13. They
said, "looks like the VST was not statically linked and/or depends on
libraries not present on your system" and suggested reporting to the
LinuxSampler developers.

Happy to run tests as needed.

David

[Linuxsampler-devel] [ANN] The QStuff* Spring Break'19 release batch #1

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

Cheers!

Interesting times we're living in...

The first batch to the so called Qstuff* Spring Break'19 is now being
delivered as fully complementary as post-LAC2019 [21] frenzy ;)

And in this batch, we have:
*  QjackCtl 0.5.7 [1]
*  Qsynth 0.5.6 [2]
*  Qsampler 0.5.5 [3]
*  QXGEdit 0.5.4 [4]
*  QmidiCtl 0.5.4 [5]
*  QmidiNet 0.5.4 [6]

All the boring (to death) details, below...


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

  QjackCtl 0.5.7 (spring-break'19) is out!

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:
  http://sourceforge.net/projects/qjackctl

Downloads:
  http://sourceforge.net/projects/qjackctl/files
- source tarball:
  http://download.sf.net/qjackctl/qjackctl-0.5.7.tar.gz
- source package:
  http://download.sf.net/qjackctl/qjackctl-0.5.7-36.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qjackctl/qjackctl-0.5.7-36.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qjackctl/qjackctl-0.5.7-9.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:
- Graph node and port title renaming and nodes position move changes are
now undo/redo-able.
- Graph client and port title in-place renaming is now integrated to
native aliases and JACK metadata (aka. pretty-names).
- Refactored all native client/port name aliases.
- Re-defined all main application UNIX signal handling.


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

  Qsynth 0.5.6 (spring-break'19) is out!

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:
  http://sourceforge.net/projects/qsynth

Downloads:
  http://sourceforge.net/projects/qsynth/files
- source tarball:
  http://download.sf.net/qsynth/qsynth-0.5.6.tar.gz
- source package:
  http://download.sf.net/qsynth/qsynth-0.5.6-17.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qsynth/qsynth-0.5.6-17.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qsynth/qsynth-0.5.6-9.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:
- Re-defined all main application UNIX signal handling.


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

  Qsampler 0.5.5 (spring-break'19) is out!

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:
  http://sourceforge.net/projects/qsampler

Downloads:
  http://sourceforge.net/projects/qsampler/files
- source tarballs:
  http://download.sf.net/qsampler/qsampler-0.5.5.tar.gz
- source package:
  http://download.sf.net/qsampler/qsampler-0.5.5-29.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qsampler/qsampler-0.5.5-29.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qsampler/qsampler-0.5.5-9.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:
- Re-defined all main application UNIX signal handling.


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

  QXGEdit 0.5.4 (spring-break'19) is out!

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:
  http://sourceforge.net/projects/qxgedit

Downloads:
  http://sourceforge.net/projects/qxgedit/files
- source tarball:
  http://download.sf.net/qxgedit/qxgedit-0.5.4.tar.gz
- source package:
  http://download.sf.net/qxgedit/qxgedit-0.5.4-15.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qxgedit/qxgedit-0.5.4-15.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qxgedit/qxgedit-0.5.4-9.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:
- Re-defined all main application UNIX signal handling.


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

  QmidiCtl 0.5.4 (spring-break'19) is out!

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:
  http://sourceforge.net/projects/qmidictl

Downloads:
  http://sourceforge.net/projects/qmidictl/files
- source tarball:
  http://download.sf.net/qmidictl/qmidictl-0.5.4.tar.gz
- source package:
  http://download.sf.net/qmidictl/qmidictl-0.5.4-16.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qmidictl/qmidictl-0.5.4-16.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qmidictl/qmidictl-0.5.4-9.x86_64.AppImage
- Android package:
  http://download.sf.net/qmidictl/qmidictl-0.5.4-9.apk
  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:
- Fix build on linux with musl (according to POSIX.1-2001, POSIX.1-2008;
PR#3 by Andreas Müller aka. schnitzeltony, thanks).
- HiDPI display screen support (Qt >= 5.6).


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

  QmidiNet 0.5.4 (spring-break'19) is out!

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:
  http://sourceforge.net/projects/qmidinet

Downloads:
  http://sourceforge.net/projects/qmidinet/files
- source tarball:
  http://download.sf.net/qmidinet/qmidinet-0.5.4.tar.gz
- source package:
  http://download.sf.net/qmidinet/qmidinet-0.5.4-17.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qmidinet/qmidinet-0.5.4-17.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qmidinet/qmidinet-0.5.4-9.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:
- Fix build on linux with musl (according to POSIX.1-2001, POSIX.1-2008;
PR#7 by Andreas Müller aka. schnitzeltony, thanks).


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
     http://qt.io/

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

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

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

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

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

[13] GPL - GNU General Public License
     http://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
     http://llg.cubic.org/tools/multimidicast

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

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

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

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

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

[21] LAC2019@CCRMA-Stanford, March 22–26 2019
     https://lac.linuxaudio.org/2019/


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


Enjoy && Keep the fun!
--
rncbc aka Rui Nuno Capela

Re: [Linuxsampler-devel] Jack support for Linuxsampler on OSX?

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

On Montag, 8. April 2019 07:46:53 CEST Kurt Miyashiro wrote:
> Does anyone have a package for Linuxsampler with Jack support on OSX? 

So far nobody actually asked for JACK support on macOS before. And that's why 
currently our automatic builds for macOS are not compiling with JACK support 
enabled yet.

So right now the fastest solution for you would probably compiling the sampler 
backend with JACK support on macOS by yourself. And since you only need to 
compile and replace the sampler backend (not any UI frontend or the instrument 
editor) the involved library dependencies are quite small.

> Linuxsampler works better as a standalone, rather than as a plugin when
> used in large orchestral projects.  Currently, I can only run Linuxsampler
> with Coreaudio or as a plugin, and no Jack.  Perhaps it is the interaction
> between Ardour and Linuxsampler that is causing issues (long freezes,
> complete crashes).  The same project works perfectly well on Linux.  Any
> help would be appreciated.

Which plugin did you use, AU or VST? Both are available on Mac, and Ardour 
might be one of the few DAWs supporting both.

CU
Christian

[Linuxsampler-devel] Jack support for Linuxsampler on OSX?

[Kurt M. <kmi...@gm...>]

Does anyone have a package for Linuxsampler with Jack support on OSX?  Linuxsampler works better as a standalone, rather than as a plugin when used in large orchestral projects.  Currently, I can only run Linuxsampler with Coreaudio or as a plugin, and no Jack.  Perhaps it is the interaction between Ardour and Linuxsampler that is causing issues (long freezes, complete crashes).  The same project works perfectly well on Linux.  Any help would be appreciated.

Re: [Linuxsampler-devel] Does LS have a "global fine tuning" control?

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

On Freitag, 29. März 2019 12:33:28 CET Jaime T wrote:
> Is anyone aware of how I could lower the pitch of all sound coming out of LS
> by, say, 0.844%? (Motivation: I'm playing over the top of a video where
> their A flat 2, normally 103.8262Hz, is sounding at 102.95Hz).

There is pitchbend of course, which is on per part (sampler channel) level.

Then globally for all parts there is the Roland GS scale tuning SysEx message. 
Which allows to fine tune the 12 individual notes of an octave by cents.

And there is the coarse tuning RPN controller, which transposes in semi tone 
steps.

CU
Christian

[Linuxsampler-devel] Does LS have a "global fine tuning" control?

[Jaime T <eno...@gm...>]

I've searched the mailing list archive, the forum and the "LinuxSampler
Control Protocol" reference documentation looking for any mention of a
"global fine tuning" control but I couldn't find anything.

Is anyone aware of how I could lower the pitch of all sound coming out of LS
by, say, 0.844%? (Motivation: I'm playing over the top of a video where
their A flat 2, normally 103.8262Hz, is sounding at 102.95Hz).

Re: [Linuxsampler-devel] Mac AU plugin issue

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

On 2019. Mar 15., at 13:00, Christian Schoenebeck <sch...@li...> wrote:
> Ok, I will look into that AU issue a bit later. Currently I don't have Logic
> installed, so I can't test the AU ATM.
Thank you very much. Please let me know if there’s anything else I can do to help.

All the best,
Rob

Re: [Linuxsampler-devel] Mac AU plugin issue

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

On Freitag, 15. März 2019 12:05:06 CET Robert O. wrote:
> On 2019. Mar 14., at 15:05, Christian Schoenebeck 
<sch...@li...> wrote:
> > I don't get that behaviour with macOS 10.14.3 using the stand-alone app.
> 
> You are right, the standalone version seems to be working when I followed
> the steps you suggested. There are no cutouts and the instruments work as
> expected. This is probably an AU plugin issue.

Ok, I will look into that AU issue a bit later. Currently I don't have Logic 
installed, so I can't test the AU ATM.

CU
Christian

Re: [Linuxsampler-devel] Mac AU plugin issue

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

On 2019. Mar 14., at 15:05, Christian Schoenebeck <sch...@li...> wrote:
> I don't get that behaviour with macOS 10.14.3 using the stand-alone app.
You are right, the standalone version seems to be working when I followed the steps you suggested. There are no cutouts and the instruments work as expected. This is probably an AU plugin issue.

All the best,
Rob

Re: [Linuxsampler-devel] Mac AU plugin issue

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

On Donnerstag, 14. März 2019 14:01:40 CET Robert O. wrote:
> On 2019. Mar 14., at 13:12, Christian Schoenebeck 
<sch...@li...> wrote:
> > Does this only happen with the AU, or also when you use the stand-alone
> > app?
> I have tested it just now via QSampler, and the issue seems to be the same,
> no matter what instrument I load.

I don't get that behaviour with macOS 10.14.3 using the stand-alone app.

To avoid misapprehensions: Make sure you closed Logic, and for now (just in 
this particular case) reboot the Mac, then use QSampler to create only one 
part, and when you create that part make sure that "CoreAudio" as audio driver 
and "CoreMIDI" as MIDI driver is selected in those two combo boxes before you 
actually create the sampler part with QSampler.

Background: the sampler actually allows quite exotic setups, and when you 
start the sampler as plugin (e.g. in Logic) you may even use the sampler in a 
mixed setup with other apps, even using multiple different drivers (AU/VST 
plugin, CoreAudio, CoreMIDI, JACK) simultaniously.

CU
Christian

Re: [Linuxsampler-devel] Mac AU plugin issue

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

On 2019. Mar 14., at 13:12, Christian Schoenebeck <sch...@li...> wrote:
> Does this only happen with the AU, or also when you use the stand-alone app?
I have tested it just now via QSampler, and the issue seems to be the same, no matter what instrument I load.

> How many LS parts/tracks are you using in Logic?
It varies, in this particular instance I have used 12, but I have also tried with a single channel only.

All the best,
Rob

Re: [Linuxsampler-devel] Mac AU plugin issue

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

On Mittwoch, 13. März 2019 15:34:48 CET Robert O. wrote:
> Hi all,

Hi!

> I’m not sure if this has been reported before, but there seems to be an
> issue with the AU plugin on macOS Mojave.
> 
> I’ve tested the latest and earlier versions using Logic Pro X with various
> Giga instruments, and when sending a note via a midi keyboard, sample
> playback cuts out a few milliseconds into the played sample. Sometimes,
> faster playing results in a full note, however playing another note
> afterwards results in a very short note again.

Does this only happen with the AU, or also when you use the stand-alone app?

How many LS parts/tracks are you using in Logic?

CU
Christian

[Linuxsampler-devel] Mac AU plugin issue

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

Hi all,

I’m not sure if this has been reported before, but there seems to be an issue with the AU plugin on macOS Mojave.

I’ve tested the latest and earlier versions using Logic Pro X with various Giga instruments, and when sending a note via a midi keyboard, sample playback cuts out a few milliseconds into the played sample. Sometimes, faster playing results in a full note, however playing another note afterwards results in a very short note again.

All the best,
Rob

[Linuxsampler-devel] [ANN] The QStuff* Pre-LAC2019 Release Frenzy

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

Hello there!

The Qstuff* pre-LAC2019 [17] release frenzy is now starting up... enjoy!

Included in this batch:

*  QjackCtl 0.5.6
*  Qsynth 0.5.5
*  Qsampler 0.5.4
*  QXGEdit 0.5.3
*  QmidiNet 0.5.3

All the boring details follow suit...


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

  QjackCtl 0.5.6 (pre-lac2019) is released!

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

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

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

Downloads:
  http://sourceforge.net/projects/qjackctl/files
- source tarball:
  http://download.sf.net/qjackctl/qjackctl-0.5.6.tar.gz
- source package:
  http://download.sf.net/qjackctl/qjackctl-0.5.6-35.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qjackctl/qjackctl-0.5.6-35.rncbc.suse.x86_64.rpm
- AppImage [16] package:
  http://download.sf.net/qjackctl/qjackctl-0.5.6-7.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:
- Refactored all singleton/unique application instance setup logic away
from X11/Xcb hackery.
- At last, JACK freewheel mode is now being detected as to postpone any
active patchbay scans as much as possible.
- Removed old pre-FFADO 'freebob' driver support.
- HiDPI display screen support (Qt >= 5.6).
- Graph port temporary highlighting while hovering, if and only if
connecting ports of same type and complementary modes.
- Bumped copyright headers into the New Year (2019).


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

  Qsynth 0.5.5 (pre-lac2019) is released!

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

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

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

Downloads:
  http://sourceforge.net/projects/qsynth/files
- source tarball:
  http://download.sf.net/qsynth/qsynth-0.5.5.tar.gz
- source package:
  http://download.sf.net/qsynth/qsynth-0.5.5-16.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qsynth/qsynth-0.5.5-16.rncbc.suse.x86_64.rpm
- AppImage [16] package:
  http://download.sf.net/qsynth/qsynth-0.5.5-7.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:
- Refactored all singleton/unique application instance setup logic away
from X11/Xcb hackery.
- HiDPI display screen support (Qt >= 5.6).
- Bumped copyright headers into the New Year (2019).


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

  Qsampler 0.5.4 (pre-lac2019) is released!

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

Website:
  http://qsampler.sourceforge.net

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

Downloads:
  http://sourceforge.net/projects/qsampler/files
- source tarballs:
  http://download.sf.net/qsampler/qsampler-0.5.4.tar.gz
- source package:
  http://download.sf.net/qsampler/qsampler-0.5.4-28.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qsampler/qsampler-0.5.4-28.rncbc.suse.x86_64.rpm
- AppImage [16] package:
  http://download.sf.net/qsampler/qsampler-0.5.4-7.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:
- Refactored all singleton/unique application instance setup logic away
from X11/Xcb hackery.
- HiDPI display screen support (Qt >= 5.6).
- Bumped copyright headers into the New Year (2019).


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

  QXGEdit 0.5.3 (pre-lac2019) is released!

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

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

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

Downloads:
  http://sourceforge.net/projects/qxgedit/files
- source tarball:
  http://download.sf.net/qxgedit/qxgedit-0.5.3.tar.gz
- source package:
  http://download.sf.net/qxgedit/qxgedit-0.5.3-14.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qxgedit/qxgedit-0.5.3-14.rncbc.suse.x86_64.rpm
- AppImage [16] package:
  http://download.sf.net/qxgedit/qxgedit-0.5.3-7.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:
- HiDPI display screen support (Qt >= 5.6).
- Old deprecated Qt4 build support is no more.
- AppStream metadata updated to be the most compliant with latest
freedesktop.org specification and recommendation.


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

  QmidiNet 0.5.3 (pre-lac2019) is released!

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

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

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

Downloads:
  http://sourceforge.net/projects/qmidinet/files
- source tarball:
  http://download.sf.net/qmidinet/qmidinet-0.5.3.tar.gz
- source package:
  http://download.sf.net/qmidinet/qmidinet-0.5.3-16.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qmidinet/qmidinet-0.5.3-16.rncbc.suse.x86_64.rpm
- AppImage [16] package:
  http://download.sf.net/qmidinet/qmidinet-0.5.3-7.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:
- HiDPI display screen support (Qt >= 5.6).
- Old deprecated Qt4 build support is no more.
- AppData/AppStream metadata is now settled under an all permisssive
license (FSFAP); also updated to be the most compliant with latest
freedesktop.org specification and recommendation.
- Fixed for some g++ >= 8.1.1 warnings and quietness.


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
     http://qjackctl.sourceforge.net

 [2] Qsynth - A fluidsynth Qt GUI Interface
     http://qsynth.sourceforge.net

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

 [4] QXGEdit - A Qt XG Editor
     http://qxgedit.sourceforge.net

 [5] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast
     http://qmidinet.sourceforge.net

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

 [7] JACK Audio Connection Kit
     http://jackaudio.org

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

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

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

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

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

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

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

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

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

[17] LAC2019@CCRMA-Stanford, March 22–26 2019
     https://lac.linuxaudio.org/2019/


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


Enjoy && Keep having fun!
--
rncbc aka Rui Nuno Capela

[Linuxsampler-devel] Mac installer modernized

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

Hi,

As you probably know, we have a build system that compiles the code and
creates installers for Windows and Mac every time a change is done in
the source code.

The installer for macOS is now modernized:

* All components (libgig, linuxsampler, etc) are built with a newer
compiler, one that supports C++11. C++11 is also enabled in the builds.

* Third-party libraries are updated to newer versions, especially: GTK
(used by gigedit) is now version 3, and Qt (used by QSampler) is version 5.

* The upgrade of Qt makes QSampler work again. It has been broken in the
Mac installer for a long time, as Qt 5 has been a requirement.

* The minimum required macOS version is now 10.7. This means PowerPC
Macs are no longer supported.

* 32-bit Intel binaries are no longer included. Please let us know if
this is a problem to you.

The new installer can be found on the download page on
www.linuxsampler.org, in snapshot builds from today (20190310). Feel
free to test it and report any issues!

/Andreas

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

[Jacek R. <j....@gm...>]

> Ok, I have reviewed your patch. There are several issues with your suggested
> patch, some which you already pointed out, but also you are doing things which
> are not real-time safe, and overall it simply looks like more changes than
> actually required.

I think that there's no need for a voice to release itself and in the
third iteration a public pure virtual function in AbstractVoice
implemented in derived classes should be enough. The decision about
releasing a voice can be made in EngineChannelBase (like in the patch)
without group processing queue (which in my opinion is
counter-intuitive with sfz format's group and off_by opcodes.

> And one important thing: Please also describe (or provide links) in the report
> how the new sfz opcodes shall behave exactly in your opinion. Because I am not
> using sfz much. So I don't know the common behaviour of existing sfz opcodes
> of other players. And good (free) documentation about sfz is still a bit
> sparse. For the latter I once started this:

I will submit it.

> I don't think that's an issue at all. I don't expect anybody to have a demand
> of so many key groups. You probably barely find an instrument with more than 88
> key groups. And for the negative issue on our internal implementation side:
> for that purpose we do have the optional<> template class, which behaves
> (almost) identical to its equal named template class from the boost library
> and STL17:
>
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/common/
> optional.h?view=markup

I think later on I can convert sfz engine to use this class and
unsigned ints where appropriate to make linuxsampler more compatible
with the spec (that's the only reason). I was using far more than 88
groups in my drumkit instrument because of no polyphony support.
Imagine a ride cymbal hit, choose one zone (bow) out of three,
multiply it by velocity layers (8) and in each layer there's a group
of 4 round robin regions * 2 samples (overhead and room). It's 72
groups for ride cymbal. And there are 16 layers for snare, and
positional sensing :) Now I can put all ride samples in one group,
choke it with another off_by group and manage concurrent voices by
note_polyphony (let's say 2) with note_selfmask=on which is great for
cymbal hits, but setting polyphony to 6 for a group allows me to save
resources.

> No problem. I appreciate your effort though!

Maybe in some (long?) time I will share the final result - something
like a DIY poor man's Pearl Mimic Pro.

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

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

On Freitag, 8. März 2019 05:45:38 CET Jacek Roszkowski wrote:
> This is my second approach to handling polyphony. I'm not submitting
> it into bugzilla, since I'm not sure if that's the way it should be
> resolved. It works for me, but it's not thoroughly tested even for my
> needs.

Ok, I have reviewed your patch. There are several issues with your suggested 
patch, some which you already pointed out, but also you are doing things which 
are not real-time safe, and overall it simply looks like more changes than 
actually required.

I understand that you already invested more time in this feature than you 
wanted to. So my suggestion: just open a report for now and attach your patch 
so it won't get lost, and a bit later I might come up with an alternative 
implementation to achieve this feature, which won't happen in the next couple 
weeks or so though.

And one important thing: Please also describe (or provide links) in the report 
how the new sfz opcodes shall behave exactly in your opinion. Because I am not 
using sfz much. So I don't know the common behaviour of existing sfz opcodes 
of other players. And good (free) documentation about sfz is still a bit 
sparse. For the latter I once started this:

http://doc.linuxsampler.org/sfz/
( http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/doc/docbase/sfz/ )

But as you can see it is also not more than a start ATM.

> 6. signed/unsigned mismatch for sfz opcodes
> These are declared as int, even though most of them (according to
> http://www.sfzformat.com/legacy/) are unsigned with values from 0 to 4
> Gb (4294967296), and the "end" opcode can even take values from -1 to
> 4 Gb. This spec is weird, since 32 bit ULONG_MAX is 4294967295. It's
> not such a big deal, but the patch depends on off_by default value to
> be -1, since AbstractVoice requires iKeyGroup to be non-zero to
> processGroupEvents()

I don't think that's an issue at all. I don't expect anybody to have a demand 
of so many key groups. You probably barely find an instrument with more than 88 
key groups. And for the negative issue on our internal implementation side: 
for that purpose we do have the optional<> template class, which behaves 
(almost) identical to its equal named template class from the boost library 
and STL17:

http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/common/
optional.h?view=markup

> 7. My reference sfz engine is ARIA 1.933 with sforzando VST plugin.
> Unfortunately it behaves differently with note_polyphony opcode. My
> patch releases oldest voices first. ARIA releases most recent ones. I
> think it's a bug, not a feature, because if there are two regions

Yes, that's definitely not an appropriate behaviour. I don't know the ARIA 
engine much. But I know that many players don't have any real voice stealing 
algorithm implementation. So many engines simply pick random old voices 
instead of caring about to pick appropriate old voices.

> I've sent it here to get your opinion, but I suppose I'm not going to
> develop my concerns further, only bugfixing.

No problem. I appreciate your effort though!

CU
Christian

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

[Jacek R. <j....@gm...>]

Hi.

This is my second approach to handling polyphony. I'm not submitting
it into bugzilla, since I'm not sure if that's the way it should be
resolved. It works for me, but it's not thoroughly tested even for my
needs.

These are my concerns.

1. It can't be implemented in AbstractEngineChannel, because it needs
an access to voice pool, so it's in template EngineChannelBase.

2. It implements self-masking for sfz and gig (not sure how the
sustain pedal issue should be resolved, so I left it intact) and
handles group conflict in a different way (turned on by default only
for sfz). If you want to test it with gig and sf2 (I haven't), just
change the default value of NewAlgorithm to true.

3. It creates an interface for Voice classes to return KeyGroup (or
off_by for sfz with an argument set to true). I don't like this
solution. Maybe it should have two separate functions like
GetKeyGroup, GetOffBy returning same values for gig and sf2 and
different for sfz.

4. [premature optimization alert] It creates a separate Event for each
voice and processGroupEvents iterates over all events. I think the
complexity of this solution is O(n^2). It would be better with one
event containing a std::set of VoiceIDs to check against, but it's not
possible inside Event's union.

5. The function is huge. I don't like it.

6. signed/unsigned mismatch for sfz opcodes
These are declared as int, even though most of them (according to
http://www.sfzformat.com/legacy/) are unsigned with values from 0 to 4
Gb (4294967296), and the "end" opcode can even take values from -1 to
4 Gb. This spec is weird, since 32 bit ULONG_MAX is 4294967295. It's
not such a big deal, but the patch depends on off_by default value to
be -1, since AbstractVoice requires iKeyGroup to be non-zero to
processGroupEvents()

7. My reference sfz engine is ARIA 1.933 with sforzando VST plugin.
Unfortunately it behaves differently with note_polyphony opcode. My
patch releases oldest voices first. ARIA releases most recent ones. I
think it's a bug, not a feature, because if there are two regions
triggered at the same time the first one is suppressed and only the
second one is played. I've attached an example file to reproduce this
ARIA bug (you must provide a Crash.wav file which is long enough to
test polyphony).

I've sent it here to get your opinion, but I suppose I'm not going to
develop my concerns further, only bugfixing.

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

[Jacek R. <j....@gm...>]

pon., 25 lut 2019 o 21:37 Christian Schoenebeck
<sch...@li...> napisał(a):

> What do you mean with common interface released?

By final solution and common interface I thought about adding
parameters you have already mentioned (amount of voices per key group,
and whether a key group shall use a soft release or rather harsh kill)
to AbstractVoice instead of sfz::Voice.

> That's a continuous, non-formal process. If somebody needs to
> change some interface of the shared engine code for some new feature, then he
> simply does that. That's a not a public API, so we can quickly change things
> there without having to vote or something.

That was actually my concern. Thank you again for your replies.

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

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

On Montag, 25. Februar 2019 21:05:22 CET Jacek Roszkowski wrote:
> pon., 25 lut 2019 o 19:10 Christian Schoenebeck
> 
> <sch...@li...> napisał(a):
> > From what you described so far, I don't see why you would need to open a
> > separate concept to the existing key group conflict concept. As far as I
> > can see it, the key group concept just would need some additional options
> > for allowing what you want to do.
> 
> Thank you for your explanations. I'm a hobbyist drummer and hobbyist
> programmer and I don't aspire to bring a final solution for those
> issues. 

I did not suggest you to come up with a final solution. I just said that 
modifying the existing key group code makes more sense than adding a 
completely separate code inside the sfz classes which would handle the same 
thing as the existing key group code. It requires actually far less code to 
just modify the key group code than adding your previously suggested patch.

Where do you see difficulties extending the key group code for your purpose?

> I suppose the common engine interface is not going to be
> released in near future. 

What do you mean with common interface released? We already do have a shared 
code base for all 3 engines. Almost all engine code is shared code, and all 
new engine features are always added to that shared code base for several 
years now. That's a continuous, non-formal process. If somebody needs to 
change some interface of the shared engine code for some new feature, then he 
simply does that. That's a not a public API, so we can quickly change things 
there without having to vote or something.

We have put a lot of work in actually deduplicating all the code we had for 
the individual engines before; it does not make sense to turn back time and 
piling up yet again code inside the individual (non shared) engine code for 
things that would be needed in the other engines later on.

CU
Christian