LinuxSampler 2.3.0 and friends were released on Jan 26th 2024. Almost three years have passed since the previous release. This time the release notes are quite short, as this is basically a maintenance release with a bunch of fixes.
This release of LinuxSampler fixes behaviour of release-triggered samples for some keybaords without release velocity sensors: if and only if MIDI note-off velocity is exactly zero (which means keyboard does not have a sensor) then the previous note-on velocity is used as note-off velocity for release triggered samples.
Most of the changes in this release are adoptions of API changes introduced on libgig 4.4.0 side which in turn are fixing a bunch of misbehaviours people were facing in the past, foremost multi-threading issues. Refer to the libgig changes below for more details.
Refer to LinuxSampler's ChangeLog for other changes.
Similar to changes in LinuxSampler, most of the changes in this Gigedit release are also adoptions of API changes by libgig 4.4.0, which brings multi-threading fixes for Gigedit as well. Refer to the libgig changes below for more details.
Our fundamental file access C++ library libgig has also received mostly fixes, but also something new, another tool:
This release of libgig introduces a new command line tool 'wav2gig' which allows to automatically create a .gig file from a directory of .wav files. This can safe quite some time when creating a new and large .gig instrument from scratch, as this tool automatically extracts info such as root note, velocity and loop points either from the .wav files themselves (if possible), or from their file names. It comes with a bunch of options to override exact behaviour to whatever the naming scheme of your .wav files are for instance. Refer to the new 'wav2gig' man page for details.
A long sitting API issue had been mitigated in this release: the ancient
style of methods were always error prone.
Those methods are now marked as deprecated and
GetFoo(size_t index) or
methods were added as reentrant-safe replacement.
I/O per Thread
Another important multi-threading issue for applications based on libgig have
been addressed on API level: the
RIFF::File class now
provides a new method
(see libgig API docs)
to activate a transparent mode of separation for
file streaming by libgig. By default this feature is off and libgig therefore
behaves as in previous releases, which means application threads would
concurrently change file I/O positions when accessing libgig file access
methods simultaniously, like e.g. streaming audio data from disk or loading or
saving any kind of other data from or to the file directly might
unintentionally change threads' file I/O positions between each other. By
activating this new libgig feature, libgig automatically detects individual
threads (as callers of affected libgig methods) and separates the file I/O
positions for each application thread automatically, as if each thread had
opened the file separately by itself. This feature comes with a slight runtime
overhead cost, but has the advantage that it keeps application code simple, as
it usually just requires to add only one line of code to make a multi-threaded
applications work as expected, while still sharing the same libgig objects and
without duplicating data or draining RAM resources.
The rest of changes are numerous fixes, please refer to libgig's ChangeLog for details.