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 |
|
|
<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> |