1 |
schoenebeck |
4094 |
Version 4.4.1 (20 Feb 2024) |
2 |
|
|
|
3 |
|
|
Maintenance release. |
4 |
|
|
|
5 |
|
|
Fixes build errors with some compilers only. No behaviour change. |
6 |
|
|
|
7 |
schoenebeck |
4076 |
Version 4.4.0 (26 Jan 2024) |
8 |
|
|
|
9 |
|
|
This release introduces a new command line tool 'wav2gig' which allows to |
10 |
|
|
automatically create a .gig file from a directory of .wav files. This can |
11 |
|
|
safe quite some time when creating a new and large .gig instrument from |
12 |
|
|
scratch, as this tool automatically extracts info such as root note, velocity |
13 |
|
|
and loop points either from the .wav files themselves (if possible), or from |
14 |
|
|
their file names. It comes with a bunch of options to override exact |
15 |
|
|
behaviour to whatever the naming scheme of your .wav files are for instance. |
16 |
|
|
Refer to the new 'wav2.gig' man page for details. |
17 |
|
|
|
18 |
|
|
A long sitting API issue had been mitigated in this release: the ancient |
19 |
|
|
GetFirstFoo() and GetNextFoo() style of methods were always error prone. |
20 |
|
|
Those methods are now marked as deprecated and GetFoo(size_t index) or |
21 |
|
|
GetFooAt(size_t index) methods were added as reentrant-safe replacement. |
22 |
|
|
|
23 |
|
|
Another important multi-threading issue for applications based on libgig have |
24 |
|
|
been addressed on API level: the RIFF::File class now provides a new method |
25 |
|
|
SetIOPerThread(bool enable) to activate a transparent mode of separation for |
26 |
|
|
file streaming by libgig. By default this feature is off and libgig therefore |
27 |
|
|
behaves as in previous releases, which means application threads would |
28 |
|
|
concurrently change file I/O positions when accessing libgig file access |
29 |
|
|
methods simultaniously, like e.g. streaming audio data from disk or loading or |
30 |
|
|
saving any kind of other data from or to the file directly might |
31 |
|
|
unintentionally change threads' file I/O positions between each other. By |
32 |
|
|
activating this new libgig feature, libgig automatically detects individual |
33 |
|
|
threads (as callers of affected libgig methods) and separates the file I/O |
34 |
|
|
positions for each application thread automatically, as if each thread had |
35 |
|
|
opened the file separately by itself. This feature comes with a slight runtime |
36 |
|
|
overhead cost, but has the advantage that it keeps application code simple, as |
37 |
|
|
it usually just requires to add only one line of code to make a multi-threaded |
38 |
|
|
applications work as expected, while still sharing the same libgig objects and |
39 |
|
|
without duplicating data or draining RAM resources. |
40 |
|
|
|
41 |
|
|
The rest of changes are numerous fixes, please refer to ChangeLog for details. |
42 |
|
|
|
43 |
schoenebeck |
3878 |
Version 4.3.0 (9 May 2021) |
44 |
|
|
|
45 |
|
|
From this release on libgig requires at least a C++11 compliant compiler to |
46 |
|
|
build from its sources. Another new requirement is the presence of some UUID |
47 |
|
|
generating function which must be provided by the underlying OS. Previously |
48 |
|
|
the presence of an UUID generating function was optional in libgig for many |
49 |
|
|
years. Its absence in the past only meant that you were unable to load your |
50 |
|
|
own gig files (e.g. created from scratch with Gigedit by yourself) into |
51 |
|
|
Tascam's GigaStudio software, it did not mean though any restriction in |
52 |
|
|
conjunction with LinuxSampler in the past. The latter has changed in this |
53 |
|
|
release. Without UUIDs in gig files you would now also get misbehaviours |
54 |
|
|
even while staying entirely in the Linux eco space, and hence this is now a |
55 |
|
|
hard build requirement for libgig. |
56 |
|
|
|
57 |
|
|
Most of the changes in the gig classes in this release are about gig file |
58 |
|
|
format extensions used by recent versions of LinuxSampler. For instance you |
59 |
|
|
now have much more control over what LFO wave form shall be used (e.g. saw and |
60 |
|
|
square, whereas the original GigaStudio was alwas limited to sine only) and |
61 |
|
|
other LFO parameters like their start phase. There are also a bunch of new |
62 |
|
|
audio filter types available in conjuction with the latest LinuxSampler |
63 |
|
|
version, e.g. additional lowpass filter types with 2, 4 and 6 poles, |
64 |
|
|
additional highpass filters with 1, 2, 4 and 6 poles, a new bandpass filter |
65 |
|
|
with 2 poles and finally also a bandreject filter with 2 poles. Another gig |
66 |
|
|
format extension was added concerning NKSP instrument scripts: LinuxSampler's |
67 |
|
|
new NKSP "patch" variable type is now supported in this version of libgig. |
68 |
|
|
Please refer to the LinuxSampler website for a more detailed explanation about |
69 |
|
|
this new NKSP instrument script feature. |
70 |
|
|
|
71 |
|
|
And as always there are a various fixes in this release, foremost sane output |
72 |
|
|
compatibility with GigaStudio 3 was broken, so that GigaStudio version might |
73 |
|
|
not have accepted gig files changed by you with the prior version of libgig. |
74 |
|
|
This issue is now fixed in this release. |
75 |
|
|
|
76 |
|
|
And last but not least the Serialization framework was extended to support now |
77 |
|
|
various common C++ STL classes like std::string, std::vector, std::map and |
78 |
|
|
std::set out of the box. So no custom code is required aymore to |
79 |
|
|
serialize/deserialize such very common native C++ object types, which reduces |
80 |
|
|
code complexity for serializing/deserializing complex C++ projects a lot. |
81 |
|
|
|
82 |
schoenebeck |
3524 |
Version 4.2.0 (25 Jul 2019) |
83 |
|
|
|
84 |
|
|
This is a maintenance release with important fixes; especially it fixes |
85 |
|
|
issues with gig files in GigaStudio v4 format, however this release also |
86 |
|
|
introduces some few new features and additions. Most notably it is now |
87 |
|
|
possible to write large gig files splitted over extension files (.gx01, |
88 |
|
|
.gx02, ...). Previously it was only possible to read gig files with |
89 |
|
|
extension files, but libgig only supported to save large gig files as one |
90 |
|
|
single, monolithic gig file. The problem with the latter was that gig |
91 |
|
|
files >= 2 GB could only be read by libgig, but could not be loaded with |
92 |
|
|
any version of GigaStudio. So this solves that legacy support issue. |
93 |
|
|
Apart from that, a bunch of convenience methods have been added. |
94 |
|
|
|
95 |
schoenebeck |
3370 |
Version 4.1.0 (25 Nov 2017) |
96 |
|
|
|
97 |
|
|
This release adds support for files much larger than 2 GB for GigaStudio / |
98 |
|
|
Gigasampler (.gig), DLS, as well as for RIFF files in general. This file size |
99 |
|
|
limitation existed for a very long time due to the RIFF format's historical, |
100 |
|
|
internal 32 bit file offsets. To circumvent this file size limitation the |
101 |
|
|
concept of so called "extension files" was added in the past to the |
102 |
|
|
GigaStudio format, which means that the GigaStudio instrument editor splitted |
103 |
|
|
the respective overall instrument file into a set of files (.gig, .gx01, |
104 |
|
|
.gx02, ...), each being max. 2 GB in size, and all of them were expected to be |
105 |
|
|
located in the same directory for the sampler to load the entire large |
106 |
|
|
instrument successfully. libgig always supported only reading such gig |
107 |
|
|
extension files, however libgig never supported to create .gig files with |
108 |
|
|
extension files, nor did it support modifying existing ones. In this release |
109 |
|
|
it was necessary to finally get rid of this overall file size limitation in |
110 |
|
|
libgig. Now when that concept of extension files was introduced years ago, it |
111 |
|
|
made sense at that point, because there were still many systems out there |
112 |
|
|
which still had no support for large files (on either OS or file system |
113 |
|
|
level). However today even on low end mobile devices support for large files |
114 |
|
|
is already a broad standard. Accordingly instead of adding write support for |
115 |
|
|
extension files in libgig, the problem was addressed at its root by |
116 |
|
|
transparently using appropriate, automatic file offset sizes. So when writing |
117 |
|
|
.gig/DLS/RIFF files smaller than 2 GB there are still 32 bit file offsets |
118 |
|
|
being used by libgig. Accordingly such files are still backward compatible |
119 |
|
|
with older software. However if the overall file size to be written is 2 GB or |
120 |
|
|
larger, then 64 bit file offsets are automatically used by libgig instead. |
121 |
|
|
Note though that due to that circumstance such files >= 2 GB are not backward |
122 |
|
|
compatible with older versions of libgig, nor could they be loaded with the |
123 |
|
|
original GigaStudio software. |
124 |
|
|
|
125 |
|
|
Another major new feature in this libgig release is the entirely new |
126 |
|
|
serialization API (Serialization.h) which provides a powerful and easy way |
127 |
|
|
to serialize and deserialize an arbitrary set of native C++ objects into an |
128 |
|
|
abstract data stream. Which means you can simply save the entire runtime state |
129 |
|
|
of an application to a file or send it as data over "wire" (i.e. over network |
130 |
|
|
or to another process) and restore that runtime state from that data there at |
131 |
|
|
any time. In contrast to other C++ serialization frameworks out there, this |
132 |
|
|
framework provides two major benefits: |
133 |
|
|
|
134 |
|
|
1. This serialization framework is designed to be very robust regarding |
135 |
|
|
potential versioning changes of the native C++ classes being |
136 |
|
|
(de)serialized. So even if the C++ classes have seen massive software |
137 |
|
|
changes between the point where they were serialized and the point where |
138 |
|
|
they are to be deserialized; for example if class member variables of |
139 |
|
|
serialized C++ objects were renamed in meantime, or if variable offsets, or |
140 |
|
|
variables' data types had been changed, then the deserialization algorithm |
141 |
|
|
can still cope with such common software changes automatically in many |
142 |
|
|
cases, that is as long as the deserialization algorithm can "guess" what |
143 |
|
|
the changes were exactly. If the serialization framework is unable to |
144 |
|
|
automatically detect the precise software changes, then it will abort the |
145 |
|
|
deserialization task with an exception and an error message stating that |
146 |
|
|
the software versions are incompatible. |
147 |
|
|
|
148 |
|
|
2. This serialization framework supports "partial" deserialization. That |
149 |
|
|
means it not only allows to restore an entire runtime state, but it also |
150 |
|
|
allows to only restore an arbitrary desired subset of information |
151 |
|
|
from the previously serialized data stream, while leaving all other data |
152 |
|
|
of the running C++ objects untouched. The serialization framework also |
153 |
|
|
incorporates a reflection API which allows applications to implement |
154 |
|
|
convenient editors on top of such serialized data, i.e. allowing end users |
155 |
|
|
to pick or alter specific information within the serialized data. |
156 |
|
|
|
157 |
|
|
The new Serialization framework is already embedded into the gig classes of |
158 |
|
|
libgig, and it is used as basis for the new powerful macro features in the |
159 |
|
|
gigedit instrument editor application. Refer to the release notes of |
160 |
|
|
gigedit 1.1.0 for more information about those new macro features in gigedit. |
161 |
|
|
|
162 |
schoenebeck |
2785 |
Version 4.0.0 (14 Jul 2015) |
163 |
|
|
|
164 |
|
|
This major release of libgig adds support for other file formats: |
165 |
|
|
SoundFont 2 (.sf2), KORG multi sample instruments (.KSF, .KMP) and AKAI |
166 |
schoenebeck |
4064 |
format sounds. The AKAI classes are a fork of S��bastien M��trot's libakai and |
167 |
schoenebeck |
2785 |
since it is released under a different license (LGPL) than libgig is (GPL), |
168 |
|
|
the AKAI classes are built as separate DLL file. All other classes of those |
169 |
|
|
new file formats are built and bundled with the existing libgig DLL. Thanks |
170 |
|
|
to Grigor Iliev for his work on the SoundFont 2 classes! Please note that |
171 |
|
|
there is currently no support for KORG's .PCG file format yet. That's because |
172 |
|
|
this file format changes a lot and is not only dependent to the precise KORG |
173 |
|
|
keyboard model, but also to the precise OS version on the same model. And |
174 |
|
|
since basic conversion can also be done by just accessing the .KSF and .KMP |
175 |
|
|
files (sample data, loop informations), the current classes should be |
176 |
|
|
sufficient for many tasks. Adding support for KORG's .PCG files is not |
177 |
|
|
planned at the moment. |
178 |
|
|
|
179 |
|
|
Various new command line tools have been added as well to dump, extract and |
180 |
|
|
convert between all those file formats now. Each one of it has a man page, |
181 |
|
|
so please refer to the respective man page of the individual command line |
182 |
|
|
tool for details. |
183 |
|
|
|
184 |
|
|
The GigaStudio/Gigasampler classes received a load of fixes during the last |
185 |
|
|
six years. And support for features introduced with the last official |
186 |
|
|
GigaStudio 4 software (RIP) were added, for instance support for so called |
187 |
|
|
"iMIDI Rules". Those rules allow i.e. to trigger notes by MIDI CC and to |
188 |
|
|
define a sample set for legato playing style. In the meantime it seems as if |
189 |
|
|
the GigaStudio software has seen its last version with GigaStudio 4, because |
190 |
|
|
Tascam discontinued this product and the intellectual property of GigaStudio |
191 |
|
|
had been sold several times between companies. It is currently not possible |
192 |
|
|
to buy a new copy of GigaStudio anymore and we personally don't expect that |
193 |
|
|
this situation will ever change. |
194 |
|
|
|
195 |
|
|
Does this also mean the end of new features for libgig? Not really! Actually |
196 |
|
|
we already started to add new features to the GigaStudio/Gigasampler format |
197 |
|
|
which never existed with the GigaStudio/Gigasampler software: The most |
198 |
|
|
noteworthy new feature added by us is support for real-time instrument |
199 |
|
|
scripts. These are little "programs" which you can bundle with your .gig |
200 |
|
|
sounds to add a custom behavior to your sounds when playing them with i.e. |
201 |
|
|
LinuxSampler. Find out more about this new major feature on: |
202 |
|
|
|
203 |
|
|
http://doc.linuxsampler.org/Instrument_Scripts/ |
204 |
|
|
|
205 |
|
|
There are also some more minor extensions to the .gig format, for example |
206 |
|
|
support for far more MIDI CC's than originally allowed by the GigaStudio |
207 |
|
|
software. Obviously all those custom extensions will not work with any |
208 |
|
|
version of the official GigaStudio software, those new features will only |
209 |
|
|
work with a recent version of LinuxSampler and gigedit at the moment. |
210 |
|
|
|
211 |
|
|
Besides those major changes, a load of convenient methods have been added to |
212 |
|
|
the existing libgig classes to reduce the overall effort working with all |
213 |
|
|
those file formats with software applications based on libgig. |
214 |
|
|
|
215 |
schoenebeck |
1953 |
Version 3.3.0 (30 Jul 2009) |
216 |
|
|
|
217 |
|
|
Partial support for MIDI rules, the rest are just bug fixes. |
218 |
|
|
|
219 |
schoenebeck |
1549 |
Version 3.2.1 (5 Dec 2007) |
220 |
|
|
|
221 |
|
|
Just some minor performance optimizations. |
222 |
|
|
|
223 |
schoenebeck |
1416 |
Version 3.2.0 (14 Oct 2007) |
224 |
schoenebeck |
1406 |
|
225 |
schoenebeck |
1416 |
This release once again comes with a huge bunch of fixes regarding |
226 |
|
|
Gigasampler write support. Instrument files created from scratch with |
227 |
|
|
libgig can finally be loaded into the Gigasampler application as well. |
228 |
|
|
|
229 |
schoenebeck |
1406 |
libgig's home has moved! From now on you can find it on: |
230 |
|
|
http://www.linuxsampler.org/libgig/ |
231 |
|
|
Please update your links and bookmarks! |
232 |
|
|
|
233 |
schoenebeck |
1116 |
Version 3.1.1 (24 Mar 2007) |
234 |
|
|
|
235 |
|
|
This is a bugfix release, fixing one important bug regarding gig v3 |
236 |
|
|
support (custom split points) and a lot of bugs regarding .gig write |
237 |
|
|
support. And this is the first official release for the Windows platform. |
238 |
|
|
|
239 |
schoenebeck |
933 |
Version 3.1.0 (24 Nov 2006) |
240 |
schoenebeck |
860 |
|
241 |
|
|
libgig's home has moved (slightly) from |
242 |
|
|
http://stud.fh-heilbronn.de/~cschoene/projects/libgig/ to |
243 |
|
|
http://stud.hs-heilbronn.de/~cschoene/projects/libgig/, please update your |
244 |
|
|
links and bookmarks! This is due to the recent renaming of the University |
245 |
|
|
of Heilbronn, which kindly hosts this and other projects. |
246 |
|
|
|
247 |
schoenebeck |
854 |
Version 3.0.0 (28 Apr 2006) |
248 |
|
|
|
249 |
|
|
This is the first release which allows to create new and modify existing |
250 |
|
|
.gig files. Beside that it also includes another bunch of bug fixes and |
251 |
|
|
Gigasampler v3 support improvements. |