1 |
<html> |
2 |
<head> |
3 |
<meta name="author" content="Christian Schoenebeck"> |
4 |
<title>Release Notes LinuxSampler 2.1.1</title> |
5 |
<navpath>LinuxSampler 2.1.1</navpath> |
6 |
<meta name="description" content="Release notes for LinuxSampler 2.1.1."> |
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.1.1</h1> |
12 |
<p> |
13 |
LinuxSampler 2.1.1 and friends were released on July 27th 2019. |
14 |
This is mainly a maintenance release with fixes of the |
15 |
<a href="01_linuxsampler_2_1_0.html">previous release</a>. So the |
16 |
release notes will be quite short this time since there are only very |
17 |
few and minor new features in this release. |
18 |
</p> |
19 |
|
20 |
<h3>Upcoming C++11 Requirement</h3> |
21 |
<p> |
22 |
Please note that this will most probably be the last release still supporting |
23 |
compilers which are not C++11 compliant. There are plans for new engine |
24 |
features for the next major release of the sampler which will strictly rely on |
25 |
C++11 support by the compiler. Because some of the planned new features |
26 |
are hardly feasible without C++11 language support at all and maintaining |
27 |
legacy support for such old compilers simply no longer makes sense. |
28 |
</p> |
29 |
|
30 |
<h3>Real-Time Instrument Scripts</h3> |
31 |
<p> |
32 |
Behaviour of the built-in <a href="01_nksp.html">NKSP</a> functions |
33 |
<code lang="nksp">change_sustain()</code>, |
34 |
<code lang="nksp">change_cutoff_attack()</code>, |
35 |
<code lang="nksp">change_cutoff_decay()</code>, |
36 |
<code lang="nksp">change_cutoff_sustain()</code>, |
37 |
<code lang="nksp">change_cutoff_release()</code> have been fixed.<br> |
38 |
<br> |
39 |
<a href="instrument_scripts.html">Find out more about scripts ...</a> |
40 |
</p> |
41 |
|
42 |
<h3>SFZ Engine</h3> |
43 |
<p> |
44 |
The sfz engine adds support for the commonly used built-in sample |
45 |
<code lang="none">'*silence'</code> of the sfz format. See the |
46 |
<code lang="sfz">sample</code> opcode for details. It does what you |
47 |
think it does; it |
48 |
instructs the sampler to play no sound at all. This is commonly used |
49 |
in sfz files for instance for the lowest velocity switch to not play any |
50 |
sample. With the previous release trying to load sfz files which used this |
51 |
built-in sample caused a file loading error. There are various other |
52 |
commonly used built-in samples in sfz files which you can denote by the |
53 |
leading star character in the sample name, however the <code lang="none">'*silence'</code> one is |
54 |
currently the only supported built-in sample by our sfz engine yet. Trying |
55 |
to load sfz files which are using other built-in samples does not prevent |
56 |
your instrument from being loaded by the sampler, however you will get a |
57 |
warning message on the console that the built-in sample is not supported |
58 |
yet and the sampler will simply play silence for that non supported |
59 |
built-in sample. |
60 |
</p> |
61 |
|
62 |
<h3>GigaStudio Format Engine</h3> |
63 |
<p> |
64 |
The Giga format engine adds a format extension which allows sound |
65 |
designers to define whether release trigger samples shall be played when |
66 |
the sustain pedal is released. In the previous release this was actually |
67 |
the default behaviour by the sampler, but meanwhile there was a consensus |
68 |
on the |
69 |
<a href="https://sourceforge.net/projects/linuxsampler/lists/linuxsampler-devel">mailing list</a> |
70 |
that release samples being triggered by sustain pedal |
71 |
is not the common, expected behaviour. So this is no longer the default |
72 |
behaviour by the sampler, but you can still opt in to this old behaviour by using this |
73 |
new format extension option (see Gigedit changes below for details). If you |
74 |
don't enable this option then release samples are now only triggered by |
75 |
note-off events. |
76 |
</p> |
77 |
|
78 |
<h2>Gigedit 1.1.1</h2> |
79 |
<p> |
80 |
Our instrument editor for the GigaStudio/Gigasampler format received |
81 |
primarily fixes as well, but also the following few new features. |
82 |
</p> |
83 |
|
84 |
<h3>File Format Version</h3> |
85 |
<p> |
86 |
<img src="gigedit_file_format_v4_select.png" title="File Format Selection"> |
87 |
From the file properties dialog you can now choose to specifically save a |
88 |
gig file in GigaStudio v4 file format (from the main menu select |
89 |
"File" -> "Properties" -> "File Format"). So you can override the file |
90 |
format version of already existing gig files that way. |
91 |
</p> |
92 |
|
93 |
<h3>Release Trigger Options</h3> |
94 |
<p> |
95 |
<img src="gigedit_release_trigger_whence.png" title="Release Trigger Options"> |
96 |
There is now a combo box and checkbox on "Misc" tab which allow to define |
97 |
when precisely release trigger samples shall be played. This is an |
98 |
extension of the original gig file format. You have the option to play |
99 |
release trigger samples only on <b>note-off</b> events, or only on |
100 |
<b>sustain pedal up</b> events, or both on note-off events and on sustain pedal |
101 |
up events. These are options on dimension region level, so you can |
102 |
override this behaviour even for individual cases, not just for the |
103 |
entire instrument. |
104 |
</p> |
105 |
|
106 |
<h3>Script Slots Tooltip</h3> |
107 |
<p> |
108 |
<img src="gigedit_scripts_tooltip.png" title="Script Slots Tooltip"> |
109 |
When working on gig files with more than one real-time instrument script |
110 |
per file, it was sometimes a bit tedious to keep track of which instrument |
111 |
was using which script exactly, because it involved a right-click on the |
112 |
individual instrument to get to the script slots dialog of the instrument, |
113 |
which finally listed the scripts being used. You no longer have to do that |
114 |
just to check which scripts are being used: Just hover your mouse over the |
115 |
"Scripts" column of the instruments table on the left hand side of |
116 |
gigedit; a coloured popup will appear with the list of scripts currently |
117 |
being assigned to the instrument.<br> |
118 |
<br> |
119 |
Likewise it is a very common task to remove all scripts from an |
120 |
instrument. There is now a keyboard shortcut for that: Just select the |
121 |
instrument from the instruments list and then hit |
122 |
<b>Shift</b> (⇧) + <b>Backspace</b> (⌫). |
123 |
</p> |
124 |
|
125 |
<h3>Beginners' Tooltips</h3> |
126 |
<p> |
127 |
<img src="gigedit_menu_tooltips_for_beginners.png" title="Beginners' Tooltips"> |
128 |
Gigedit provides a large number of tooltips when you are hovering your |
129 |
mouse over the huge amount of individual controls and menu items the |
130 |
application is offering in the meantime. In case you find that annoying, |
131 |
you can now disable those particular tooltips which are specifically |
132 |
intended for beginners from the main menu by unchecking "View" -> |
133 |
"Tooltips for Beginners". All other tooltips that are still useful for |
134 |
daily work with gigedit are still being shown when this option is |
135 |
unchecked. |
136 |
</p> |
137 |
|
138 |
<h3>Function Keys</h3> |
139 |
<p> |
140 |
The previous release of gigedit introduced "Macros" for quickly |
141 |
performing frequently used sequences of editor actions, and you were able |
142 |
to assign your macros to keyboard function keys F1 .. F12. In this release |
143 |
you can now also assign macros to function keys up to F19, in case you own |
144 |
one of those keyboards with such a large amount of function keys. |
145 |
</p> |
146 |
|
147 |
<h2>libgig 4.2.0</h2> |
148 |
<p> |
149 |
Our fundamental file access C++ library |
150 |
<a href="https://download.linuxsampler.org/doc/libgig/api/">libgig</a> |
151 |
has also received primarily corrections and improvements, which are outlined next. |
152 |
</p> |
153 |
|
154 |
<h3>GigaStudio v4</h3> |
155 |
<p> |
156 |
This release of libgig contains important fixes concerning the |
157 |
GigaStudio v4 format. For instance in the previous release gig v4 files |
158 |
were falsely detected as gig v2 files by libgig, which was leading to |
159 |
numerous undesired behaviours. |
160 |
</p> |
161 |
|
162 |
<h3>Extension Files</h3> |
163 |
<p> |
164 |
It is now possible to write large gig files splitted over extension |
165 |
files (.gx01, .gx02, ...). Previously it was only possible to read gig |
166 |
files with extension files, but libgig only supported to save large gig |
167 |
files as one single, monolithic gig file. The problem with the latter |
168 |
was that gig files >= 2 GB could only be read by libgig, but could not |
169 |
be loaded with any version of GigaStudio. So this solves that legacy |
170 |
support issue, and you have the freedom to switch between a single, large |
171 |
gig file or rather this extension file based format at any time. |
172 |
</p> |
173 |
|
174 |
</body> |
175 |
</html> |