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 <b>48 new built-in functions</b> and <b>21 new built-in |
32 |
variables</b> 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 |
<p> |
74 |
And yes, as you can see from the SFZ opcode links here, we also |
75 |
started documenting the actual SFZ file format. You wanna help us |
76 |
on completing the SFZ file format documentation? Great! Have a look |
77 |
at <a href="01_writing_docs.html">how articles are written for this site</a> and |
78 |
<a href="https://sourceforge.net/projects/linuxsampler/lists/linuxsampler-devel">get in touch with us</a>! |
79 |
</p> |
80 |
|
81 |
<h3>New GigaStudio format features</h3> |
82 |
<p> |
83 |
The equally named software on Windows has gone years ago, |
84 |
but the format lives on with LinuxSampler and this release adds |
85 |
yet some more new extensions to the gig format. |
86 |
</p> |
87 |
<p> |
88 |
<img src="gigedit_state_machine_options.png" title="EG State Machine Options (Gigedit)"> |
89 |
Most notably you |
90 |
now have options to control envelope generators' state machines. |
91 |
For example you can now define whether a certain EG state should |
92 |
either be aborted or continued to its end when a note off arrived |
93 |
(or on a note on in the release stage). |
94 |
These controls are especially useful for certain kinds of sounds |
95 |
like percussive instruments.<br> |
96 |
<br> |
97 |
Accordingly you will now find new check boxes for this in gigedit. |
98 |
As these are extensions of the original format, setting these options |
99 |
will only work with LinuxSampler and would be ignored with the |
100 |
original GigaStudio software. |
101 |
</p> |
102 |
|
103 |
<h3>Instruments DB</h3> |
104 |
<p> |
105 |
Also the Instruments Database feature has received important maintenance |
106 |
fixes. Before this release, the instrument DB feature was barely usable |
107 |
for quite some time. Fundamental instruments DB issues have been fixed in |
108 |
this release to finally consider this feature stable again as well. |
109 |
</p> |
110 |
|
111 |
|
112 |
<h2>Gigedit 1.1.0</h2> |
113 |
<p> |
114 |
Also <i>Gigedit</i>, our instrument editor for the GigaStudio/Gigasampler |
115 |
format, had been enhanced quite a lot. The most important new features are |
116 |
summarized next. |
117 |
</p> |
118 |
|
119 |
<h3>Script Editor</h3> |
120 |
<p> |
121 |
Gigedit's integrated instrument script editor supports now tight coupling |
122 |
directly with LinuxSampler's actual real-time instrument script backend. |
123 |
That provides several improvements for the script editor. |
124 |
</p> |
125 |
<p> |
126 |
<img src="nksp_editor_error_tooltip.png" title="NKSP Error Tooltips"> |
127 |
For example |
128 |
colored syntax highlighting of scripts is now always displayed correctly and |
129 |
simply looks much better now. Previously there was some small hard coded |
130 |
script parser code on Gigedit's side which however was buggy and simply |
131 |
did no great job. Now all the heavy lifting of handling all the details |
132 |
of the numerous NKSP language aspects are handled by the sampler instead, |
133 |
which also provides the following new script editor features.<br> |
134 |
<br> |
135 |
Due to that direct coupling with LinuxSampler's |
136 |
script backend, gigedit's script editor now shows all issues related to the script (errors |
137 |
and warnings) directly within the script editor in real-time while you are |
138 |
typing. The actual erroneous locations of the script are automatically |
139 |
highlighted with red background color, locations of the script with |
140 |
warnings are automatically highlighted with yellow background color, and |
141 |
when you move your mouse over the respective code location, the precise |
142 |
error/warning message is displayed as a tooltip. And last but not least |
143 |
there is a summary of issues displayed in the status bar of the script |
144 |
editor. Since LinuxSampler's instrument script backend is actually doing |
145 |
all the work for the script editor, all aspects of the language, all |
146 |
details about built-in functions and variables, and all potential issues |
147 |
with their precise cause and messages are automatically covered by the |
148 |
script editor now. |
149 |
That way you immediately know whether or whether not your script |
150 |
is OK with every character you are typing, and without requiring to |
151 |
actually load the script with an instrument into the sampler. |
152 |
</p> |
153 |
<p> |
154 |
<img src="nksp_editor_strike_through.png" title="NKSP Disabled Code Blocks"> |
155 |
Additionally when clicking on the |
156 |
script editor's "Apply" button or using Ctrl+S keyboard shortcut, then |
157 |
the script is automatically reloaded by the sampler. So you no longer |
158 |
have to reload the respective instrument manually while you are |
159 |
developing instrument scripts.<br> |
160 |
<br> |
161 |
There are also visual enhancements for the |
162 |
script editor, for example the line numbers are now shown on the left, |
163 |
the font size can be altered by the user, and unused code portions (i.e. |
164 |
disabled by <a href="01_nksp.html#preprocessor_statements">NKSP preprocessor statements</a>) |
165 |
are automatically striked through. That way you can immediately see |
166 |
which code portions of your scripts are actually used, and which are not. |
167 |
Everything you see striked through is completely ignored by the sampler.<br> |
168 |
<br> |
169 |
As as side note, you may have noticed a handy new built-in preprocessor |
170 |
condition in LinuxSampler 2.1.0 which can be enabled with |
171 |
<code lang="nksp">SET_CONDITION(NKSP_NO_MESSAGE)</code> and allows you |
172 |
to quickly disable <code lang="nksp">message()</code> function calls, |
173 |
i.e. to conviently switch your scripts between a debug and release mode. |
174 |
<a href="01_nksp.html#disable_messages">Find out more ...</a> |
175 |
</p> |
176 |
|
177 |
<h3>Macros</h3> |
178 |
<p> |
179 |
Another major new feature in this release are macros. |
180 |
A macro is a set of changes that should be applied to the currently selected instrument. |
181 |
</p> |
182 |
<p> |
183 |
<img src="gigedit_macros_setup.png" title="Macro List (Gigedit)"> |
184 |
Such macros can be reviewed and edited, and they can be saved permanently |
185 |
as templates or shortcuts for common instrument creation tasks. Macros can be |
186 |
assigned to F keys on the keyboard so that they can quickly be triggered, |
187 |
you can transfer them over the OS clipboard and you can write comments |
188 |
to your macros so that you never forget what kind of purpose you had in |
189 |
mind for them. Your macros will also appear in the application's menu, |
190 |
and when you move the mouse pointer over a macro, a tooltop appears with |
191 |
the comments you wrote for that macro.<br> |
192 |
<br> |
193 |
The macro features are based on libgig's new |
194 |
"Serialization" framework (described below) and accordingly you need at |
195 |
least libgig 4.1.0 for using these macro features. |
196 |
</p> |
197 |
<p> |
198 |
<img src="gigedit_macro_editor.png" title="Macro Editor (Gigedit)"> |
199 |
This is an example of editing a macro. Usually you may start creating a |
200 |
new macro by simply taking all parameters of a selected dimension region. |
201 |
Then in the macro editor you usually multi-row select (i.e. by Ctrl clicking |
202 |
items in the list) just the parameters you want this macro to alter, then |
203 |
click on "Inverse Delete" to just keep those few selected parameters in |
204 |
that macro. As a result, when you are going to apply this macro during your |
205 |
upcoming work, only those few parameters are modifed by this macro and all |
206 |
other ones are left untouched. |
207 |
Of course you can also alter the individual parameter values in |
208 |
this macro editor as well.<br> |
209 |
<br> |
210 |
You might now think, wait a minute, does such a macro change the entire |
211 |
instrument, or only a portion of it? The answer is simple: you decide! |
212 |
The precise scope a macro is going to modify behaves exactly the same like |
213 |
you manually changed individual parameters in Gigedit before. That means |
214 |
for example when you check the two check boxes "all regions" and "all dimension splits", |
215 |
then when you trigger a macro, it is going to be applied against the entire instrument. |
216 |
If you uncheck those check boxes and select only one specific region and one specific |
217 |
dimension region zone, then the macro only modifies this single dimension |
218 |
region zone. Or yet another alternative: Ctrl+click the precise dimension |
219 |
region zones you want to be changed by the macro and then trigger the macro, i.e. |
220 |
by hitting the macro's F key on the keyboard, or by selecting the macro from |
221 |
the main menu.<br> |
222 |
<br> |
223 |
So as you might see, macros introduce a powerful way for you to create yourself |
224 |
a personal instrument construction kit, not limited to only creating global |
225 |
templates for entire instruments, but also for an arbitrary set of small and large |
226 |
building blocks in any size and complexity you need. For example you may create a macro |
227 |
which only sets one single parameter, and another macro which configures an entire filter |
228 |
block with all its filter parameters and MIDI controllers, up to a macro which really |
229 |
modifies every single parameter to build up an entire instrument with one stroke |
230 |
of a key. |
231 |
</p> |
232 |
|
233 |
<h3>Persistent Settings</h3> |
234 |
<p> |
235 |
All user settings of gigedit are now persistently saved and automatically |
236 |
restored. This also includes gigedit's windows' dimensions and positions, |
237 |
and of course including all macros you create. |
238 |
</p> |
239 |
|
240 |
<h3>Multi-Row Selection</h3> |
241 |
<p> |
242 |
<img src="gigedit_multi_row_action.png" title="Multi Row Selection & Actions (Gigedit)"> |
243 |
Multi-row selection has been added to all list views now, so you can now |
244 |
more efficiently apply actions to multiple samples, instruments or scripts |
245 |
simultaneously at once, instead of requesting those actions for each item |
246 |
individually. This works exactly like you are used to from other applications. |
247 |
So i.e. press and hold the Ctrl key while clicking with the mouse on the |
248 |
individual instruments (or samples) from the list view. Or press and hold |
249 |
the Shift key and click on an item from the list to select an entire range |
250 |
instead with one click. |
251 |
</p> |
252 |
|
253 |
<h3>Multi-Zone Selection</h3> |
254 |
<p> |
255 |
<img src="gigedit_multi_dimreg_zone_actions.png" title="Multi Zone Selection & Actions (Gigedit)"> |
256 |
Also modifying key features of several dimension region zones |
257 |
simultaneously is now supported. That means you can now delete, split and |
258 |
resize multiple dimension region zones at once. Oh yes, I forget, Ctrl+click |
259 |
selecting multiple dimension region zones is supported now as well. For the |
260 |
latter there is also a keyboard shortcut now: Hit and hold the Alt and Shift |
261 |
keys, then use the left and right arrow keys to multi select the dimension |
262 |
region zones you need. |
263 |
</p> |
264 |
|
265 |
<h3>Feature Icons</h3> |
266 |
<p> |
267 |
<img src="gigedit_zone_icons.png" title="Feature Icons (Gigedit)"> |
268 |
You will also note that there are now icons displayed on the individual |
269 |
regions and dimension region zones. Those icons visualize common key |
270 |
features of regions and dimension region zones. For example if you forgot |
271 |
to assign any sample to one of them, then you will see a red dot on the |
272 |
respective region or dimension region zone. Another icon type is showing |
273 |
you whether a region or dimension region zone uses a sample loop. |
274 |
For example when you just imported a short drum sample (not a drum loop), |
275 |
then you don't really want a loop to be on for it. |
276 |
This way |
277 |
you can immediately see and control the key features of all regions |
278 |
and their dimension region zones, without requiring to browse through all |
279 |
of them individually. |
280 |
</p> |
281 |
|
282 |
<h3>Keyboard Shortcuts</h3> |
283 |
<p> |
284 |
Various new keyboard shortcuts have been added so you can work more |
285 |
efficiently on your sounds. For example you can now use Ctrl+Up and Ctrl+Down |
286 |
to switch between instruments, or use Ctrl+Left and |
287 |
Ctrl+Right to navigate through all regions of the currently selected |
288 |
instrument, and likewise you can use Alt+Left, Alt+Right, Alt+Up and |
289 |
Alt+Down to navigate through all dimension region zones of the currently |
290 |
selected region. Since there are many actions that can be either applied |
291 |
on file level, instrument level, on region level, or on dimension region level, as |
292 |
a general rule of thumb for all keyboard shortcuts: |
293 |
<ul> |
294 |
<li><b>Shift</b> key (⇧) is used for global actions</li> |
295 |
<li><b>Ctrl</b> key (⌘ key on Mac) is used on region level</li> |
296 |
<li><b>Alt</b> key (⌥ key on Mac) is used by gigedit for actions on dimension region level</li> |
297 |
</ul> |
298 |
So as another example you may copy all parameters of the currently |
299 |
selected dimension region zone to the clipboard by hitting Alt+C. |
300 |
Now when you change parameters of the selected dimension region, |
301 |
the original parameters are still there on the clipboard. Hit |
302 |
Alt+X to review or even edit the parameters directly on the clipboard. |
303 |
Then select a dimension region zone, or another instrument and then use Alt+V |
304 |
to apply those parameters from the clipboard to the now selected dimension region. |
305 |
You want to keep those parameters on the clipboard permanently in the editor |
306 |
for other instruments in future? Hit Ctrl+M to open the macro list, then hit |
307 |
Ctrl+B to save the content on the clipboard permanently as a new macro. |
308 |
From this point you can also simply duplicate the macro, fine tune and |
309 |
adjust the cloned macros and so on. All macros are saved along with the settings |
310 |
of the application. So they will always be there next time you launch gigedit, |
311 |
and no matter on which gig files you are working on. |
312 |
</p> |
313 |
<p> |
314 |
Too many shortcuts to remember? Of course you can find all keyboard |
315 |
shortcuts in the menus and on the individual buttons. Simply place |
316 |
the mouse pointer over the individual menu items or buttons and a tooltip |
317 |
will explain what the action would do. For menu items and buttons you use |
318 |
frequently, start using their displayed keyboard shortcuts instead. |
319 |
And the ones you really are going to use frequently, you will remember as shortcut |
320 |
in a very short time. |
321 |
</p> |
322 |
|
323 |
<h3>Combine Tool Improvements</h3> |
324 |
<p> |
325 |
<img src="gigedit_combine_tool_reorder.png" title="Combine Tool (Gigedit)"> |
326 |
Also the Combine Tool has been improved. You can now simply select the |
327 |
(multiple) instruments you want to combine directly from the applications |
328 |
main window, i.e. by Ctrl or Shift clicking them from the instruments |
329 |
list view, and then right click to call the combine tool on that |
330 |
selection or even faster; simply hit Ctrl+j ("j" as in "join").<br> |
331 |
<br> |
332 |
The Combine Tool now also shows you a preview of the order in |
333 |
which the selected instruments are going to be combined. This is |
334 |
especially useful when combining instruments with certain dimension |
335 |
types where the order significantly matters for the actual resulting sound; for example |
336 |
when combining by velocity dimension. Simply use drag n drop to reorder |
337 |
the previously selected instruments before combining them finally |
338 |
(by clicking on Ok or simply hitting Enter). |
339 |
</p> |
340 |
|
341 |
<h3>Search Filter</h3> |
342 |
<p> |
343 |
<img src="gigedit_search_filter.png" title="Search Filter (Gigedit)"> |
344 |
And last but not least a filter option field had been added to the |
345 |
instruments list view and samples list view, which allows you to find specific |
346 |
samples and instruments very quickly by typing search key words, which is |
347 |
especially very helpful in case you are working on huge gig files which contain |
348 |
a very large amount of samples or instruments in a single gig file |
349 |
(like this one, which apparently has far more than 400 instruments). |
350 |
</p> |
351 |
|
352 |
<h2>libgig 4.1.0</h2> |
353 |
<p> |
354 |
Our fundamental file access C++ library |
355 |
<a href="http://download.linuxsampler.org/doc/libgig/api/">libgig</a> |
356 |
has also received some major improvements, which are outlined next. |
357 |
</p> |
358 |
|
359 |
<h3>Files larger than 4 GB</h3> |
360 |
<p> |
361 |
libgig 4.1.0 adds support for writing files much larger than 4 GB |
362 |
(or more exactly: up to now 16 Exabyte = 16 777 216 Terabyte) |
363 |
for GigaStudio / Gigasampler (.gig), DLS, as well as for RIFF files in general. This file size |
364 |
limitation existed for a very long time due to the RIFF format's historical, |
365 |
internal 32 bit file offsets. To circumvent this file size limitation the |
366 |
concept of so called "extension files" was added in the past to the |
367 |
GigaStudio format, which means that the GigaStudio instrument editor |
368 |
(the original one on Windows) splitted |
369 |
the respective overall instrument file into a set of files (.gig, .gx01, |
370 |
.gx02, ...), each being max. 2 GB in size, and all of them were expected to be |
371 |
located in the same directory for the sampler to load the entire large |
372 |
instrument successfully. libgig always supported only reading such gig |
373 |
extension files, however libgig never supported to create .gig files with |
374 |
extension files, nor did it support modifying existing ones. |
375 |
<p> |
376 |
</p> |
377 |
In this release |
378 |
it was necessary to finally get rid of this overall file size limitation in |
379 |
libgig. Now when that concept of extension files was introduced years ago, it |
380 |
made sense at that point, because there were still many systems out there |
381 |
which still had no support for large files (on either OS or file system |
382 |
level). However today even on low end mobile devices support for large files |
383 |
is already a broad standard. Accordingly instead of adding write support for |
384 |
extension files in libgig, the problem was addressed at its root by |
385 |
transparently using appropriate, automatic file offset sizes. So when writing |
386 |
.gig/DLS/RIFF files smaller than 4 GB there are still 32 bit file offsets |
387 |
being used by libgig. Accordingly such files are still backward compatible |
388 |
with older software. However if the overall file size to be written is 4 GB or |
389 |
larger, then 64 bit file offsets are automatically used by libgig instead. |
390 |
Note though that due to that circumstance such files ≧ 4 GB are not backward |
391 |
compatible with older versions of libgig, nor could they be loaded with the |
392 |
original GigaStudio software. |
393 |
</p> |
394 |
|
395 |
<h3>Serialization API</h3> |
396 |
<p> |
397 |
Another major new feature in this libgig release is the entirely new |
398 |
<a href="http://download.linuxsampler.org/doc/libgig/api/namespaceSerialization.html">Serialization API</a> |
399 |
which provides a powerful and easy way |
400 |
to serialize and deserialize an arbitrary set of native C++ objects into an |
401 |
abstract data stream. Which means you can simply save the entire runtime state |
402 |
of an application to a file or send it as data over "wire" (i.e. over network |
403 |
or to another process) and restore that runtime state from that data there at |
404 |
any time. In contrast to other C++ serialization frameworks out there, this |
405 |
framework provides two major benefits: |
406 |
<ol> |
407 |
<li> |
408 |
This serialization framework is designed to be very robust regarding |
409 |
potential versioning changes of the native C++ classes being |
410 |
(de)serialized. So even if the C++ classes have seen massive software |
411 |
changes between the point where they were serialized and the point where |
412 |
they are to be deserialized; for example if class member variables of |
413 |
serialized C++ objects were renamed in meantime, or if variable offsets, or |
414 |
variables' data types had been changed, then the deserialization algorithm |
415 |
can still cope with such common software changes automatically in many |
416 |
cases, that is as long as the deserialization algorithm can "guess" what |
417 |
the changes were exactly. If the serialization framework is unable to |
418 |
automatically detect the precise software changes, then it will abort the |
419 |
deserialization task with an exception and an error message stating that |
420 |
the software versions are incompatible. |
421 |
</li> |
422 |
<li> |
423 |
This serialization framework supports "partial" deserialization. That |
424 |
means it not only allows to restore an entire runtime state, but it also |
425 |
allows to only restore an arbitrary desired subset of information |
426 |
from the previously serialized data stream, while leaving all other data |
427 |
of the running C++ objects untouched. The serialization framework also |
428 |
incorporates a reflection API which allows applications to view and |
429 |
manipulate the already serialized data, which in turn allows to implement |
430 |
convenient editors on top of such serialized data, i.e. allowing end users |
431 |
to pick or alter specific information within the serialized data. |
432 |
</li> |
433 |
</ol> |
434 |
This new Serialization framework is already embedded into the gig classes of |
435 |
libgig, and it is used as basis for the new powerful macro features in the |
436 |
gigedit instrument editor, like already outlined above. |
437 |
</p> |
438 |
|
439 |
</body> |
440 |
</html> |