1 |
<html> |
2 |
<head> |
3 |
<meta name="author" content="Christian Schoenebeck"> |
4 |
<title>Release Notes LinuxSampler 2.2.0</title> |
5 |
<navpath>LinuxSampler 2.2.0</navpath> |
6 |
<meta name="description" content="Release notes for LinuxSampler 2.2.0."> |
7 |
<link rel="stylesheet" href="https://doc.linuxsampler.org/css/preview.css"> |
8 |
<script type="text/javascript" src="https://doc.linuxsampler.org/js/preview.js"></script> |
9 |
</head> |
10 |
<body> |
11 |
<h1>LinuxSampler 2.2.0</h1> |
12 |
<p> |
13 |
LinuxSampler 2.2.0 and friends were released on May 9th 2021. Almost two |
14 |
years have passed since the |
15 |
<a href="01_linuxsampler_2_1_1.html">previous release</a>. This time there |
16 |
are a load of changes and especially many new features packed into this |
17 |
release. |
18 |
</p> |
19 |
|
20 |
<h3 id="cpp14">C++11/C++14 Requirement</h3> |
21 |
<p> |
22 |
Starting with Gigedit 1.2.0 and libgig 4.3.0 you now need at least a C++11 |
23 |
compliant compiler to build them from source; and for building |
24 |
LinuxSampler 2.2.0 you now need at least a C++14 compliant compiler. |
25 |
Originally it was planned to only raise the minimum compiler |
26 |
requirement to C++11 for LinuxSampler in this release as well, however |
27 |
during this development cycle, some C++14 features came across which helped |
28 |
to reduce code complexity in the LinuxSampler code base tremendously. |
29 |
</p> |
30 |
|
31 |
<h2 id="nksp">Real-Time Instrument Scripts</h2> |
32 |
<p> |
33 |
The <a href="01_nksp.html">NKSP</a> real-time instrument script engine has |
34 |
received tremendous new features and improvements in this release, which |
35 |
are outlined next. |
36 |
</p> |
37 |
|
38 |
<h3 id="64bit">64-Bit NKSP Integers</h3> |
39 |
<p> |
40 |
Instrument script variables of type integer |
41 |
(e.g. <code lang="nksp">declare $foo := 4294967295</code>) |
42 |
are now all 64-bit internally, which prevents unexpected side effects of |
43 |
script authors due to potential integer overflows that easily had happened |
44 |
before when integer script variables were just 32-bit wide. |
45 |
<a href="01_nksp_real_unit_final.html#64bit">Find out more ...</a> |
46 |
</p> |
47 |
|
48 |
<h3 id="real_numbers">NKSP Real Numbers</h3> |
49 |
<p> |
50 |
On <a href="01_nksp.html">NKSP language</a> level there is now support for |
51 |
floating point variables; both scalar types (e.g. |
52 |
<code lang="nksp">declare ~foo := 3.94</code> |
53 |
) and floating point arrays (e.g. |
54 |
<code lang="nksp">declare ?foo[] = ( 1.6, 4.7 )</code> |
55 |
). |
56 |
<a href="01_nksp_real_unit_final.html#real_numbers">Find out more ...</a> |
57 |
</p> |
58 |
|
59 |
<h3 id="units">NKSP Standard Measuring Units</h3> |
60 |
<p> |
61 |
Another huge new NKSP language feature is |
62 |
<a href="01_nksp_real_unit_final.html#units">support for standard measuring units</a> |
63 |
like <code>Hz</code> (Hertz), <code>dB</code> (Decibel), |
64 |
<code>s</code> (seconds), <code>c</code> (cents) in conjuction with |
65 |
arbitrary metric prefixes like <code>kHz</code>, <code>mdB</code>, |
66 |
<code>ms</code>, <code>mc</code>, etc. For instance previously for pausing |
67 |
a script for one second, you had to write <code>wait(1000000)</code>, |
68 |
which still works, but now you can also just write <code>wait(1s)</code>. |
69 |
<a href="01_nksp_real_unit_final.html#units">Find out more ...</a> |
70 |
</p> |
71 |
|
72 |
<h3 id="finalness">NKSP Final Operator</h3> |
73 |
<p> |
74 |
The newly introduced "final" operator <code>!</code> in NKSP allows to |
75 |
force a synthesis parameter like e.g. volume or pitch to a specific value |
76 |
that should not be overridden by any other modulation source (e.g. neither |
77 |
from patch level, nor LFOs, nor from EGs, ...). This is sometimes helpful |
78 |
for being able to e.g. say in a script, "hey, the volume of this voice |
79 |
should be exactly -3dB, period. I mean it!": |
80 |
</p> |
81 |
<p> |
82 |
<code lang="nksp"> |
83 |
on note |
84 |
change_vol($EVENT_ID, !-3dB) |
85 |
end note |
86 |
</code> |
87 |
</p> |
88 |
<p> |
89 |
<a href="01_nksp_real_unit_final.html#finalness">Find out more ...</a> |
90 |
</p> |
91 |
|
92 |
<h3 id="functions">New Built-In NKSP Functions</h3> |
93 |
<p> |
94 |
Furthermore there are <b>23 new</b> |
95 |
<a href="01_nksp_reference.html#functions">built-in NKSP script functions</a> |
96 |
and <b>6 new</b> <a href="01_nksp_reference.html#variables">NKSP constants/variables</a>. |
97 |
There also <b>2 new event handler types</b> for processing MIDI <b>RPN events</b>: |
98 |
</p> |
99 |
<p> |
100 |
<code lang="nksp"> |
101 |
on rpn |
102 |
message("RPN address msb=" & msb($RPN_ADDRESS) & ",lsb=" & lsb($RPN_ADDRESS) & |
103 |
"-> value msb=" & msb($RPN_VALUE) & ",lsb=" & lsb($RPN_VALUE)) |
104 |
if ($RPN_ADDRESS = 2) |
105 |
message("Standard Coarse Tuning RPN received") |
106 |
end if |
107 |
end on |
108 |
</code> |
109 |
</p> |
110 |
<p> |
111 |
and for MIDI <b>NRPN events</b>: |
112 |
</p> |
113 |
<p> |
114 |
<code lang="nksp"> |
115 |
on nrpn |
116 |
message("NRPN address msb=" & msb($RPN_ADDRESS) & ",lsb=" & lsb($RPN_ADDRESS) & |
117 |
"-> value msb=" & msb($RPN_VALUE) & ",lsb=" & lsb($RPN_VALUE)) |
118 |
end on |
119 |
</code> |
120 |
</p> |
121 |
<p> |
122 |
<a href="01_nksp#rpn_event">Find out more ...</a> |
123 |
</p> |
124 |
|
125 |
<h3 id="patch_variables">NKSP Patch Variables</h3> |
126 |
<p> |
127 |
Instrument scripts give you great flexibility to achieve whatever exotic |
128 |
bahaviour you might have in mind for your sounds. Built-in patch |
129 |
parameters on the other hand, hard coded into the sampler engines and |
130 |
supported already by the underlying file format allow very quick and |
131 |
convenient parameter changes, e.g. simply by few clicks in the Gigedit |
132 |
instrument editor. What about having both? |
133 |
</p> |
134 |
<p> |
135 |
<img src="nksp_new_patch_script_example_shot.png"> |
136 |
This is what the new NKSP "patch" variables are for. By simply declaring |
137 |
an instrument script variable with the new NKSP keyword <code>patch</code> |
138 |
you are publishing and exposing that variable as parameter in the |
139 |
instrument editor's patch parameters pane.<br> |
140 |
<br> |
141 |
Patch variables are shown and adjustable on a per instruments basis. So |
142 |
you can share a script among multiple instruments and override |
143 |
certain script parameters to customize the script behaviour for your |
144 |
individual instruments if needed. Gigedit shows you the default values of each patch |
145 |
variable. After changing a value of some of the variables the respective |
146 |
variable turns into a bold font, so you can immediately see which script |
147 |
parameters you have adjusted for the specific instrument and which not. |
148 |
By selecting one of the overridden variables and hitting the |
149 |
<b>Backspace</b> (⌫) key you can revert those variables back to |
150 |
their default values. |
151 |
<img src="gigedit_new_patch_vars_cut.png"> |
152 |
</p> |
153 |
|
154 |
<h2 id="gig">GigaStudio Format Engine</h2> |
155 |
<p> |
156 |
For the GigaStudio/Gigasampler (.gig) format sampler engine several new |
157 |
format extensions have been added. Of course there are also many fixes for |
158 |
the gig engine in this release, but they are too many to list them here. |
159 |
Please refer to the |
160 |
<a href="http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/ChangeLog?view=markup">ChangeLog</a> |
161 |
for more details about all the corrections in this release. |
162 |
</p> |
163 |
|
164 |
<h3 id="lfo">LFO Extensions</h3> |
165 |
<p> |
166 |
<img src="gigedit_new_lfo_wave_forms.png"> |
167 |
You now have much more control over LFOs with the gig engine like |
168 |
selecting different LFO waveforms as sine, triangle, saw or square. |
169 |
GigaStudio had this limited to sine only. The default LFO wave form in |
170 |
LinuxSampler's gig engine has also changed to sine for that reason |
171 |
(instead of triangle in previous LinuxSampler versions). Additionally you |
172 |
can now also fine control the start phase of individual LFOs. In the |
173 |
original gig format you were only able to flip the phase. |
174 |
</p> |
175 |
|
176 |
<h3 id="filters">New Filter Types</h3> |
177 |
<p> |
178 |
<img src="gigedit_new_audio_filter_types.png"> |
179 |
Furthermore there are now new audio filter types available for the Giga |
180 |
engine: new lowpass 1/2/4/6-pole, new highpass 1/2/4/6-pole, new bandpass |
181 |
2-pole, and finally a bandreject 2-pole filter. You might say that some of |
182 |
those filter types existed before, and they still do and will continue to |
183 |
co-exist, but they simply sound differently. Keep in mind that the audio |
184 |
filters for the Giga engine were very carefully engineered to accurateley |
185 |
replicate the sounds as if being played with Tascam's GigaStudio, so that |
186 |
made and still makes sense. However you might simply like the sound of |
187 |
some of the new filter types more for certain reasons when creating your |
188 |
own gig instruments from scratch. |
189 |
</p> |
190 |
|
191 |
<h2 id="sfz">SFZ Format Engine</h2> |
192 |
<p> |
193 |
On SFZ format engine side there are corrections for the SFZ opcodes |
194 |
<code lang="sfz">loccN</code>/<code lang="sfz">hiccN</code> and <code lang="sfz">xfin_hivel</code>. |
195 |
</p> |
196 |
|
197 |
<h2 id="tests">LinuxSampler Test Cases</h2> |
198 |
<p> |
199 |
For package maintainers: the LinuxSampler unit tests (which were broken |
200 |
before) have been fixed in this release and work now as expected. It is |
201 |
recommend for them to be run automatically to detect and prevent any OS |
202 |
issues that might cause misbehaviours for users. Just keep in mind the |
203 |
test cases als test the LSCP server which will listen on TCP port 8888 |
204 |
during the tests. So make sure this port cannot be accessed from outside |
205 |
for security reasons. |
206 |
</p> |
207 |
|
208 |
<h2 id="gigedit">Gigedit 1.2.0</h2> |
209 |
<p> |
210 |
Our instrument editor for the GigaStudio/Gigasampler format also received |
211 |
many new features. Some of them have already been shown above among the |
212 |
new features in LinuxSampler. |
213 |
</p> |
214 |
|
215 |
<h3 id="script_editor">NKSP Standard Measuring Units</h3> |
216 |
<p> |
217 |
The real-time instrument script editor of Gigedit supports now syntax |
218 |
highlighting for LinuxSampler's new standard measuring units (kHz, c, ms, |
219 |
dB, etc.) feature of the NKSP script language. |
220 |
</p> |
221 |
|
222 |
<h3 id="script_tab">New "Script" Tab</h3> |
223 |
<p> |
224 |
<img src="gigedit_new_patch_vars.png"> |
225 |
On the right hand side of Gigedit (the main working area actually) there |
226 |
is now a new tab "Script" which reveals a list of so called NKSP "patch" |
227 |
variables which have been <a href="#patch_variables">described above</a> |
228 |
among LinuxSampler's new features. |
229 |
</p> |
230 |
|
231 |
<h3 id="sample_info">Sample Properties Dialog</h3> |
232 |
<p> |
233 |
A new dialog has been added to access the global settings and meta info of |
234 |
individual samples, |
235 |
similar to the meta info dialog that already existed for individual |
236 |
instruments. |
237 |
</p> |
238 |
<p> |
239 |
<img src="gigedit_new_sample_info_meta.png"> |
240 |
<img src="gigedit_new_sample_info_settings.png"> |
241 |
</p> |
242 |
|
243 |
<h3 id="gain">More Flexible Gain</h3> |
244 |
<p> |
245 |
Gain can now be set to any arbitary value between -96 dB .. +96 dB. |
246 |
</p> |
247 |
<p> |
248 |
<img src="gigedit_more_flexible_gain_setting.png"> |
249 |
Previously it was only possible to set gain to max. 0 dB and there was a checkbox which |
250 |
allowed a hard coded boost to exactly +6 dB. The previous appearance |
251 |
replicated the appearance of GigaStudio's original instrument editor. The |
252 |
previous limitation of having just a single possible value for positive gain |
253 |
was unfortunate, but as it turned out this was actually not a limitation of |
254 |
the original gig file format. And in fact we have not added any gig file |
255 |
format extension for this reason to achieve this new freedom of arbitrary gain |
256 |
settings. So setting a positive gain of e.g. let's say +1.45 dB does not break |
257 |
compatibility of your sounds with GigaStudio. |
258 |
</p> |
259 |
|
260 |
<h3 id="convenience">Convenience Features</h3> |
261 |
<p> |
262 |
<img src="gigedit_new_instr_prop_by_double_click_opt.png"> |
263 |
And last but not least various minor convenience functions have been added, |
264 |
for instance the default double click behaviour on instruments (which would |
265 |
open their meta info dialog) can now optionally be disabled, window size, |
266 |
position and vertical spliter position are now auto saved and restored (correctly) by default among |
267 |
Gigedit sessions and the up/down buttons' steps have been individually |
268 |
adjusted to make more sense for the individual synthesis parameters they |
269 |
control. And regarding the latter: remember that the up/down steppers do |
270 |
actually have two distinct operations per button: a regular left-mouse click |
271 |
for small changes and middle-mouse click for larger changes. Both have been |
272 |
adjusted appropriately for the individual synthesis parameters they control. |
273 |
</p> |
274 |
<img src="gigedit_spinbox_fine_tuning_steps.png"> |
275 |
|
276 |
<h2 id="libgig">libgig 4.3.0</h2> |
277 |
<p> |
278 |
Our fundamental file access C++ library |
279 |
<a href="https://download.linuxsampler.org/doc/libgig/api/">libgig</a> |
280 |
has also received new features and corrections. Most of them deal with the |
281 |
Giga format extensions added by LinuxSampler, so they are obviously also |
282 |
added on libgig side. We are not going to repeat them here, because it should |
283 |
already be obvious from LinuxSampler's new features described above. There |
284 |
are however also new build requirements for libgig as follows. |
285 |
</p> |
286 |
|
287 |
<h3 id="uuid">UUID Function Required</h3> |
288 |
<p> |
289 |
From this release on (besides the new C++11 requirement) presence of some |
290 |
UUID generating function is required, which must be provided by the |
291 |
underlying OS. Previously |
292 |
the presence of an UUID generating function was optional in libgig for many |
293 |
years. Its absence in the past only meant that you were unable to load your |
294 |
own gig files (e.g. created from scratch with Gigedit by yourself) into |
295 |
Tascam's GigaStudio software, it did not mean though any restriction in |
296 |
conjunction with LinuxSampler in the past. The latter has changed in this |
297 |
release. Without UUIDs in gig files you would now also get misbehaviours |
298 |
even while staying entirely in the Linux eco space, and hence this is now a |
299 |
hard build requirement for libgig. |
300 |
</p> |
301 |
|
302 |
<h3 id="GigaStudio3">GigaStudio 3 Compatibility Fixes</h3> |
303 |
</p> |
304 |
And as always there are a various fixes in this release, foremost sane output |
305 |
compatibility with GigaStudio 3 was broken, so that GigaStudio version might |
306 |
not have accepted gig files changed by you with the prior version of libgig. |
307 |
This issue is now fixed in this release. Please refer to the |
308 |
<a href="http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/ChangeLog?view=markup">ChangeLog</a> |
309 |
for other corrections in this release of libgig. |
310 |
</p> |
311 |
|
312 |
<h3 id="serialization">Serialization Framework</h3> |
313 |
</p> |
314 |
And last but not least libgig's <a href="https://download.linuxsampler.org/doc/libgig/api/namespaceSerialization.html#details">Serialization framework</a> |
315 |
was extended to support now |
316 |
various common C++ STL classes like std::string, std::vector, std::map and |
317 |
std::set out of the box. So no custom code is required aymore to |
318 |
serialize/deserialize such very common native C++ object types, which reduces |
319 |
code complexity for serializing/deserializing complex C++ projects a lot. |
320 |
</p> |
321 |
|
322 |
</body> |
323 |
</html> |