release_notes/linuxsampler_2_1_0/01_linuxsampler_2_1_0.html

<html>
  <head>
    <meta name="author" content="Christian Schoenebeck">
    <title>Release Notes LinuxSampler 2.1.0</title>
    <navpath>LinuxSampler 2.1.0</navpath>
    <meta name="description" content="Release notes for LinuxSampler 2.1.0.">
    <link rel="stylesheet" href="http://doc.linuxsampler.org/css/preview.css">
    <script type="text/javascript" src="http://doc.linuxsampler.org/js/preview.js"></script>
  </head>
  <body>
    <h1>LinuxSampler 2.1.0</h1>
    <p>
      LinuxSampler 2.1.0 and friends were released on November 25th 2017.
      Two years have passed since the last release of LinuxSampler.
      Here is a summary about what's new.
    </p>

    <h3>Real-Time Instrument Scripts</h3>
    <p>
      In the <a href="01_linuxsampler_2_0_0.html">previous release</a> a major
      new feature called <i>Real-Time Instrument Scripts</i> was added, which
      are essentially small programs that may be bundled with sound files to extend the
      sampler with custom behavior specifically intended for individual sounds.
      <a href="instrument_scripts.html">Find out more ...</a>
    </p>
    <p>
      These programs are written by sound designers in a script language called
      <a href="01_nksp.html">NKSP</a>.
      In this release a large amount of extensions and improvements have been
      added for this real-time instrument scripting support of LinuxSampler.
      For example <b>48 new built-in functions</b> and <b>21 new built-in
      variables</b> have been added.
      <a href="01_nksp_reference.html">Find out more ...</a>
    </p>
    <p>
      Also the NKSP language and the underlying engine itself was extended.
      Most notably the script engine now has an execution scheduler which is
      the basis for many of the timing relevant new NKSP features in this
      release, like programmatically suspending and resuming scripts for an
      exact duration or at an exact point of time or triggering or killing notes
      at very precise times (all with microsecond accuracy).
      You can now even launch new threads in your NKSP scripts by
      calling the new built-in function <code lang="nksp">fork()</code>.
      Furthermore
      <a href="01_nksp.html#boolean_operators">bitwise operators</a>
      have been added to NKSP, as well as support for
      read only built-in variables,
      <a href="01_nksp.html#synchronized_blocks">"synchronized" code blocks</a>
      , as well as
      <a href="01_nksp.html#user_functions">user declared functions</a>
      and user declared const array variables have been added to the NKSP language,
      and finally automatic suspension of RT threatening scripts by the RT script engine
      has been implemented. The latter ensures that the sampler remains stable,
      and does not cause audio dropouts, even while you are working on heavy and
      extremely buggy scripts.
      Also syntax error messages with NKSP scripts have
      been improved to output more clear and user friendly error messages, as
      well as the NKSP editor API has been improved which brings handy new features
      to gigedit's NKSP script editor, which will further be described below,
      along with gigedit's new features.
    </p>

    <h3>SFZ Engine</h3>
    <p>
      The SFZ engine now supports <code lang="sfz">&lt;global&gt;</code>,
      <code lang="sfz">&lt;master&gt;</code> sections,
      <code lang="sfz">#define</code> statement and <code lang="sfz">set_ccN</code>
      opcode. And finally the SFZ engine now supports NKSP real-time
      instrument scripts as well by adding a new
      <code lang="sfz">script</code> opcode for this purpose. So NKSP scripts
      are no longer limited to our Giga engine.
    </p>

    <h3>New GigaStudio format features</h3>
    <p>
      The equally named software on Windows has gone years ago,
      but the format lives on with LinuxSampler and this release adds
      yet some more new extensions to the gig format.
    </p>
    <p>
      <img src="gigedit_state_machine_options.png" title="EG State Machine Options (Gigedit)">
      Most notably you
      now have options to control envelope generators' state machines.
      For example you can now define whether a certain EG state should
      either be aborted or continued to its end when a note off arrived.
      These controls are especially useful for certain kinds of sounds
      like percussive instruments.<br>
      <br>
      Accordingly you will now find new check boxes for this in gigedit.
      As these are extensions of the original format, setting these options
      will only work with LinuxSampler and would be ignored with the
      original GigaStudio software.
    </p>

    <h3>Instruments DB</h3>
    <p>
      Also the Instruments Database feature has received important maintenance
      fixes. Before this release, the instrument DB feature was barely usable
      for quite some time. Fundamental instruments DB issues have been fixed in
      this release to finally consider this feature stable again as well.
    </p>


    <h2>Gigedit 1.1.0</h2>
    <p>
      Also <i>Gigedit</i>, our instrument editor for the GigaStudio/Gigasampler
      format, had been enhanced quite a lot. The most important new features are
      summarized next.
    </p>

    <h3>Script Editor</h3>
    <p>
      Gigedit's integrated instrument script editor supports now tight coupling
      directly with LinuxSampler's actual real-time instrument script backend.
      That provides several improvements for the script editor.
    </p>
    <p>
      <img src="nksp_editor_error_tooltip.png" title="NKSP Error Tooltips">
      For example
      colored syntax highlighting of scripts is now always displayed correctly and
      simply looks much better now. Previously there was some small hard coded
      script parser code on Gigedit's side which however was buggy and simply
      did no great job. Now all the heavy lifting of handling all the details
      of the numerous NKSP language aspects are handled by the sampler instead,
      which also provides the following new script editor features.<br>
      <br>
      Due to that direct coupling with LinuxSampler's
      script backend, gigedit's script editor now shows all issues related to the script (errors
      and warnings) directly within the script editor in real-time while you are
      typing. The actual erroneous locations of the script are automatically
      highlighted with red background color, locations of the script with
      warnings are automatically highlighted with yellow background color, and
      when you move your mouse over the respective code location, the precise
      error/warning message is displayed as a tooltip. And last but not least
      there is a summary of issues displayed in the status bar of the script
      editor. Since LinuxSampler's instrument script backend is actually doing
      all the work for the script editor, all aspects of the language, all
      details about built-in functions and variables, and all potential issues
      with their precise cause and messages are automatically covered by the
      script editor now.
      That way you immediately know whether or whether not your script
      is OK with every character you are typing, and without requiring to
      actually load the script with an instrument into the sampler.
    </p>
    <p>
      <img src="nksp_editor_strike_through.png" title="NKSP Disabled Code Blocks">
      Additionally when clicking on the
      script editor's "Apply" button or using Ctrl+S keyboard shortcut, then
      the script is automatically reloaded by the sampler. So you no longer
      have to reload the respective instrument manually while you are
      developing instrument scripts. There are also visual enhancements for the
      script editor, for example the line numbers are now shown on the left,
      the font size can be altered by the user, and unused code portions (i.e.
      disabled by <a href="01_nksp.html#preprocessor_statements">NKSP preprocessor statements</a>)
      are automatically striked through. That way you can immediately see
      which code portions of your scripts are actually used, and which are not.<br>
      <br>
      As as side note, you may have noticed a handy new built-in preprocessor
      condition in LinuxSampler 2.1.0 which can be enabled with
      <code lang="nksp">SET_CONDITION(NKSP_NO_MESSAGE)</code> and allows you
      to quickly disable <code lang="nksp">message()</code> function calls,
      i.e. to conviently switch your scripts between a debug and release mode.
      <a href="01_nksp.html#disable_messages">Find out more ...</a>
    </p>

    <h3>Macros</h3>
    <p>
      Another major new feature in this release are macros.
      A macro is a set of changes that should be applied to currently selected instrument.
    </p>
    <p>
      <img src="gigedit_macros_setup.png" title="Macro List (Gigedit)">
      Such macros can be reviewed and edited, and they can be saved permanently for
      example as templates for common instrument creation tasks. Macros can be
      assigned to F keys on the keyboard so that they can be quickly triggered,
      you can transfer them over the OS clipboard and you can write comments
      to your macros so that you never forget what kind of purpose you had in
      mind for them. The macro features are based on libgig's new
      "Serialization" framework (described below) and accordingly you need at
      least libgig 4.1.0 for using these macro features.
    </p>
    <p>
      <img src="gigedit_macro_editor.png" title="Macro Editor (Gigedit)">
      This is an example of editing a macro. Usually you may start creating a
      new macro by simply taking all parameters of a selected dimension region.
      Then in the macro editor you usually multi-row select (i.e. by Ctrl clicking
      items in the list) just the parameters you want this macro to alter, then
      click on "Inverse Delete" to just keep those few selected parameters in
      that macro. As a result, when you are going to apply this macro during your
      upcoming work, only those few parameters are modifed by this macro and all
      other ones are left untouched.
      Of course you can also alter the individual parameter values in
      this editor as well. 
    </p>

    <h3>Persistent Settings</h3>
    <p>
      All user settings of gigedit are now persistently saved and automatically
      restored. This also includes gigedit's windows' dimensions and positions.
    </p>

    <h3>Multi-Row Selection</h3>
    <p>
    <img src="gigedit_multi_row_action.png" title="Multi Row Selection &amp; Actions (Gigedit)">
      Multi-row selection has been added to all list views now, so you can now
      more efficiently apply actions to multiple samples, instruments or scripts
      simultaneously at once, instead of requesting those actions for each item
      individually.
    </p>

    <h3>Multi-Zone Selection</h3>
    <p>
      <img src="gigedit_multi_dimreg_zone_actions.png" title="Multi Zone Selection &amp; Actions (Gigedit)">
      Also modifying key features of several dimension region zones
      simultaneously is now supported. That means you can now delete, split and
      resize multiple dimension region zones at once. Oh yes, I forget, Ctrl+click
      selecting multiple dimension region zones is supported now as well.
    </p>
    
    <h3>Feature Icons</h3>
    <p>
      <img src="gigedit_zone_icons.png" title="Feature Icons (Gigedit)">
      You will also note that there are now icons displayed on the individual
      regions and dimension region zones. Those icons visualize common key
      features of regions and dimension region zones. For example if you forgot
      to assign any sample to one of them, then you will see a red dot on the
      respective region or dimension region zone. Another icon type is showing
      you whether a region or dimension region zone uses a sample loop.
      For example when you just imported a drum sample, you don't really want
      a loop to be on.
      This way
      you can immediately see and control the key features of all regions
      and their dimension region zones, without requiring to browse through all
      of them individually.
    </p>

    <h3>Keyboard Shortcuts</h3>
    <p>
     Various new keyboard shortcuts have been added so you can work more
     efficiently on your sounds. For example you can now use Ctrl+Left and
     Ctrl+Right to navigate through all regions of the currently selected
     instrument, and likewise you can use Alt+Left, Alt+Right, Alt+Up and
     Alt+Down to navigate through all dimension region zones of the currently
     selected region. Since there are many actions that can be either applied
     on instrument level, or on region level, or on dimension region level, as
     a general rule, for all keyboard shortcuts:
     <ul>
       <li><b>Shift</b> key is used for actions on instrument level</li>
       <li><b>Ctrl</b> key is used on region level</li>
       <li><b>Alt</b> key is used by gigedit for actions on dimension region level</li>
     </ul>
     So as another example you may copy all parameters of the currently
     selected dimension region zone by hitting Alt+C, then you might select
     another dimension region zone, or another instrument and then use Alt+V
     to apply the parameters from the clipboard. While the parameters are
     (as macro actually) on the clipboard you can also review, edit and
     delete the individual parameters before applying them. As a final
     example for new important shortcuts you may now use Shift+Up and
     Shift+Down for switching between instruments.
    </p>

    <h3>Combine Tool Improvements</h3>
    <p>
      <img src="gigedit_combine_tool_reorder.png" title="Combine Tool (Gigedit)">
      Also the Combine Tool has been improved. You can now simply select the
      (multiple) instruments you want to combine directly from the applications
      main window, i.e. by Ctrl or Shift clicking them from the instruments
      list view, and then right click to call the combine tool on that
      selection. The Combine Tool now also shows you as preview the order in
      which the selected instruments are going to be combined. This is
      especially useful when combining instruments with certain dimension
      types where the order matters for the actual resulting sound; for example
      when using the velocity dimension. Simply use drag n drop to reorder
      the previously selected instruments before combining them.
    </p>

    <h3>Search Filter</h3>
    <p>
      <img src="gigedit_search_filter.png" title="Search Filter (Gigedit)">
      And last but not least a filter option field had been added to the
      instruments list view and samples list view, which allows you to find specific
      samples and instruments very quickly by typing search key words, which is
      especially very helpful in case you are working on gig files which contain
      a very large amount of samples or instruments in a single gig file
      (like this one, which apparently has far more than 400 instruments).
    </p>

    <h2>libgig 4.1.0</h2>
    <p>
      Our fundamental file access C++ library
      <a href="http://download.linuxsampler.org/doc/libgig/api/">libgig</a>
      has also received some major improvements, which are outlined next.
    </p>

    <h3>Files larger than 2 GB</h3>
    <p>
      libgig 4.1.0 adds support for files much larger than 2 GB for GigaStudio /
      Gigasampler (.gig), DLS, as well as for RIFF files in general. This file size
      limitation existed for a very long time due to the RIFF format's historical,
      internal 32 bit file offsets. To circumvent this file size limitation the
      concept of so called "extension files" was added in the past to the
      GigaStudio format, which means that the GigaStudio instrument editor
      (the original one on Windows) splitted
      the respective overall instrument file into a set of files (.gig, .gx01,
      .gx02, ...), each being max. 2 GB in size, and all of them were expected to be
      located in the same directory for the sampler to load the entire large
      instrument successfully. libgig always supported only reading such gig
      extension files, however libgig never supported to create .gig files with
      extension files, nor did it support modifying existing ones.
    <p>
    </p>
      In this release
      it was necessary to finally get rid of this overall file size limitation in
      libgig. Now when that concept of extension files was introduced years ago, it
      made sense at that point, because there were still many systems out there
      which still had no support for large files (on either OS or file system
      level). However today even on low end mobile devices support for large files
      is already a broad standard. Accordingly instead of adding write support for
      extension files in libgig, the problem was addressed at its root by
      transparently using appropriate, automatic file offset sizes. So when writing
      .gig/DLS/RIFF files smaller than 2 GB there are still 32 bit file offsets
      being used by libgig. Accordingly such files are still backward compatible
      with older software. However if the overall file size to be written is 2 GB or
      larger, then 64 bit file offsets are automatically used by libgig instead.
      Note though that due to that circumstance such files &#8807; 2 GB are not backward
      compatible with older versions of libgig, nor could they be loaded with the
      original GigaStudio software.
    </p>
    
    <h3>Serialization API</h3>
    <p>
      Another major new feature in this libgig release is the entirely new
      <a href="http://download.linuxsampler.org/doc/libgig/api/namespaceSerialization.html">Serialization API</a>
      which provides a powerful and easy way
      to serialize and deserialize an arbitrary set of native C++ objects into an
      abstract data stream. Which means you can simply save the entire runtime state
      of an application to a file or send it as data over "wire" (i.e. over network
      or to another process) and restore that runtime state from that data there at
      any time. In contrast to other C++ serialization frameworks out there, this
      framework provides two major benefits:
      <ol>
        <li>
          This serialization framework is designed to be very robust regarding
          potential versioning changes of the native C++ classes being
          (de)serialized. So even if the C++ classes have seen massive software
          changes between the point where they were serialized and the point where
          they are to be deserialized; for example if class member variables of
          serialized C++ objects were renamed in meantime, or if variable offsets, or
          variables' data types had been changed, then the deserialization algorithm
          can still cope with such common software changes automatically in many
          cases, that is as long as the deserialization algorithm can "guess" what
          the changes were exactly. If the serialization framework is unable to
          automatically detect the precise software changes, then it will abort the
          deserialization task with an exception and an error message stating that
          the software versions are incompatible.
        </li>
        <li>
          This serialization framework supports "partial" deserialization. That
          means it not only allows to restore an entire runtime state, but it also
          allows to only restore an arbitrary desired subset of information
          from the previously serialized data stream, while leaving all other data
          of the running C++ objects untouched. The serialization framework also
          incorporates a reflection API which allows applications to implement
          convenient editors on top of such serialized data, i.e. allowing end users
          to pick or alter specific information within the serialized data.
        </li>
      </ol>
      This new Serialization framework is already embedded into the gig classes of
      libgig, and it is used as basis for the new powerful macro features in the
      gigedit instrument editor, like already outlined above.
    </p>

  </body>
