ViewVC logotype

Contents of /doc/docbase/release_notes/linuxsampler_2_1_0/01_linuxsampler_2_1_0.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 3394 - (show annotations) (download) (as text)
Wed Dec 6 18:28:02 2017 UTC (3 years, 4 months ago) by schoenebeck
File MIME type: text/html
File size: 24952 byte(s)
- Additional minor corrections to LinuxSampler 2.1.0 release notes.

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>
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>
63 <h3>SFZ Engine</h3>
64 <p>
65 The SFZ engine now supports <code lang="sfz">&lt;global&gt;</code>,
66 <code lang="sfz">&lt;master&gt;</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>
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>
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>
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>
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>
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>
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>
240 <h3>Multi-Row Selection</h3>
241 <p>
242 <img src="gigedit_multi_row_action.png" title="Multi Row Selection &amp; 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>
253 <h3>Multi-Zone Selection</h3>
254 <p>
255 <img src="gigedit_multi_dimreg_zone_actions.png" title="Multi Zone Selection &amp; 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>
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>
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 (&#8679;) is used for global actions</li>
295 <li><b>Ctrl</b> key (&#8984; key on Mac) is used on region level</li>
296 <li><b>Alt</b> key (&#8997; 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>
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").
331 The Combine Tool now also shows you a preview of the order in
332 which the selected instruments are going to be combined. This is
333 especially useful when combining instruments with certain dimension
334 types where the order significantly matters for the actual resulting sound; for example
335 when combining by velocity dimension. Simply use drag n drop to reorder
336 the previously selected instruments before combining them finally
337 (by clicking on Ok or simply hitting Enter).
338 </p>
340 <h3>Search Filter</h3>
341 <p>
342 <img src="gigedit_search_filter.png" title="Search Filter (Gigedit)">
343 And last but not least a filter option field had been added to the
344 instruments list view and samples list view, which allows you to find specific
345 samples and instruments very quickly by typing search key words, which is
346 especially very helpful in case you are working on huge gig files which contain
347 a very large amount of samples or instruments in a single gig file
348 (like this one, which apparently has far more than 400 instruments).
349 </p>
351 <h2>libgig 4.1.0</h2>
352 <p>
353 Our fundamental file access C++ library
354 <a href="http://download.linuxsampler.org/doc/libgig/api/">libgig</a>
355 has also received some major improvements, which are outlined next.
356 </p>
358 <h3>Files larger than 4 GB</h3>
359 <p>
360 libgig 4.1.0 adds support for writing files much larger than 4 GB
361 (or more exactly: up to now 16 Exabyte = 16 777 216 Terabyte)
362 for GigaStudio / Gigasampler (.gig), DLS, as well as for RIFF files in general. This file size
363 limitation existed for a very long time due to the RIFF format's historical,
364 internal 32 bit file offsets. To circumvent this file size limitation the
365 concept of so called "extension files" was added in the past to the
366 GigaStudio format, which means that the GigaStudio instrument editor
367 (the original one on Windows) splitted
368 the respective overall instrument file into a set of files (.gig, .gx01,
369 .gx02, ...), each being max. 2 GB in size, and all of them were expected to be
370 located in the same directory for the sampler to load the entire large
371 instrument successfully. libgig always supported only reading such gig
372 extension files, however libgig never supported to create .gig files with
373 extension files, nor did it support modifying existing ones.
374 <p>
375 </p>
376 In this release
377 it was necessary to finally get rid of this overall file size limitation in
378 libgig. Now when that concept of extension files was introduced years ago, it
379 made sense at that point, because there were still many systems out there
380 which still had no support for large files (on either OS or file system
381 level). However today even on low end mobile devices support for large files
382 is already a broad standard. Accordingly instead of adding write support for
383 extension files in libgig, the problem was addressed at its root by
384 transparently using appropriate, automatic file offset sizes. So when writing
385 .gig/DLS/RIFF files smaller than 4 GB there are still 32 bit file offsets
386 being used by libgig. Accordingly such files are still backward compatible
387 with older software. However if the overall file size to be written is 4 GB or
388 larger, then 64 bit file offsets are automatically used by libgig instead.
389 Note though that due to that circumstance such files &#8807; 4 GB are not backward
390 compatible with older versions of libgig, nor could they be loaded with the
391 original GigaStudio software.
392 </p>
394 <h3>Serialization API</h3>
395 <p>
396 Another major new feature in this libgig release is the entirely new
397 <a href="http://download.linuxsampler.org/doc/libgig/api/namespaceSerialization.html">Serialization API</a>
398 which provides a powerful and easy way
399 to serialize and deserialize an arbitrary set of native C++ objects into an
400 abstract data stream. Which means you can simply save the entire runtime state
401 of an application to a file or send it as data over "wire" (i.e. over network
402 or to another process) and restore that runtime state from that data there at
403 any time. In contrast to other C++ serialization frameworks out there, this
404 framework provides two major benefits:
405 <ol>
406 <li>
407 This serialization framework is designed to be very robust regarding
408 potential versioning changes of the native C++ classes being
409 (de)serialized. So even if the C++ classes have seen massive software
410 changes between the point where they were serialized and the point where
411 they are to be deserialized; for example if class member variables of
412 serialized C++ objects were renamed in meantime, or if variable offsets, or
413 variables' data types had been changed, then the deserialization algorithm
414 can still cope with such common software changes automatically in many
415 cases, that is as long as the deserialization algorithm can "guess" what
416 the changes were exactly. If the serialization framework is unable to
417 automatically detect the precise software changes, then it will abort the
418 deserialization task with an exception and an error message stating that
419 the software versions are incompatible.
420 </li>
421 <li>
422 This serialization framework supports "partial" deserialization. That
423 means it not only allows to restore an entire runtime state, but it also
424 allows to only restore an arbitrary desired subset of information
425 from the previously serialized data stream, while leaving all other data
426 of the running C++ objects untouched. The serialization framework also
427 incorporates a reflection API which allows applications to view and
428 manipulate the already serialized data, which in turn allows to implement
429 convenient editors on top of such serialized data, i.e. allowing end users
430 to pick or alter specific information within the serialized data.
431 </li>
432 </ol>
433 This new Serialization framework is already embedded into the gig classes of
434 libgig, and it is used as basis for the new powerful macro features in the
435 gigedit instrument editor, like already outlined above.
436 </p>
438 </body>
439 </html>

  ViewVC Help
Powered by ViewVC