ViewVC logotype

Contents of /doc/docbase/release_notes/linuxsampler_2_2_0/01_linuxsampler_2_2_0.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 3888 - (show annotations) (download) (as text)
Sun May 9 18:18:23 2021 UTC (2 years, 6 months ago) by schoenebeck
File MIME type: text/html
File size: 15686 byte(s)
* Release note fixes (LinuxSampler 2.2.0).

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>
20 <h3 id="cpp14">C++11 / C++14 Requirement</h3>
21 <p>
22 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 compliant compiler to build them from source; and for building
25 <b>LinuxSampler 2.2.0</b> you now need at least a <b>C++14</b> compliant compiler.
26 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>
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>
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 &nbsp;&nbsp;
47 <a href="01_nksp_real_unit_final.html#64bit">Find out more ...</a>
48 </p>
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 &nbsp;&nbsp;
59 <a href="01_nksp_real_unit_final.html#real_numbers">Find out more ...</a>
60 </p>
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 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 &nbsp;&nbsp;
75 <a href="01_nksp_real_unit_final.html#units">Find out more ...</a>
76 </p>
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 should be exactly -3dB, period. I mean it!", which is as simple as
86 <code lang="nksp">change_vol($EVENT_ID, !-3dB)</code>
87 &nbsp;&nbsp;
88 <a href="01_nksp_real_unit_final.html#finalness">Find out more ...</a>
89 </p>
90 <img src="nksp_multi_mods_fin.png" caption="Force 'Finalness' by Script">
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>.<br>
97 <br>
98 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>
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 instrument editor. What about having both?<br>
134 <br>
135 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> (&#9003;) key you can revert those variables back to
149 their default values.
150 </p>
151 <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>
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>
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 <img src="gigedit_new_lfo_wave_forms.png">
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 <img src="gigedit_new_audio_filter_types.png">
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>
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>
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>
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>
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 <img src="gigedit_new_patch_vars.png" caption="Gigedit's new 'Script' tab">
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>
245 <h3 id="gain">More Flexible Gain</h3>
246 <p>
247 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 </p>
252 <p>
253 <img src="gigedit_more_flexible_gain_setting.png">
254 The previous limitation of having just a single possible value for positive gain
255 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>
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 <img src="gigedit_spinbox_fine_tuning_steps.png">
276 </p>
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>
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>
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>
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>
324 </body>
325 </html>

  ViewVC Help
Powered by ViewVC