/[svn]/doc/docbase/release_notes/linuxsampler_2_2_0/01_linuxsampler_2_2_0.html
ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 3895 - (hide annotations) (download) (as text)
Sun May 9 19:13:21 2021 UTC (2 years, 10 months ago) by schoenebeck
File MIME type: text/html
File size: 15736 byte(s)
- Release notes: and hopefully the last one: fix a typo.

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 &nbsp;&nbsp;
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 &nbsp;&nbsp;
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     &nbsp;&nbsp;
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     &nbsp;&nbsp;
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> (&#9003;) key you can revert those variables back to
149     their default values.
150     </p>
151 schoenebeck 3888 <p>
152 schoenebeck 3889 <img src="nksp_new_patch_script_example_shot.png">
153     <img src="gigedit_new_patch_vars_cut.png">
154 schoenebeck 3888 </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 schoenebeck 3891 engine: new <b>lowpass 1/2/4/6-pole</b>, new <b>highpass 1/2/4/6-pole</b>,
182     new <b>bandpass 2-pole</b>, and finally a <b>bandreject 2-pole</b> filter.<br>
183     <br>
184     You might say that some of
185 schoenebeck 3887 those filter types existed before, and they still do and will continue to
186     co-exist, but they simply sound differently. Keep in mind that the audio
187     filters for the Giga engine were very carefully engineered to accurateley
188     replicate the sounds as if being played with Tascam's GigaStudio, so that
189     made and still makes sense. However you might simply like the sound of
190     some of the new filter types more for certain reasons when creating your
191     own gig instruments from scratch.
192     </p>
193 schoenebeck 3888 <img src="gigedit_new_audio_filter_types.png">
194 schoenebeck 3887
195     <h2 id="sfz">SFZ Format Engine</h2>
196     <p>
197     On SFZ format engine side there are corrections for the SFZ opcodes
198     <code lang="sfz">loccN</code>/<code lang="sfz">hiccN</code> and <code lang="sfz">xfin_hivel</code>.
199     </p>
200    
201     <h2 id="tests">LinuxSampler Test Cases</h2>
202     <p>
203     For package maintainers: the LinuxSampler unit tests (which were broken
204     before) have been fixed in this release and work now as expected. It is
205     recommend for them to be run automatically to detect and prevent any OS
206     issues that might cause misbehaviours for users. Just keep in mind the
207 schoenebeck 3895 test cases also test the LSCP server which will listen on TCP port 8888
208 schoenebeck 3887 during the tests. So make sure this port cannot be accessed from outside
209     for security reasons.
210     </p>
211    
212     <h2 id="gigedit">Gigedit 1.2.0</h2>
213     <p>
214     Our instrument editor for the GigaStudio/Gigasampler format also received
215     many new features. Some of them have already been shown above among the
216     new features in LinuxSampler.
217     </p>
218    
219     <h3 id="script_editor">NKSP Standard Measuring Units</h3>
220     <p>
221     The real-time instrument script editor of Gigedit supports now syntax
222     highlighting for LinuxSampler's new standard measuring units (kHz, c, ms,
223     dB, etc.) feature of the NKSP script language.
224     </p>
225 schoenebeck 3894 <img src="gigedit_new_units_support_code_editor_shot.png">
226 schoenebeck 3887
227     <h3 id="script_tab">New "Script" Tab</h3>
228     <p>
229     On the right hand side of Gigedit (the main working area actually) there
230     is now a new tab "Script" which reveals a list of so called NKSP "patch"
231     variables which have been <a href="#patch_variables">described above</a>
232     among LinuxSampler's new features.
233     </p>
234 schoenebeck 3888 <img src="gigedit_new_patch_vars.png" caption="Gigedit's new 'Script' tab">
235 schoenebeck 3887
236     <h3 id="sample_info">Sample Properties Dialog</h3>
237     <p>
238     A new dialog has been added to access the global settings and meta info of
239     individual samples,
240     similar to the meta info dialog that already existed for individual
241     instruments.
242     </p>
243     <p>
244     <img src="gigedit_new_sample_info_meta.png">
245     <img src="gigedit_new_sample_info_settings.png">
246     </p>
247    
248     <h3 id="gain">More Flexible Gain</h3>
249     <p>
250 schoenebeck 3888 Gain can now be set to any arbitary value between -96 dB .. +96 dB.
251     Previously it was only possible to set gain to max. 0 dB and there was a
252     checkbox which allowed a hard coded boost to exactly +6 dB. The previous
253     appearance replicated the appearance of GigaStudio's original instrument editor.
254 schoenebeck 3887 </p>
255     <p>
256     <img src="gigedit_more_flexible_gain_setting.png">
257 schoenebeck 3888 The previous limitation of having just a single possible value for positive gain
258 schoenebeck 3887 was unfortunate, but as it turned out this was actually not a limitation of
259     the original gig file format. And in fact we have not added any gig file
260     format extension for this reason to achieve this new freedom of arbitrary gain
261     settings. So setting a positive gain of e.g. let's say +1.45 dB does not break
262     compatibility of your sounds with GigaStudio.
263     </p>
264    
265     <h3 id="convenience">Convenience Features</h3>
266     <p>
267 schoenebeck 3890 <img src="gigedit_spinbox_fine_tuning_steps.png">
268 schoenebeck 3887 And last but not least various minor convenience functions have been added,
269     for instance the default double click behaviour on instruments (which would
270     open their meta info dialog) can now optionally be disabled, window size,
271     position and vertical spliter position are now auto saved and restored (correctly) by default among
272 schoenebeck 3892 Gigedit sessions.<br>
273     <br>
274     And the up/down buttons' steps have been individually
275 schoenebeck 3887 adjusted to make more sense for the individual synthesis parameters they
276     control. And regarding the latter: remember that the up/down steppers do
277     actually have two distinct operations per button: a regular left-mouse click
278     for small changes and middle-mouse click for larger changes. Both have been
279     adjusted appropriately for the individual synthesis parameters they control.
280     </p>
281 schoenebeck 3890 <img src="gigedit_new_instr_prop_by_double_click_opt.png">
282 schoenebeck 3887
283     <h2 id="libgig">libgig 4.3.0</h2>
284     <p>
285     Our fundamental file access C++ library
286     <a href="https://download.linuxsampler.org/doc/libgig/api/">libgig</a>
287     has also received new features and corrections. Most of them deal with the
288     Giga format extensions added by LinuxSampler, so they are obviously also
289     added on libgig side. We are not going to repeat them here, because it should
290     already be obvious from LinuxSampler's new features described above. There
291     are however also new build requirements for libgig as follows.
292     </p>
293    
294     <h3 id="uuid">UUID Function Required</h3>
295     <p>
296     From this release on (besides the new C++11 requirement) presence of some
297     UUID generating function is required, which must be provided by the
298     underlying OS. Previously
299     the presence of an UUID generating function was optional in libgig for many
300     years. Its absence in the past only meant that you were unable to load your
301     own gig files (e.g. created from scratch with Gigedit by yourself) into
302     Tascam's GigaStudio software, it did not mean though any restriction in
303     conjunction with LinuxSampler in the past. The latter has changed in this
304     release. Without UUIDs in gig files you would now also get misbehaviours
305     even while staying entirely in the Linux eco space, and hence this is now a
306     hard build requirement for libgig.
307     </p>
308    
309     <h3 id="GigaStudio3">GigaStudio 3 Compatibility Fixes</h3>
310 schoenebeck 3891 <p>
311 schoenebeck 3887 And as always there are a various fixes in this release, foremost sane output
312     compatibility with GigaStudio 3 was broken, so that GigaStudio version might
313     not have accepted gig files changed by you with the prior version of libgig.
314     This issue is now fixed in this release. Please refer to the
315     <a href="http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/ChangeLog?view=markup">ChangeLog</a>
316     for other corrections in this release of libgig.
317     </p>
318    
319     <h3 id="serialization">Serialization Framework</h3>
320 schoenebeck 3891 <p>
321 schoenebeck 3887 And last but not least libgig's <a href="https://download.linuxsampler.org/doc/libgig/api/namespaceSerialization.html#details">Serialization framework</a>
322     was extended to support now
323 schoenebeck 3892 various common C++ STL classes like <b>std::string</b>, <b>std::vector</b>,
324     <b>std::map</b> and <b>std::set</b> out of the box. So no custom code is required aymore to
325 schoenebeck 3887 serialize/deserialize such very common native C++ object types, which reduces
326     code complexity for serializing/deserializing complex C++ projects a lot.
327     </p>
328    
329     </body>
330     </html>

  ViewVC Help
Powered by ViewVC