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