release_notes/linuxsampler_2_2_0/01_linuxsampler_2_2_0.html

<html>
  <head>
    <meta name="author" content="Christian Schoenebeck">
    <title>Release Notes LinuxSampler 2.2.0</title>
    <navpath>LinuxSampler 2.2.0</navpath>
    <meta name="description" content="Release notes for LinuxSampler 2.2.0.">
    <link rel="stylesheet" href="https://doc.linuxsampler.org/css/preview.css">
    <script type="text/javascript" src="https://doc.linuxsampler.org/js/preview.js"></script>
  </head>
  <body>
    <h1>LinuxSampler 2.2.0</h1>
    <p>
      LinuxSampler 2.2.0 and friends were released on May 9th 2021. Almost two
      years have passed since the
      <a href="01_linuxsampler_2_1_1.html">previous release</a>. This time there
      are a load of changes and especially many new features packed into this
      release.
    </p>

    <h3 id="cpp14">C++11 / C++14 Requirement</h3>
    <p>
      Starting with <b>Gigedit 1.2.0</b> and <b>libgig 4.3.0</b> you now need at
      least a <b>C++11</b>
      compliant compiler to build them from source; and for building
      <b>LinuxSampler 2.2.0</b> you now need at least a <b>C++14</b> compliant compiler.
      Originally it was planned to only raise the minimum compiler
      requirement to C++11 for LinuxSampler in this release as well, however
      during this development cycle, some C++14 features came across which helped
      to reduce code complexity in the LinuxSampler code base tremendously.
    </p>

    <h2 id="nksp">Real-Time Instrument Scripts</h2>
    <p>
      The <a href="01_nksp.html">NKSP</a> real-time instrument script engine has
      received tremendous new features and improvements in this release, which
      are outlined next.
    </p>

    <h3 id="64bit">64-Bit NKSP Integers</h3>
    <p>
      Instrument script variables of type integer
      (e.g. <code lang="nksp">declare $foo := 4294967295</code>)
      are now all 64-bit internally, which prevents unexpected side effects of
      script authors due to potential integer overflows that easily had happened
      before when integer script variables were just 32-bit wide.
      &nbsp;&nbsp;
      <a href="01_nksp_real_unit_final.html#64bit">Find out more ...</a>
    </p>

    <h3 id="real_numbers">NKSP Real Numbers</h3>
    <p>
      On <a href="01_nksp.html">NKSP language</a> level there is now support for
      floating point variables; both scalar types (e.g. 
      <code lang="nksp">declare ~foo := 3.94</code>
      ) and floating point arrays (e.g.
      <code lang="nksp">declare ?foo[] = ( 1.6, 4.7 )</code>
      ).
      &nbsp;&nbsp;
      <a href="01_nksp_real_unit_final.html#real_numbers">Find out more ...</a>
    </p>

    <h3 id="units">NKSP Standard Measuring Units</h3>
    <p>
      Another huge new NKSP language feature is
      <a href="01_nksp_real_unit_final.html#units">support for standard measuring units</a>
      like <code lang="none">Hz</code> (Hertz), <code lang="none">dB</code> (Decibel),
      <code lang="none">s</code> (seconds), <code lang="none">c</code> (cents) in conjuction with
      arbitrary metric prefixes like <code lang="none">kHz</code>, <code lang="none">mdB</code>,
      <code lang="none">ms</code>, <code lang="none">mc</code>, etc.<br>
      <br>
      For instance previously for pausing
      a script for one second, you had to write <code lang="nksp">wait(1000000)</code>,
      which still works, but now you can also just write <code lang="nksp">wait(1s)</code>.
      &nbsp;&nbsp;
      <a href="01_nksp_real_unit_final.html#units">Find out more ...</a>
    </p>

    <h3 id="finalness">NKSP Final Operator</h3>
    <p>
      The newly introduced "final" operator <code>!</code> in NKSP allows to
      force a synthesis parameter like e.g. volume or pitch to a specific value
      that should not be overridden by any other modulation source (e.g. neither
      from patch level, nor LFOs, nor from EGs, ...). This is sometimes helpful
      for being able to e.g. say in a script, "hey, the volume of this voice
      should be exactly -3dB, period. I mean it!", which is as simple as
      <code lang="nksp">change_vol($EVENT_ID, !-3dB)</code>
      &nbsp;&nbsp;
      <a href="01_nksp_real_unit_final.html#finalness">Find out more ...</a>
    </p>
    <img src="nksp_multi_mods_fin.png" caption="Force 'Finalness' by Script">

    <h3 id="functions">New Built-In NKSP Functions</h3>
    <p>
      Furthermore there are <b>23 new</b>
      <a href="01_nksp_reference.html#functions">built-in NKSP script functions</a>
      and <b>6 new</b> <a href="01_nksp_reference.html#variables">NKSP constants/variables</a>.<br>
      <br>
      There also <b>2 new event handler types</b> for processing MIDI <b>RPN events</b>:
    </p>
    <p>
      <code lang="nksp">
