| 1 |
|
Version 4.1.0 (25 Nov 2017) |
| 2 |
|
|
| 3 |
|
This release adds support for files much larger than 2 GB for GigaStudio / |
| 4 |
|
Gigasampler (.gig), DLS, as well as for RIFF files in general. This file size |
| 5 |
|
limitation existed for a very long time due to the RIFF format's historical, |
| 6 |
|
internal 32 bit file offsets. To circumvent this file size limitation the |
| 7 |
|
concept of so called "extension files" was added in the past to the |
| 8 |
|
GigaStudio format, which means that the GigaStudio instrument editor splitted |
| 9 |
|
the respective overall instrument file into a set of files (.gig, .gx01, |
| 10 |
|
.gx02, ...), each being max. 2 GB in size, and all of them were expected to be |
| 11 |
|
located in the same directory for the sampler to load the entire large |
| 12 |
|
instrument successfully. libgig always supported only reading such gig |
| 13 |
|
extension files, however libgig never supported to create .gig files with |
| 14 |
|
extension files, nor did it support modifying existing ones. In this release |
| 15 |
|
it was necessary to finally get rid of this overall file size limitation in |
| 16 |
|
libgig. Now when that concept of extension files was introduced years ago, it |
| 17 |
|
made sense at that point, because there were still many systems out there |
| 18 |
|
which still had no support for large files (on either OS or file system |
| 19 |
|
level). However today even on low end mobile devices support for large files |
| 20 |
|
is already a broad standard. Accordingly instead of adding write support for |
| 21 |
|
extension files in libgig, the problem was addressed at its root by |
| 22 |
|
transparently using appropriate, automatic file offset sizes. So when writing |
| 23 |
|
.gig/DLS/RIFF files smaller than 2 GB there are still 32 bit file offsets |
| 24 |
|
being used by libgig. Accordingly such files are still backward compatible |
| 25 |
|
with older software. However if the overall file size to be written is 2 GB or |
| 26 |
|
larger, then 64 bit file offsets are automatically used by libgig instead. |
| 27 |
|
Note though that due to that circumstance such files >= 2 GB are not backward |
| 28 |
|
compatible with older versions of libgig, nor could they be loaded with the |
| 29 |
|
original GigaStudio software. |
| 30 |
|
|
| 31 |
|
Another major new feature in this libgig release is the entirely new |
| 32 |
|
serialization API (Serialization.h) which provides a powerful and easy way |
| 33 |
|
to serialize and deserialize an arbitrary set of native C++ objects into an |
| 34 |
|
abstract data stream. Which means you can simply save the entire runtime state |
| 35 |
|
of an application to a file or send it as data over "wire" (i.e. over network |
| 36 |
|
or to another process) and restore that runtime state from that data there at |
| 37 |
|
any time. In contrast to other C++ serialization frameworks out there, this |
| 38 |
|
framework provides two major benefits: |
| 39 |
|
|
| 40 |
|
1. This serialization framework is designed to be very robust regarding |
| 41 |
|
potential versioning changes of the native C++ classes being |
| 42 |
|
(de)serialized. So even if the C++ classes have seen massive software |
| 43 |
|
changes between the point where they were serialized and the point where |
| 44 |
|
they are to be deserialized; for example if class member variables of |
| 45 |
|
serialized C++ objects were renamed in meantime, or if variable offsets, or |
| 46 |
|
variables' data types had been changed, then the deserialization algorithm |
| 47 |
|
can still cope with such common software changes automatically in many |
| 48 |
|
cases, that is as long as the deserialization algorithm can "guess" what |
| 49 |
|
the changes were exactly. If the serialization framework is unable to |
| 50 |
|
automatically detect the precise software changes, then it will abort the |
| 51 |
|
deserialization task with an exception and an error message stating that |
| 52 |
|
the software versions are incompatible. |
| 53 |
|
|
| 54 |
|
2. This serialization framework supports "partial" deserialization. That |
| 55 |
|
means it not only allows to restore an entire runtime state, but it also |
| 56 |
|
allows to only restore an arbitrary desired subset of information |
| 57 |
|
from the previously serialized data stream, while leaving all other data |
| 58 |
|
of the running C++ objects untouched. The serialization framework also |
| 59 |
|
incorporates a reflection API which allows applications to implement |
| 60 |
|
convenient editors on top of such serialized data, i.e. allowing end users |
| 61 |
|
to pick or alter specific information within the serialized data. |
| 62 |
|
|
| 63 |
|
The new Serialization framework is already embedded into the gig classes of |
| 64 |
|
libgig, and it is used as basis for the new powerful macro features in the |
| 65 |
|
gigedit instrument editor application. Refer to the release notes of |
| 66 |
|
gigedit 1.1.0 for more information about those new macro features in gigedit. |
| 67 |
|
|
| 68 |
Version 4.0.0 (14 Jul 2015) |
Version 4.0.0 (14 Jul 2015) |
| 69 |
|
|
| 70 |
This major release of libgig adds support for other file formats: |
This major release of libgig adds support for other file formats: |
Parent Directory
| 
Revision Log
| 
Patch