| 1 |
|
Version 4.4.0 (26 Jan 2024) |
| 2 |
|
|
| 3 |
|
This release introduces a new command line tool 'wav2gig' which allows to |
| 4 |
|
automatically create a .gig file from a directory of .wav files. This can |
| 5 |
|
safe quite some time when creating a new and large .gig instrument from |
| 6 |
|
scratch, as this tool automatically extracts info such as root note, velocity |
| 7 |
|
and loop points either from the .wav files themselves (if possible), or from |
| 8 |
|
their file names. It comes with a bunch of options to override exact |
| 9 |
|
behaviour to whatever the naming scheme of your .wav files are for instance. |
| 10 |
|
Refer to the new 'wav2.gig' man page for details. |
| 11 |
|
|
| 12 |
|
A long sitting API issue had been mitigated in this release: the ancient |
| 13 |
|
GetFirstFoo() and GetNextFoo() style of methods were always error prone. |
| 14 |
|
Those methods are now marked as deprecated and GetFoo(size_t index) or |
| 15 |
|
GetFooAt(size_t index) methods were added as reentrant-safe replacement. |
| 16 |
|
|
| 17 |
|
Another important multi-threading issue for applications based on libgig have |
| 18 |
|
been addressed on API level: the RIFF::File class now provides a new method |
| 19 |
|
SetIOPerThread(bool enable) to activate a transparent mode of separation for |
| 20 |
|
file streaming by libgig. By default this feature is off and libgig therefore |
| 21 |
|
behaves as in previous releases, which means application threads would |
| 22 |
|
concurrently change file I/O positions when accessing libgig file access |
| 23 |
|
methods simultaniously, like e.g. streaming audio data from disk or loading or |
| 24 |
|
saving any kind of other data from or to the file directly might |
| 25 |
|
unintentionally change threads' file I/O positions between each other. By |
| 26 |
|
activating this new libgig feature, libgig automatically detects individual |
| 27 |
|
threads (as callers of affected libgig methods) and separates the file I/O |
| 28 |
|
positions for each application thread automatically, as if each thread had |
| 29 |
|
opened the file separately by itself. This feature comes with a slight runtime |
| 30 |
|
overhead cost, but has the advantage that it keeps application code simple, as |
| 31 |
|
it usually just requires to add only one line of code to make a multi-threaded |
| 32 |
|
applications work as expected, while still sharing the same libgig objects and |
| 33 |
|
without duplicating data or draining RAM resources. |
| 34 |
|
|
| 35 |
|
The rest of changes are numerous fixes, please refer to ChangeLog for details. |
| 36 |
|
|
| 37 |
Version 4.3.0 (9 May 2021) |
Version 4.3.0 (9 May 2021) |
| 38 |
|
|
| 39 |
From this release on libgig requires at least a C++11 compliant compiler to |
From this release on libgig requires at least a C++11 compliant compiler to |
Parent Directory
| 
Revision Log
| 
Patch