on rpn
  message("RPN address msb=" & msb($RPN_ADDRESS) & ",lsb=" & lsb($RPN_ADDRESS) &
          "-> value msb=" & msb($RPN_VALUE) & ",lsb="  & lsb($RPN_VALUE))
  if ($RPN_ADDRESS = 2)
    message("Standard Coarse Tuning RPN received")
  end if
end on
      </code>
    </p>
    <p>
      and for MIDI <b>NRPN events</b>:
    </p>
    <p>
      <code lang="nksp">
on nrpn
  message("NRPN address msb=" & msb($RPN_ADDRESS) & ",lsb=" & lsb($RPN_ADDRESS) &
          "-> value msb=" & msb($RPN_VALUE) & ",lsb="  & lsb($RPN_VALUE))
end on
      </code>
    </p>
    <p>
      <a href="01_nksp#rpn_event">Find out more ...</a>
    </p>

    <h3 id="patch_variables">NKSP Patch Variables</h3>
    <p>
      Instrument scripts give you great flexibility to achieve whatever exotic
      bahaviour you might have in mind for your sounds. Built-in patch
      parameters on the other hand, hard coded into the sampler engines and
      supported already by the underlying file format allow very quick and
      convenient parameter changes, e.g. simply by few clicks in the Gigedit
      instrument editor. What about having both?<br>
      <br>
      This is what the new NKSP "patch" variables are for. By simply declaring
      an instrument script variable with the new NKSP keyword <code>patch</code>
      you are publishing and exposing that variable as parameter in the
      instrument editor's patch parameters pane.<br>
      <br>
      Patch variables are shown and adjustable on a per instruments basis. So
      you can share a script among multiple instruments and override
      certain script parameters to customize the script behaviour for your
      individual instruments if needed. Gigedit shows you the default values of each patch
      variable. After changing a value of some of the variables the respective
      variable turns into a bold font, so you can immediately see which script
      parameters you have adjusted for the specific instrument and which not.
      By selecting one of the overridden variables and hitting the
      <b>Backspace</b> (&#9003;) key you can revert those variables back to
      their default values.
    </p>
    <p>
      <img src="nksp_new_patch_script_example_shot.png">
      <img src="gigedit_new_patch_vars_cut.png">
    </p>

    <h2 id="gig">GigaStudio Format Engine</h2>
    <p>
      For the GigaStudio/Gigasampler (.gig) format sampler engine several new
      format extensions have been added. Of course there are also many fixes for
      the gig engine in this release, but they are too many to list them here.
      Please refer to the
      <a href="http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/ChangeLog?view=markup">ChangeLog</a>
      for more details about all the corrections in this release.
    </p>

    <h3 id="lfo">LFO Extensions</h3>
    <p>
      You now have much more control over LFOs with the gig engine like
      selecting different LFO waveforms as sine, triangle, saw or square.
      GigaStudio had this limited to sine only. The default LFO wave form in
      LinuxSampler's gig engine has also changed to sine for that reason
      (instead of triangle in previous LinuxSampler versions). Additionally you
      can now also fine control the start phase of individual LFOs. In the
      original gig format you were only able to flip the phase.
    </p>
    <img src="gigedit_new_lfo_wave_forms.png">

    <h3 id="filters">New Filter Types</h3>
    <p>
      Furthermore there are now new audio filter types available for the Giga
      engine: new lowpass 1/2/4/6-pole, new highpass 1/2/4/6-pole, new bandpass
      2-pole, and finally a bandreject 2-pole filter. You might say that some of
      those filter types existed before, and they still do and will continue to
      co-exist, but they simply sound differently. Keep in mind that the audio
      filters for the Giga engine were very carefully engineered to accurateley
      replicate the sounds as if being played with Tascam's GigaStudio, so that
      made and still makes sense. However you might simply like the sound of
      some of the new filter types more for certain reasons when creating your
      own gig instruments from scratch.
    </p>
    <img src="gigedit_new_audio_filter_types.png">

    <h2 id="sfz">SFZ Format Engine</h2>
    <p>
      On SFZ format engine side there are corrections for the SFZ opcodes
      <code lang="sfz">loccN</code>/<code lang="sfz">hiccN</code> and <code lang="sfz">xfin_hivel</code>.
    </p>

    <h2 id="tests">LinuxSampler Test Cases</h2>
    <p>
      For package maintainers: the LinuxSampler unit tests (which were broken
      before) have been fixed in this release and work now as expected. It is
      recommend for them to be run automatically to detect and prevent any OS
      issues that might cause misbehaviours for users. Just keep in mind the
      test cases als test the LSCP server which will listen on TCP port 8888
      during the tests. So make sure this port cannot be accessed from outside
      for security reasons.
    </p>

    <h2 id="gigedit">Gigedit 1.2.0</h2>
    <p>
      Our instrument editor for the GigaStudio/Gigasampler format also received
      many new features. Some of them have already been shown above among the
      new features in LinuxSampler.
    </p>

    <h3 id="script_editor">NKSP Standard Measuring Units</h3>
    <p>
      The real-time instrument script editor of Gigedit supports now syntax
      highlighting for LinuxSampler's new standard measuring units (kHz, c, ms,
      dB, etc.) feature of the NKSP script language.
    </p>

    <h3 id="script_tab">New "Script" Tab</h3>
    <p>
      On the right hand side of Gigedit (the main working area actually) there
      is now a new tab "Script" which reveals a list of so called NKSP "patch"
      variables which have been <a href="#patch_variables">described above</a>
      among LinuxSampler's new features.
    </p>
    <img src="gigedit_new_patch_vars.png" caption="Gigedit's new 'Script' tab">

    <h3 id="sample_info">Sample Properties Dialog</h3>
    <p>
      A new dialog has been added to access the global settings and meta info of
      individual samples,
      similar to the meta info dialog that already existed for individual
      instruments.
    </p>
    <p>
      <img src="gigedit_new_sample_info_meta.png">
      <img src="gigedit_new_sample_info_settings.png">
    </p>

    <h3 id="gain">More Flexible Gain</h3>
    <p>
      Gain can now be set to any arbitary value between -96 dB .. +96 dB.
      Previously it was only possible to set gain to max. 0 dB and there was a
      checkbox which allowed a hard coded boost to exactly +6 dB. The previous
      appearance replicated the appearance of GigaStudio's original instrument editor.
    </p>
    <p>
    <img src="gigedit_more_flexible_gain_setting.png">
  The previous limitation of having just a single possible value for positive gain
  was unfortunate, but as it turned out this was actually not a limitation of
  the original gig file format. And in fact we have not added any gig file
  format extension for this reason to achieve this new freedom of arbitrary gain
  settings. So setting a positive gain of e.g. let's say +1.45 dB does not break
  compatibility of your sounds with GigaStudio.
    </p>

    <h3 id="convenience">Convenience Features</h3>
    <p>
      <img src="gigedit_spinbox_fine_tuning_steps.png">
      And last but not least various minor convenience functions have been added,
  for instance the default double click behaviour on instruments (which would
  open their meta info dialog) can now optionally be disabled, window size,
  position and vertical spliter position are now auto saved and restored (correctly) by default among
  Gigedit sessions and the up/down buttons' steps have been individually
  adjusted to make more sense for the individual synthesis parameters they
  control. And regarding the latter: remember that the up/down steppers do 
  actually have two distinct operations per button: a regular left-mouse click
  for small changes and middle-mouse click for larger changes. Both have been
  adjusted appropriately for the individual synthesis parameters they control.
    </p>
    <img src="gigedit_new_instr_prop_by_double_click_opt.png">

    <h2 id="libgig">libgig 4.3.0</h2>
    <p>
      Our fundamental file access C++ library
      <a href="https://download.linuxsampler.org/doc/libgig/api/">libgig</a>
      has also received new features and corrections. Most of them deal with the
      Giga format extensions added by LinuxSampler, so they are obviously also
      added on libgig side. We are not going to repeat them here, because it should
      already be obvious from LinuxSampler's new features described above. There
      are however also new build requirements for libgig as follows.
    </p>

    <h3 id="uuid">UUID Function Required</h3>
    <p>
      From this release on (besides the new C++11 requirement) presence of some
      UUID generating function is required, which must be provided by the
      underlying OS. Previously
  the presence of an UUID generating function was optional in libgig for many
  years. Its absence in the past only meant that you were unable to load your
  own gig files (e.g. created from scratch with Gigedit by yourself) into
  Tascam's GigaStudio software, it did not mean though any restriction in
  conjunction with LinuxSampler in the past. The latter has changed in this
  release. Without UUIDs in gig files you would now also get misbehaviours
  even while staying entirely in the Linux eco space, and hence this is now a
  hard build requirement for libgig.
    </p>

    <h3 id="GigaStudio3">GigaStudio 3 Compatibility Fixes</h3>
    </p>
      And as always there are a various fixes in this release, foremost sane output
      compatibility with GigaStudio 3 was broken, so that GigaStudio version might
      not have accepted gig files changed by you with the prior version of libgig.
      This issue is now fixed in this release. Please refer to the
      <a href="http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/ChangeLog?view=markup">ChangeLog</a>
      for other corrections in this release of libgig.
    </p>

    <h3 id="serialization">Serialization Framework</h3>
    </p>
  And last but not least libgig's <a href="https://download.linuxsampler.org/doc/libgig/api/namespaceSerialization.html#details">Serialization framework</a>
  was extended to support now
  various common C++ STL classes like std::string, std::vector, std::map and
  std::set out of the box. So no custom code is required aymore to
  serialize/deserialize such very common native C++ object types, which reduces
  code complexity for serializing/deserializing complex C++ projects a lot.
    </p>

  </body>
</html>
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	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			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	schoenebeck	3890	<img src="gigedit_spinbox_fine_tuning_steps.png">
265	schoenebeck	3887	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			</p>
276	schoenebeck	3890	<img src="gigedit_new_instr_prop_by_double_click_opt.png">
277	schoenebeck	3887
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>