1 |
<html> |
2 |
<head> |
3 |
<meta name="author" content="Christian Schoenebeck"> |
4 |
<title>Release Notes LinuxSampler 2.1.0</title> |
5 |
<navpath>LinuxSampler 2.1.0</navpath> |
6 |
<meta name="description" content="Release notes for LinuxSampler 2.1.0."> |
7 |
<link rel="stylesheet" href="http://doc.linuxsampler.org/css/preview.css"> |
8 |
<script type="text/javascript" src="http://doc.linuxsampler.org/js/preview.js"></script> |
9 |
</head> |
10 |
<body> |
11 |
<h1>LinuxSampler 2.1.0</h1> |
12 |
<p> |
13 |
LinuxSampler 2.1.0 and friends were released on November 25th 2017. |
14 |
Two years have passed since the last release of LinuxSampler. |
15 |
Here is a summary about what's new. |
16 |
</p> |
17 |
|
18 |
<h3>Real-Time Instrument Scripts</h3> |
19 |
<p> |
20 |
In the <a href="01_linuxsampler_2_0_0.html">previous release</a> a major |
21 |
new feature called <i>Real-Time Instrument Scripts</i> was added, which |
22 |
are essentially small programs that may be bundled with sound files to extend the |
23 |
sampler with custom behavior specifically intended for individual sounds. |
24 |
<a href="instrument_scripts.html">Find out more ...</a> |
25 |
</p> |
26 |
<p> |
27 |
These programs are written by sound designers in a script language called |
28 |
<a href="01_nksp.html">NKSP</a>. |
29 |
In this release a large amount of extensions and improvements have been |
30 |
added for this real-time instrument scripting support of LinuxSampler. |
31 |
For example 48 new built-in NKSP functions and 21 new built-in NKSP |
32 |
variables have been added. |
33 |
<a href="01_nksp_reference.html">Find out more ...</a> |
34 |
</p> |
35 |
<p> |
36 |
Also the NKSP language and the underlying engine itself was extended. |
37 |
Most notably the script engine now has an execution scheduler which is |
38 |
the basis for many of the timing relevant new NKSP features in this |
39 |
release, like programmatically suspending and resuming scripts for an |
40 |
exact duration or at an exact point of time or triggering or killing notes |
41 |
at very precise times (all with microsecond accuracy). |
42 |
You can now even launch new threads in your NKSP scripts by |
43 |
calling the new built-in function <code lang="nksp">fork()</code>. |
44 |
Furthermore |
45 |
<a href="01_nksp.html#boolean_operators">bitwise operators</a> |
46 |
have been added to NKSP, as well as support for |
47 |
read only built-in variables, |
48 |
<a href="01_nksp.html#synchronized_blocks">"synchronized" code blocks</a> |
49 |
, as well as |
50 |
<a href="01_nksp.html#user_functions">user declared functions</a> |
51 |
and user declared const array variables have been added to the NKSP language, |
52 |
and finally automatic suspension of RT threatening scripts by the RT script engine |
53 |
has been implemented. The latter ensures that the sampler remains stable, |
54 |
and does not cause audio dropouts, even while you are working on heavy and |
55 |
extremely buggy scripts. |
56 |
Also syntax error messages with NKSP scripts have |
57 |
been improved to output more clear and user friendly error messages, as |
58 |
well as the NKSP editor API has been improved which brings handy new features |
59 |
to gigedit's NKSP script editor, which will further be described below, |
60 |
along with gigedit's new features. |
61 |
</p> |
62 |
|
63 |
<h3>SFZ Engine</h3> |
64 |
<p> |
65 |
The SFZ engine now supports <code lang="sfz"><global></code>, |
66 |
<code lang="sfz"><master></code> sections, |
67 |
<code lang="sfz">#define</code> statement and <code lang="sfz">set_ccN</code> |
68 |
opcode. And finally the SFZ engine now supports NKSP real-time |
69 |
instrument scripts as well by adding a new |
70 |
<code lang="sfz">script</code> opcode for this purpose. So NKSP scripts |
71 |
are no longer limited to our Giga engine. |
72 |
</p> |
73 |
|
74 |
<h3>New GigaStudio format features</h3> |
75 |
<p> |
76 |
The equally named software on Windows has gone years ago, |
77 |
but the format lives on with LinuxSampler and this release adds |
78 |
yet some more new extensions to the gig format. Most notably you |
79 |
now have options to control envelope generators' state machines. |
80 |
For example you can now define whether a certain EG state should |
81 |
either be aborted or continued to its end when a note off arrived. |
82 |
These controls are especially useful for certain kinds of sounds |
83 |
like percussive instruments. |
84 |
<p> |
85 |
<img src="gigedit_state_machine_options.png" caption="EG State Machine Options (Gigedit)"> |
86 |
</p> |
87 |
Accordingly you will now find new check boxes for this in gigedit. |
88 |
As these are extensions of the original format, setting these options |
89 |
will only work with LinuxSampler and would be ignored with the |
90 |
original GigaStudio software. |
91 |
</p> |
92 |
|
93 |
<h3>Instruments DB</h3> |
94 |
<p> |
95 |
Also the Instruments Database feature has received important maintenance |
96 |
fixes. Before this release, the instrument DB feature was barely usable |
97 |
for quite some time. Fundamental instruments DB issues have been fixed in |
98 |
this release to finally consider this feature stable again as well. |
99 |
</p> |
100 |
|
101 |
|
102 |
<h2>Gigedit 1.1.0</h2> |
103 |
<p> |
104 |
Also <i>Gigedit</i>, our instrument editor for the GigaStudio/Gigasampler |
105 |
format, had been enhanced quite a lot. The most important new features are |
106 |
summarized next. |
107 |
</p> |
108 |
|
109 |
<h3>Script Editor</h3> |
110 |
<p> |
111 |
Gigedit's integrated instrument script editor supports now tight coupling |
112 |
directly with LinuxSampler's actual real-time instrument script backend. |
113 |
That provides several improvements for the script editor. |
114 |
</p> |
115 |
<p> |
116 |
<img src="nksp_editor_error_tooltip.png" caption="NKSP Error Tooltips"> |
117 |
For example |
118 |
colored syntax highlighting of scripts is now always displayed correctly and |
119 |
simply looks much better now. Previously there was some small hard coded |
120 |
script parser code on Gigedit's side which however was buggy and simply |
121 |
did no great job. Now all the heavy lifting of handling all the details |
122 |
of the numerous NKSP language aspects are handled by the sampler instead, |
123 |
which also provides the following new script editor features. |
124 |
</p> |
125 |
<p> |
126 |
Due to that direct coupling with LinuxSampler's |
127 |
script backend, gigedit's script editor now shows all issues related to the script (errors |
128 |
and warnings) directly within the script editor in real-time while you are |
129 |
typing. The actual erroneous locations of the script are automatically |
130 |
highlighted with red background color, locations of the script with |
131 |
warnings are automatically highlighted with yellow background color, and |
132 |
when you move your mouse over the respective code location, the precise |
133 |
error/warning message is displayed as a tooltip. And last but not least |
134 |
there is a summary of issues displayed in the status bar of the script |
135 |
editor. Since LinuxSampler's instrument script backend is actually doing |
136 |
all the work for the script editor, all aspects of the language, all |
137 |
details about built-in functions and variables, and all potential issues |
138 |
with their precise cause and messages are automatically covered by the |
139 |
script editor now. |
140 |
That way you immediately know whether or whether not your script |
141 |
is OK with every character you are typing, and without requiring to |
142 |
actually load the script with an instrument into the sampler. |
143 |
</p> |
144 |
<p> |
145 |
<img src="nksp_editor_strike_through.png" caption="NKSP Disabled Code Blocks"> |
146 |
Additionally when clicking on the |
147 |
script editor's "Apply" button or using Ctrl+S keyboard shortcut, then |
148 |
the script is automatically reloaded by the sampler. So you no longer |
149 |
have to reload the respective instrument manually while you are |
150 |
developing instrument scripts. There are also visual enhancements for the |
151 |
script editor, for example the line numbers are now shown on the left, |
152 |
the font size can be altered by the user, and unused code portions (i.e. |
153 |
disabled by <a href="">NKSP preprocessor statements</a>) |
154 |
are automatically striked through. That way you can immediately see |
155 |
which code portions of your scripts are actually used, and which are not.<br> |
156 |
<br> |
157 |
As as side note, you may have noticed a handy new built-in preprocessor |
158 |
condition in LinuxSampler 2.1.0 which can be enabled with |
159 |
<code lang="nksp">SET_CONDITION(NKSP_NO_MESSAGE)</code> and allows you |
160 |
to quickly disable <code lang="nksp">message()</code> function calls, |
161 |
i.e. to conviently switch your scripts between a debug and release mode. |
162 |
<a href="01_nksp.html#disable_messages">Find out more ...</a> |
163 |
</p> |
164 |
|
165 |
<h3>Macros</h3> |
166 |
<p> |
167 |
Another major new feature in this release are macros. |
168 |
A macro is a set of changes that should be applied to currently selected instrument. |
169 |
</p> |
170 |
<p> |
171 |
<img src="gigedit_macros_setup.png" caption="Macro List (Gigedit)"> |
172 |
Such macros can be reviewed and edited, and they can be saved permanently for |
173 |
example as templates for common instrument creation tasks. Macros can be |
174 |
assigned to F keys on the keyboard so that they can be quickly triggered, |
175 |
you can transfer them over the OS clipboard and you can write comments |
176 |
to your macros so that you never forget what kind of purpose you had in |
177 |
mind for them. The macro features are based on libgig's new |
178 |
"Serialization" framework (described below) and accordingly you need at |
179 |
least libgig 4.1.0 for using these macro features. |
180 |
</p> |
181 |
<p> |
182 |
<img src="gigedit_macro_editor.png" caption="Macro Editor (Gigedit)"> |
183 |
This is an example of editing a macro. Usually you may start creating a |
184 |
new macro by simply taking all parameters of a selected dimension region. |
185 |
Then in the macro editor you usually multi-row select (i.e. by Ctrl clicking |
186 |
items in the list) just the parameters you want this macro to alter, then |
187 |
click on "Inverse Delete" to just keep those few selected parameters in |
188 |
that macro. As a result, when you are going to apply this macro during your |
189 |
upcoming work, only those few parameters are modifed by this macro and all |
190 |
other ones are left untouched. |
191 |
Of course you can also alter the individual parameter values in |
192 |
this editor as well. |
193 |
</p> |
194 |
|
195 |
<h3>Persistent Settings</h3> |
196 |
<p> |
197 |
All user settings of gigedit are now persistently saved and automatically |
198 |
restored. This also includes gigedit's windows' dimensions and positions. |
199 |
</p> |
200 |
|
201 |
<h3>Multi-Row Selection</h3> |
202 |
<p> |
203 |
<img src="gigedit_multi_row_action.png" caption="Multi Row Selection & Actions (Gigedit)"> |
204 |
Multi-row selection has been added to all list views now, so you can now |
205 |
more efficiently apply actions to multiple samples, instruments or scripts |
206 |
simultaneously at once, instead of requesting those actions for each item |
207 |
individually. |
208 |
</p> |
209 |
|
210 |
<h3>Multi-Zone Selection</h3> |
211 |
<p> |
212 |
<img src="gigedit_multi_dimreg_zone_actions.png" caption="Multi Zone Selection & Actions (Gigedit)"> |
213 |
Also modifying key features of several dimension region zones |
214 |
simultaneously is now supported. That means you can now delete, split and |
215 |
resize multiple dimension region zones at once. Oh yes, I forget, Ctrl+click |
216 |
selecting multiple dimension regions is supported now as well. |
217 |
</p> |
218 |
|
219 |
<h3>Feature Icons</h3> |
220 |
<p> |
221 |
<img src="gigedit_zone_icons.png" caption="Feature Icons (Gigedit)"> |
222 |
You will also note that there are now icons displayed on the individual |
223 |
regions and dimension region zones. Those icons visualize common key |
224 |
features of regions and dimension region zones. For example if you forgot |
225 |
to assign any sample to one of them, then you will see a red dot on the |
226 |
respective region or dimension region zone. Another icon type is showing |
227 |
you whether a region or dimension region zone uses a sample loop. |
228 |
For example when you just imported a drum sample, you don't really want |
229 |
a loop to be on. |
230 |
This way |
231 |
you can immediately see and control the key features of all regions |
232 |
and their dimension region zones, without requiring to browse through all |
233 |
of them individually. |
234 |
</p> |
235 |
|
236 |
<h3>Keyboard Shortcuts</h3> |
237 |
<p> |
238 |
Various new keyboard shortcuts have been added so you can work more |
239 |
efficiently on your sounds. For example you can now use Ctrl+Left and |
240 |
Ctrl+Right to navigate through all regions of the currently selected |
241 |
instrument, and likewise you can use Alt+Left, Alt+Right, Alt+Up and |
242 |
Alt+Down to navigate through all dimension region zones of the currently |
243 |
selected region. Since there are many actions that can be either applied |
244 |
on instrument level, or on region level, or on dimension region level, as |
245 |
a general rule, for all keyboard shortcuts: |
246 |
<ul> |
247 |
<li><b>Shift</b> key is used for actions on instrument level</li> |
248 |
<li><b>Ctrl</b> key is used on region level</li> |
249 |
<li><b>Alt</b> key is used by gigedit for actions on dimension region level</li> |
250 |
</ul> |
251 |
So as another example you may copy all parameters of the currently |
252 |
selected dimension region zone by hitting Alt+C, then you might select |
253 |
another dimension region zone, or another instrument and then use Alt+V |
254 |
to apply the parameters from the clipboard. While the parameters are |
255 |
(as macro actually) on the clipboard you can also review, edit and |
256 |
delete the individual parameters before applying them. As a final |
257 |
example for new important shortcuts you may now use Shift+Up and |
258 |
Shift+Down for switching between instruments. |
259 |
</p> |
260 |
|
261 |
<h3>Combine Tool Improvements</h3> |
262 |
<p> |
263 |
<img src="gigedit_combine_tool_reorder.png" caption="Combine Tool (Gigedit)"> |
264 |
Also the Combine Tool has been improved. You can now simply select the |
265 |
(multiple) instruments you want to combine directly from the applications |
266 |
main window, i.e. by Ctrl or Shift clicking them from the instruments |
267 |
list view, and then right click to call the combine tool on that |
268 |
selection. The Combine Tool now also shows you as preview the order in |
269 |
which the selected instruments are going to be combined. This is |
270 |
especially useful when combining instruments with certain dimension |
271 |
types where the order matters for the actual resulting sound; for example |
272 |
when using the velocity dimension. Simply use drag n drop to reorder |
273 |
the previously selected instruments before combining them. |
274 |
</p> |
275 |
|
276 |
<h3>Search Filter</h3> |
277 |
<p> |
278 |
<img src="gigedit_search_filter.png" caption="Search Filter (Gigedit)"> |
279 |
And last but not least a filter option field had been added to the |
280 |
instruments list and samples list, which allows you to find specific |
281 |
samples and instruments very quickly by typing search key words, which is |
282 |
especially very helpful in case you are working on gig files which contain |
283 |
a very large amount of samples or instruments in a single gig file |
284 |
(like this one, which apparently has far more than 400 instruments). |
285 |
</p> |
286 |
|
287 |
<h2>libgig 4.1.0</h2> |
288 |
<p> |
289 |
Our fundamental file access C++ library |
290 |
<a href="http://download.linuxsampler.org/doc/libgig/api/">libgig</a> |
291 |
has also received some major improvements, which are outlined next. |
292 |
</p> |
293 |
|
294 |
<h3>Files larger than 2 GB</h3> |
295 |
<p> |
296 |
libgig 4.1.0 adds support for files much larger than 2 GB for GigaStudio / |
297 |
Gigasampler (.gig), DLS, as well as for RIFF files in general. This file size |
298 |
limitation existed for a very long time due to the RIFF format's historical, |
299 |
internal 32 bit file offsets. To circumvent this file size limitation the |
300 |
concept of so called "extension files" was added in the past to the |
301 |
GigaStudio format, which means that the GigaStudio instrument editor |
302 |
(the original one on Windows) splitted |
303 |
the respective overall instrument file into a set of files (.gig, .gx01, |
304 |
.gx02, ...), each being max. 2 GB in size, and all of them were expected to be |
305 |
located in the same directory for the sampler to load the entire large |
306 |
instrument successfully. libgig always supported only reading such gig |
307 |
extension files, however libgig never supported to create .gig files with |
308 |
extension files, nor did it support modifying existing ones. |
309 |
<p> |
310 |
</p> |
311 |
In this release |
312 |
it was necessary to finally get rid of this overall file size limitation in |
313 |
libgig. Now when that concept of extension files was introduced years ago, it |
314 |
made sense at that point, because there were still many systems out there |
315 |
which still had no support for large files (on either OS or file system |
316 |
level). However today even on low end mobile devices support for large files |
317 |
is already a broad standard. Accordingly instead of adding write support for |
318 |
extension files in libgig, the problem was addressed at its root by |
319 |
transparently using appropriate, automatic file offset sizes. So when writing |
320 |
.gig/DLS/RIFF files smaller than 2 GB there are still 32 bit file offsets |
321 |
being used by libgig. Accordingly such files are still backward compatible |
322 |
with older software. However if the overall file size to be written is 2 GB or |
323 |
larger, then 64 bit file offsets are automatically used by libgig instead. |
324 |
Note though that due to that circumstance such files ≧ 2 GB are not backward |
325 |
compatible with older versions of libgig, nor could they be loaded with the |
326 |
original GigaStudio software. |
327 |
</p> |
328 |
|
329 |
<h3>Serialization API</h3> |
330 |
<p> |
331 |
Another major new feature in this libgig release is the entirely new |
332 |
<a href="http://download.linuxsampler.org/doc/libgig/api/namespaceSerialization.html">Serialization API</a> |
333 |
which provides a powerful and easy way |
334 |
to serialize and deserialize an arbitrary set of native C++ objects into an |
335 |
abstract data stream. Which means you can simply save the entire runtime state |
336 |
of an application to a file or send it as data over "wire" (i.e. over network |
337 |
or to another process) and restore that runtime state from that data there at |
338 |
any time. In contrast to other C++ serialization frameworks out there, this |
339 |
framework provides two major benefits: |
340 |
<ol> |
341 |
<li> |
342 |
This serialization framework is designed to be very robust regarding |
343 |
potential versioning changes of the native C++ classes being |
344 |
(de)serialized. So even if the C++ classes have seen massive software |
345 |
changes between the point where they were serialized and the point where |
346 |
they are to be deserialized; for example if class member variables of |
347 |
serialized C++ objects were renamed in meantime, or if variable offsets, or |
348 |
variables' data types had been changed, then the deserialization algorithm |
349 |
can still cope with such common software changes automatically in many |
350 |
cases, that is as long as the deserialization algorithm can "guess" what |
351 |
the changes were exactly. If the serialization framework is unable to |
352 |
automatically detect the precise software changes, then it will abort the |
353 |
deserialization task with an exception and an error message stating that |
354 |
the software versions are incompatible. |
355 |
</li> |
356 |
<li> |
357 |
This serialization framework supports "partial" deserialization. That |
358 |
means it not only allows to restore an entire runtime state, but it also |
359 |
allows to only restore an arbitrary desired subset of information |
360 |
from the previously serialized data stream, while leaving all other data |
361 |
of the running C++ objects untouched. The serialization framework also |
362 |
incorporates a reflection API which allows applications to implement |
363 |
convenient editors on top of such serialized data, i.e. allowing end users |
364 |
to pick or alter specific information within the serialized data. |
365 |
</li> |
366 |
</ol> |
367 |
This new Serialization framework is already embedded into the gig classes of |
368 |
libgig, and it is used as basis for the new powerful macro features in the |
369 |
gigedit instrument editor, like already outlined above. |
370 |
</p> |
371 |
|
372 |
</body> |
373 |
</html> |