</html>
1	schoenebeck	3376	<html>
2			<head>
3			<meta name="author" content="Christian Schoenebeck">
4			<title>Release Notes LinuxSampler 2.1.0</title>
5			<navpath>LinuxSampler 2.1.0</navpath>
6			<meta name="description" content="Release notes for LinuxSampler 2.1.0.">
7			<link rel="stylesheet" href="http://doc.linuxsampler.org/css/preview.css">
8			<script type="text/javascript" src="http://doc.linuxsampler.org/js/preview.js"></script>
9			</head>
10			<body>
11			<h1>LinuxSampler 2.1.0</h1>
12			<p>
13			LinuxSampler 2.1.0 and friends were released on November 25th 2017.
14			Two years have passed since the last release of LinuxSampler.
15			Here is a summary about what's new.
16			</p>
17
18			<h3>Real-Time Instrument Scripts</h3>
19			<p>
20			In the <a href="01_linuxsampler_2_0_0.html">previous release</a> a major
21			new feature called <i>Real-Time Instrument Scripts</i> was added, which
22			are essentially small programs that may be bundled with sound files to extend the
23			sampler with custom behavior specifically intended for individual sounds.
24			<a href="instrument_scripts.html">Find out more ...</a>
25			</p>
26			<p>
27			These programs are written by sound designers in a script language called
28			<a href="01_nksp.html">NKSP</a>.
29			In this release a large amount of extensions and improvements have been
30			added for this real-time instrument scripting support of LinuxSampler.
31	schoenebeck	3377	For example <b>48 new built-in functions</b> and <b>21 new built-in
32			variables</b> have been added.
33	schoenebeck	3376	<a href="01_nksp_reference.html">Find out more ...</a>
34			</p>
35			<p>
36			Also the NKSP language and the underlying engine itself was extended.
37			Most notably the script engine now has an execution scheduler which is
38			the basis for many of the timing relevant new NKSP features in this
39			release, like programmatically suspending and resuming scripts for an
40			exact duration or at an exact point of time or triggering or killing notes
41			at very precise times (all with microsecond accuracy).
42			You can now even launch new threads in your NKSP scripts by
43			calling the new built-in function <code lang="nksp">fork()</code>.
44			Furthermore
45			<a href="01_nksp.html#boolean_operators">bitwise operators</a>
46			have been added to NKSP, as well as support for
47			read only built-in variables,
48			<a href="01_nksp.html#synchronized_blocks">"synchronized" code blocks</a>
49			, as well as
50			<a href="01_nksp.html#user_functions">user declared functions</a>
51			and user declared const array variables have been added to the NKSP language,
52			and finally automatic suspension of RT threatening scripts by the RT script engine
53			has been implemented. The latter ensures that the sampler remains stable,
54			and does not cause audio dropouts, even while you are working on heavy and
55			extremely buggy scripts.
56			Also syntax error messages with NKSP scripts have
57			been improved to output more clear and user friendly error messages, as
58			well as the NKSP editor API has been improved which brings handy new features
59			to gigedit's NKSP script editor, which will further be described below,
60			along with gigedit's new features.
61			</p>
62
63			<h3>SFZ Engine</h3>
64			<p>
65			The SFZ engine now supports <code lang="sfz"><global></code>,
66			<code lang="sfz"><master></code> sections,
67			<code lang="sfz">#define</code> statement and <code lang="sfz">set_ccN</code>
68			opcode. And finally the SFZ engine now supports NKSP real-time
69			instrument scripts as well by adding a new
70			<code lang="sfz">script</code> opcode for this purpose. So NKSP scripts
71			are no longer limited to our Giga engine.
72			</p>
73
74			<h3>New GigaStudio format features</h3>
75			<p>
76			The equally named software on Windows has gone years ago,
77			but the format lives on with LinuxSampler and this release adds
78	schoenebeck	3377	yet some more new extensions to the gig format.
79			</p>
80			<p>
81			<img src="gigedit_state_machine_options.png" title="EG State Machine Options (Gigedit)">
82			Most notably you
83	schoenebeck	3376	now have options to control envelope generators' state machines.
84			For example you can now define whether a certain EG state should
85			either be aborted or continued to its end when a note off arrived.
86			These controls are especially useful for certain kinds of sounds
87	schoenebeck	3377	like percussive instruments.<br>
88			<br>
89	schoenebeck	3376	Accordingly you will now find new check boxes for this in gigedit.
90			As these are extensions of the original format, setting these options
91			will only work with LinuxSampler and would be ignored with the
92			original GigaStudio software.
93			</p>
94
95			<h3>Instruments DB</h3>
96			<p>
97			Also the Instruments Database feature has received important maintenance
98			fixes. Before this release, the instrument DB feature was barely usable
99			for quite some time. Fundamental instruments DB issues have been fixed in
100			this release to finally consider this feature stable again as well.
101			</p>
102
103
104			<h2>Gigedit 1.1.0</h2>
105			<p>
106			Also <i>Gigedit</i>, our instrument editor for the GigaStudio/Gigasampler
107			format, had been enhanced quite a lot. The most important new features are
108			summarized next.
109			</p>
110
111			<h3>Script Editor</h3>
112			<p>
113			Gigedit's integrated instrument script editor supports now tight coupling
114			directly with LinuxSampler's actual real-time instrument script backend.
115			That provides several improvements for the script editor.
116			</p>
117			<p>
118	schoenebeck	3377	<img src="nksp_editor_error_tooltip.png" title="NKSP Error Tooltips">
119	schoenebeck	3376	For example
120			colored syntax highlighting of scripts is now always displayed correctly and
121			simply looks much better now. Previously there was some small hard coded
122			script parser code on Gigedit's side which however was buggy and simply
123			did no great job. Now all the heavy lifting of handling all the details
124			of the numerous NKSP language aspects are handled by the sampler instead,
125	schoenebeck	3377	which also provides the following new script editor features.<br>
126			<br>
127	schoenebeck	3376	Due to that direct coupling with LinuxSampler's
128			script backend, gigedit's script editor now shows all issues related to the script (errors
129			and warnings) directly within the script editor in real-time while you are
130			typing. The actual erroneous locations of the script are automatically
131			highlighted with red background color, locations of the script with
132			warnings are automatically highlighted with yellow background color, and
133			when you move your mouse over the respective code location, the precise
134			error/warning message is displayed as a tooltip. And last but not least
135			there is a summary of issues displayed in the status bar of the script
136			editor. Since LinuxSampler's instrument script backend is actually doing
137			all the work for the script editor, all aspects of the language, all
138			details about built-in functions and variables, and all potential issues
139			with their precise cause and messages are automatically covered by the
140			script editor now.
141			That way you immediately know whether or whether not your script
142			is OK with every character you are typing, and without requiring to
143			actually load the script with an instrument into the sampler.
144			</p>
145			<p>
146	schoenebeck	3377	<img src="nksp_editor_strike_through.png" title="NKSP Disabled Code Blocks">
147	schoenebeck	3376	Additionally when clicking on the
148			script editor's "Apply" button or using Ctrl+S keyboard shortcut, then
149			the script is automatically reloaded by the sampler. So you no longer
150			have to reload the respective instrument manually while you are
151			developing instrument scripts. There are also visual enhancements for the
152			script editor, for example the line numbers are now shown on the left,
153			the font size can be altered by the user, and unused code portions (i.e.
154	schoenebeck	3377	disabled by <a href="01_nksp.html#preprocessor_statements">NKSP preprocessor statements</a>)
155	schoenebeck	3376	are automatically striked through. That way you can immediately see
156			which code portions of your scripts are actually used, and which are not.<br>
157			<br>
158			As as side note, you may have noticed a handy new built-in preprocessor
159			condition in LinuxSampler 2.1.0 which can be enabled with
160			<code lang="nksp">SET_CONDITION(NKSP_NO_MESSAGE)</code> and allows you
161			to quickly disable <code lang="nksp">message()</code> function calls,
162			i.e. to conviently switch your scripts between a debug and release mode.
163			<a href="01_nksp.html#disable_messages">Find out more ...</a>
164			</p>
165
166			<h3>Macros</h3>
167			<p>
168			Another major new feature in this release are macros.
169			A macro is a set of changes that should be applied to currently selected instrument.
170			</p>
171			<p>
172	schoenebeck	3377	<img src="gigedit_macros_setup.png" title="Macro List (Gigedit)">
173	schoenebeck	3376	Such macros can be reviewed and edited, and they can be saved permanently for
174			example as templates for common instrument creation tasks. Macros can be
175			assigned to F keys on the keyboard so that they can be quickly triggered,
176			you can transfer them over the OS clipboard and you can write comments
177			to your macros so that you never forget what kind of purpose you had in
178			mind for them. The macro features are based on libgig's new
179			"Serialization" framework (described below) and accordingly you need at
180			least libgig 4.1.0 for using these macro features.
181			</p>
182			<p>
183	schoenebeck	3377	<img src="gigedit_macro_editor.png" title="Macro Editor (Gigedit)">
184	schoenebeck	3376	This is an example of editing a macro. Usually you may start creating a
185			new macro by simply taking all parameters of a selected dimension region.
186			Then in the macro editor you usually multi-row select (i.e. by Ctrl clicking
187			items in the list) just the parameters you want this macro to alter, then
188			click on "Inverse Delete" to just keep those few selected parameters in
189			that macro. As a result, when you are going to apply this macro during your
190			upcoming work, only those few parameters are modifed by this macro and all
191			other ones are left untouched.
192			Of course you can also alter the individual parameter values in
193			this editor as well.
194			</p>
195
196			<h3>Persistent Settings</h3>
197			<p>
198			All user settings of gigedit are now persistently saved and automatically
199			restored. This also includes gigedit's windows' dimensions and positions.
200			</p>
201
202			<h3>Multi-Row Selection</h3>
203			<p>
204	schoenebeck	3377	<img src="gigedit_multi_row_action.png" title="Multi Row Selection & Actions (Gigedit)">
205	schoenebeck	3376	Multi-row selection has been added to all list views now, so you can now
206			more efficiently apply actions to multiple samples, instruments or scripts
207			simultaneously at once, instead of requesting those actions for each item
208			individually.
209			</p>
210
211			<h3>Multi-Zone Selection</h3>
212			<p>
213	schoenebeck	3377	<img src="gigedit_multi_dimreg_zone_actions.png" title="Multi Zone Selection & Actions (Gigedit)">
214	schoenebeck	3376	Also modifying key features of several dimension region zones
215			simultaneously is now supported. That means you can now delete, split and
216			resize multiple dimension region zones at once. Oh yes, I forget, Ctrl+click
217	schoenebeck	3377	selecting multiple dimension region zones is supported now as well.
218	schoenebeck	3376	</p>
219
220			<h3>Feature Icons</h3>
221			<p>
222	schoenebeck	3377	<img src="gigedit_zone_icons.png" title="Feature Icons (Gigedit)">
223	schoenebeck	3376	You will also note that there are now icons displayed on the individual
224			regions and dimension region zones. Those icons visualize common key
225			features of regions and dimension region zones. For example if you forgot
226			to assign any sample to one of them, then you will see a red dot on the
227			respective region or dimension region zone. Another icon type is showing
228			you whether a region or dimension region zone uses a sample loop.
229			For example when you just imported a drum sample, you don't really want
230			a loop to be on.
231			This way
232			you can immediately see and control the key features of all regions
233			and their dimension region zones, without requiring to browse through all
234			of them individually.
235			</p>
236
237			<h3>Keyboard Shortcuts</h3>
238			<p>
239			Various new keyboard shortcuts have been added so you can work more
240			efficiently on your sounds. For example you can now use Ctrl+Left and
241			Ctrl+Right to navigate through all regions of the currently selected
242			instrument, and likewise you can use Alt+Left, Alt+Right, Alt+Up and
243			Alt+Down to navigate through all dimension region zones of the currently
244			selected region. Since there are many actions that can be either applied
245			on instrument level, or on region level, or on dimension region level, as
246			a general rule, for all keyboard shortcuts:
247			<ul>
248			<li><b>Shift</b> key is used for actions on instrument level</li>
249			<li><b>Ctrl</b> key is used on region level</li>
250			<li><b>Alt</b> key is used by gigedit for actions on dimension region level</li>
251			</ul>
252			So as another example you may copy all parameters of the currently
253			selected dimension region zone by hitting Alt+C, then you might select
254			another dimension region zone, or another instrument and then use Alt+V
255			to apply the parameters from the clipboard. While the parameters are
256			(as macro actually) on the clipboard you can also review, edit and
257			delete the individual parameters before applying them. As a final
258			example for new important shortcuts you may now use Shift+Up and
259			Shift+Down for switching between instruments.
260			</p>
261
262			<h3>Combine Tool Improvements</h3>
263			<p>
264	schoenebeck	3377	<img src="gigedit_combine_tool_reorder.png" title="Combine Tool (Gigedit)">
265	schoenebeck	3376	Also the Combine Tool has been improved. You can now simply select the
266			(multiple) instruments you want to combine directly from the applications
267			main window, i.e. by Ctrl or Shift clicking them from the instruments
268			list view, and then right click to call the combine tool on that
269			selection. The Combine Tool now also shows you as preview the order in
270			which the selected instruments are going to be combined. This is
271			especially useful when combining instruments with certain dimension
272			types where the order matters for the actual resulting sound; for example
273			when using the velocity dimension. Simply use drag n drop to reorder
274			the previously selected instruments before combining them.
275			</p>
276
277			<h3>Search Filter</h3>
278			<p>
279	schoenebeck	3377	<img src="gigedit_search_filter.png" title="Search Filter (Gigedit)">
280	schoenebeck	3376	And last but not least a filter option field had been added to the
281	schoenebeck	3377	instruments list view and samples list view, which allows you to find specific
282	schoenebeck	3376	samples and instruments very quickly by typing search key words, which is
283			especially very helpful in case you are working on gig files which contain
284			a very large amount of samples or instruments in a single gig file
285			(like this one, which apparently has far more than 400 instruments).
286			</p>
287
288			<h2>libgig 4.1.0</h2>
289			<p>
290			Our fundamental file access C++ library
291			<a href="http://download.linuxsampler.org/doc/libgig/api/">libgig</a>
292			has also received some major improvements, which are outlined next.
293			</p>
294
295			<h3>Files larger than 2 GB</h3>
296			<p>
297			libgig 4.1.0 adds support for files much larger than 2 GB for GigaStudio /
298			Gigasampler (.gig), DLS, as well as for RIFF files in general. This file size
299			limitation existed for a very long time due to the RIFF format's historical,
300			internal 32 bit file offsets. To circumvent this file size limitation the
301			concept of so called "extension files" was added in the past to the
302			GigaStudio format, which means that the GigaStudio instrument editor
303			(the original one on Windows) splitted
304			the respective overall instrument file into a set of files (.gig, .gx01,
305			.gx02, ...), each being max. 2 GB in size, and all of them were expected to be
306			located in the same directory for the sampler to load the entire large
307			instrument successfully. libgig always supported only reading such gig
308			extension files, however libgig never supported to create .gig files with
309			extension files, nor did it support modifying existing ones.
310			<p>
311			</p>
312			In this release
313			it was necessary to finally get rid of this overall file size limitation in
314			libgig. Now when that concept of extension files was introduced years ago, it
315			made sense at that point, because there were still many systems out there
316			which still had no support for large files (on either OS or file system
317			level). However today even on low end mobile devices support for large files
318			is already a broad standard. Accordingly instead of adding write support for
319			extension files in libgig, the problem was addressed at its root by
320			transparently using appropriate, automatic file offset sizes. So when writing
321			.gig/DLS/RIFF files smaller than 2 GB there are still 32 bit file offsets
322			being used by libgig. Accordingly such files are still backward compatible
323			with older software. However if the overall file size to be written is 2 GB or
324			larger, then 64 bit file offsets are automatically used by libgig instead.
325			Note though that due to that circumstance such files ≧ 2 GB are not backward
326			compatible with older versions of libgig, nor could they be loaded with the
327			original GigaStudio software.
328			</p>
329
330			<h3>Serialization API</h3>
331			<p>
332			Another major new feature in this libgig release is the entirely new
333			<a href="http://download.linuxsampler.org/doc/libgig/api/namespaceSerialization.html">Serialization API</a>
334			which provides a powerful and easy way
335			to serialize and deserialize an arbitrary set of native C++ objects into an
336			abstract data stream. Which means you can simply save the entire runtime state
337			of an application to a file or send it as data over "wire" (i.e. over network
338			or to another process) and restore that runtime state from that data there at
339			any time. In contrast to other C++ serialization frameworks out there, this
340			framework provides two major benefits:
341			<ol>
342			<li>
343			This serialization framework is designed to be very robust regarding
344			potential versioning changes of the native C++ classes being
345			(de)serialized. So even if the C++ classes have seen massive software
346			changes between the point where they were serialized and the point where
347			they are to be deserialized; for example if class member variables of
348			serialized C++ objects were renamed in meantime, or if variable offsets, or
349			variables' data types had been changed, then the deserialization algorithm
350			can still cope with such common software changes automatically in many
351			cases, that is as long as the deserialization algorithm can "guess" what
352			the changes were exactly. If the serialization framework is unable to
353			automatically detect the precise software changes, then it will abort the
354			deserialization task with an exception and an error message stating that
355			the software versions are incompatible.
356			</li>
357			<li>
358			This serialization framework supports "partial" deserialization. That
359			means it not only allows to restore an entire runtime state, but it also
360			allows to only restore an arbitrary desired subset of information
361			from the previously serialized data stream, while leaving all other data
362			of the running C++ objects untouched. The serialization framework also
363			incorporates a reflection API which allows applications to implement
364			convenient editors on top of such serialized data, i.e. allowing end users
365			to pick or alter specific information within the serialized data.
366			</li>
367			</ol>
368			This new Serialization framework is already embedded into the gig classes of
369			libgig, and it is used as basis for the new powerful macro features in the
370			gigedit instrument editor, like already outlined above.
371			</p>
372
373			</body>
374			</html>