linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] EGs

[Aaron L. <dar...@gm...>]

On Tue, Jul 18, 2017 at 7:46 AM, Christian Schoenebeck <
sch...@li...> wrote:

> Hi everybody,
>
> after reviewing the code of the envelope generators, I noticed that I
> implemented the state machine of the EGs incorrectly years ago. The common
> behavior of EGs is that the attack, decay and decay hold phases are always
> played entirely according to their defined duration in the instrument
> patch.
> With our current EGs however the attack and decay phases are aborted as
> soon
> as a note-off arrives, so the EG immediately switches into the release
> phase
> too early on short notes. That's especially problematic for percussive
> instruments.
>
> So if there are no vetoes, I am going to change that, so that even if a
> note-
> off arrives very early, the attack, decay and decay hold phases are always
> played entirely to their stage end, and after the attack and decay phases
> completed their defined durations, the EG would then switch into release
> phase
> afterwards.
>
> That will obviously change the behavior and thus the sound of existing
> sounds.
> But I think that change really makes sense, and probably this behavior
> change
> does not even have a negative impact on existing sounds.
>
> Another change I planned regarding the EGs: we currently have a behavior
> which
> is probably a bit exotic compared to common EG implementations; if a voice
> is
> in release phase and a new note-on arrives on that respective MIDI note,
> our
> EGs abort the release phase and switch back to the previous phase (i.e.
> back
> to sustain phase). Now that behavior is sometimes useful, sometimes
> negative,
> depends on the sound. So maybe I make that configurable, I am not very sure
> about this particular change yet.
>
> If you have an opinion on these two EG issues, let me know!
>
> CU
> Christian


Yes, that certainly seems like a bug; good catch.

Likewise, I think allowing the release to continue after a new note-on
should be configurable. In "absurd" cases, it may contribute to excessive
polyphony, but in the normal case, I think the releases would be
appreciated.

In Christ,
Aaron Laws

[Linuxsampler-devel] EGs

[Christian S. <sch...@li...>]

Hi everybody,

after reviewing the code of the envelope generators, I noticed that I 
implemented the state machine of the EGs incorrectly years ago. The common 
behavior of EGs is that the attack, decay and decay hold phases are always 
played entirely according to their defined duration in the instrument patch. 
With our current EGs however the attack and decay phases are aborted as soon 
as a note-off arrives, so the EG immediately switches into the release phase 
too early on short notes. That's especially problematic for percussive 
instruments.

So if there are no vetoes, I am going to change that, so that even if a note-
off arrives very early, the attack, decay and decay hold phases are always 
played entirely to their stage end, and after the attack and decay phases 
completed their defined durations, the EG would then switch into release phase 
afterwards.

That will obviously change the behavior and thus the sound of existing sounds. 
But I think that change really makes sense, and probably this behavior change 
does not even have a negative impact on existing sounds.

Another change I planned regarding the EGs: we currently have a behavior which 
is probably a bit exotic compared to common EG implementations; if a voice is 
in release phase and a new note-on arrives on that respective MIDI note, our 
EGs abort the release phase and switch back to the previous phase (i.e. back 
to sustain phase). Now that behavior is sometimes useful, sometimes negative, 
depends on the sound. So maybe I make that configurable, I am not very sure 
about this particular change yet.

If you have an opinion on these two EG issues, let me know!

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Re-saving file as gig v3?

[Christian S. <sch...@li...>]

On Sunday, July 16, 2017 18:31:23 Andrew C wrote:
> I assume if I just re-save the file using 'file -> save as', gigedit will
> re-save it as a gig v3 format file?

No, gigedit won't do that automatically. That behavior is intentional. Because 
otherwise the gig file would no longer load in older GigaStudio versions 
(talking about the original software on Windows). So you must go the file 
properties in gigedit, then switch the combo box from v2 to v3 and then save 
the gig file. After you did that, combining your instruments should work just 
fine.

BTW you only get that warning message if the combine algorithm would need to 
use a feature that is only available with Gig format v3 (i.e. if the 
instrument would exceed the v2 limitation of max. dimension regions).

Also when you create instruments from scratch, gigedit will create them as v3 
format by default. So you only have v2 format gig files if you got them from 
somewhere else (i.e. commercial gig library, downloaded from a shop, etc).

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] Re-saving file as gig v3?

[Andrew C <cou...@gm...>]

Hey all,

I'm trying to combine some instruments together in a gig file, but when I
do I get the message

 "You are currently using a .gig file in old v2 format. The current combine
algorithm will most probably fail trying to combine instruments in this old
format. So better save the file in new v3 format before trying to combine
your instruments."

I assume if I just re-save the file using 'file -> save as', gigedit will
re-save it as a gig v3 format file?

Thanks,

Andrew.

Re: [Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Christian S. <sch...@li...>]

On Monday, July 10, 2017 23:43:14 Andrew C wrote:
> Great! Thank you for the fix and extended functionality. This makes it alot
> easier for me!
> 
> P.S Did you get my e-mail with the lscp-to-idf script and transitionfx giga
> file?

I admit I received it, but forgot to upload it to an appropriate place yet. I 
try to do that during this week.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Andrew C <cou...@gm...>]

Great! Thank you for the fix and extended functionality. This makes it alot
easier for me!

P.S Did you get my e-mail with the lscp-to-idf script and transitionfx giga
file?

Thanks!

On Sun, Jul 9, 2017 at 7:32 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Sunday, July 09, 2017 13:30:57 Christian Schoenebeck wrote:
> > On Sunday, July 09, 2017 11:39:28 Andrew C wrote:
> > > Thanks! That worked out perfectly for me.
> > > I had looked at the Maestro concert grand gig file last night to try
> and
> > > work out what 'order' to combine the instruments, thinking I had to do
> the
> > > release trigger layer first, then the velocity and it was giving me all
> > > kinds of headaches.
> > >
> > > Guess I was doing it completely backwards! :)
> >
> > Yeah, the point here is that you currently cannot change the order
> directly
> > within the combine tool dialog itself. So it does not matter for instance
> > which one of the instruments you select first in the combine tool
> dialog. So
> > yes, that has to be improved or at least there should be some note that
> you
> > must change the order in the instruments list first before calling the
> > combine dialog.
>
> I just addressed these issues. Now (gigedit 1.0.0.svn55) it is quite
> convenient to combine instruments:
>
> 1. Simply select the instruments you want to combine directly from the main
>    window's instrument list by Ctrl clicking on them.
>
> 2. Use the new keyboard shortcut Ctrl + j (for "join"), or open the combine
>    tool dialog manually from the menu. Now the combine tool dialog pops up
> and
>    the instruments are already pre-selected.
>
> 3. At the bottom of the combine tool dialog there is now a new horizontal
>    list, showing you the currently selected items. Use drag & drop to alter
>    the sequence in which they are going to be combined.
>
> 4. Click "Ok". The dialog disappears and the instrument list automatically
>    scrolls to the newly added (combined) instrument.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Christian S. <sch...@li...>]

On Sunday, July 09, 2017 13:30:57 Christian Schoenebeck wrote:
> On Sunday, July 09, 2017 11:39:28 Andrew C wrote:
> > Thanks! That worked out perfectly for me.
> > I had looked at the Maestro concert grand gig file last night to try and
> > work out what 'order' to combine the instruments, thinking I had to do the
> > release trigger layer first, then the velocity and it was giving me all
> > kinds of headaches.
> > 
> > Guess I was doing it completely backwards! :)
> 
> Yeah, the point here is that you currently cannot change the order directly
> within the combine tool dialog itself. So it does not matter for instance
> which one of the instruments you select first in the combine tool dialog. So
> yes, that has to be improved or at least there should be some note that you
> must change the order in the instruments list first before calling the
> combine dialog.

I just addressed these issues. Now (gigedit 1.0.0.svn55) it is quite 
convenient to combine instruments:

1. Simply select the instruments you want to combine directly from the main 
   window's instrument list by Ctrl clicking on them.

2. Use the new keyboard shortcut Ctrl + j (for "join"), or open the combine 
   tool dialog manually from the menu. Now the combine tool dialog pops up and 
   the instruments are already pre-selected.

3. At the bottom of the combine tool dialog there is now a new horizontal
   list, showing you the currently selected items. Use drag & drop to alter
   the sequence in which they are going to be combined.

4. Click "Ok". The dialog disappears and the instrument list automatically 
   scrolls to the newly added (combined) instrument.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Christian S. <sch...@li...>]

On Sunday, July 09, 2017 11:39:28 Andrew C wrote:
> Thanks! That worked out perfectly for me.
> I had looked at the Maestro concert grand gig file last night to try and
> work out what 'order' to combine the instruments, thinking I had to do the
> release trigger layer first, then the velocity and it was giving me all
> kinds of headaches.
> 
> Guess I was doing it completely backwards! :)

Yeah, the point here is that you currently cannot change the order directly 
within the combine tool dialog itself. So it does not matter for instance 
which one of the instruments you select first in the combine tool dialog. So 
yes, that has to be improved or at least there should be some note that you 
must change the order in the instruments list first before calling the combine 
dialog.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Andrew C <cou...@gm...>]

Thanks! That worked out perfectly for me.
I had looked at the Maestro concert grand gig file last night to try and
work out what 'order' to combine the instruments, thinking I had to do the
release trigger layer first, then the velocity and it was giving me all
kinds of headaches.

Guess I was doing it completely backwards! :)

On Sun, Jul 9, 2017 at 11:29 AM, Christian Schoenebeck <
sch...@li...> wrote:

> On Saturday, July 08, 2017 21:54:55 Andrew C wrote:
> > Thanks for that, Christian!
> >
> > On a related note, is there any relatively painless way to automatically
> > combine a) a multi-velocity instrument patch with b) a set of
> > multi-velocity release samples?
> > The thought of having to manually drag and drop release triggers for
> > multiple velocities is quite daunting to put it lightly.
>
> Sure, use the "combine" tool. Main menu of gigedit -> Tools -> Combine
> Instruments. Then Ctrl click on the two instruments you want to combine,
> select the release trigger dimension as the dimension to combine them and
> click on Ok.
>
> Note that the sequence of the selected instruments matters. So make sure
> the
> instrument with the regular samples is in the instruments list before the
> instrument with the release samples. If that's not the case use drag and
> drop
> on the instruments list to correct this sequence before using the combine
> tool.
>
> Tip: if the combine tool causes any issues like samples are missing in the
> combined instrument, then combine the two instruments with the "layer"
> dimension first, then afterwards select the newly combined instrument,
> double
> click any region, the region's dimension manager dialog will popup, check
> the
> "Alll regions" checkbox and then change the layer dimension type to release
> trigger dimension type.
>
> That should do it.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Christian S. <sch...@li...>]

On Saturday, July 08, 2017 21:54:55 Andrew C wrote:
> Thanks for that, Christian!
> 
> On a related note, is there any relatively painless way to automatically
> combine a) a multi-velocity instrument patch with b) a set of
> multi-velocity release samples?
> The thought of having to manually drag and drop release triggers for
> multiple velocities is quite daunting to put it lightly.

Sure, use the "combine" tool. Main menu of gigedit -> Tools -> Combine 
Instruments. Then Ctrl click on the two instruments you want to combine, 
select the release trigger dimension as the dimension to combine them and 
click on Ok.

Note that the sequence of the selected instruments matters. So make sure the 
instrument with the regular samples is in the instruments list before the 
instrument with the release samples. If that's not the case use drag and drop 
on the instruments list to correct this sequence before using the combine 
tool.

Tip: if the combine tool causes any issues like samples are missing in the 
combined instrument, then combine the two instruments with the "layer" 
dimension first, then afterwards select the newly combined instrument, double 
click any region, the region's dimension manager dialog will popup, check the 
"Alll regions" checkbox and then change the layer dimension type to release 
trigger dimension type.

That should do it.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Andrew C <cou...@gm...>]

Thanks for that, Christian!

On a related note, is there any relatively painless way to automatically
combine a) a multi-velocity instrument patch with b) a set of
multi-velocity release samples?
The thought of having to manually drag and drop release triggers for
multiple velocities is quite daunting to put it lightly.

Andrew.

On Sat, Jul 8, 2017 at 6:22 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Saturday, July 08, 2017 14:02:11 Andrew C wrote:
> > Not sure if this is a bug or intended behaviour, but if I remove a sample
> > from a dimension and have 'all regions' selected, only that particular
> > region's dimension is affected.
>
> Yes, that's most probably a bug, or rather I forgot to implement the "for
> all"
> behavior for that specific feature, because assigning a null sample is not
> used that often, so I never stumbled over this being still missing.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Christian S. <sch...@li...>]

On Saturday, July 08, 2017 14:02:11 Andrew C wrote:
> Not sure if this is a bug or intended behaviour, but if I remove a sample
> from a dimension and have 'all regions' selected, only that particular
> region's dimension is affected.

Yes, that's most probably a bug, or rather I forgot to implement the "for all" 
behavior for that specific feature, because assigning a null sample is not 
used that often, so I never stumbled over this being still missing.

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] Bug? Removing a sample from a dimension with 'all regions' selected only affects current region

[Andrew C <cou...@gm...>]

Not sure if this is a bug or intended behaviour, but if I remove a sample
from a dimension and have 'all regions' selected, only that particular
region's dimension is affected.

Andrew.

Re: [Linuxsampler-devel] [linuxsampler-devel] Wrote an lscp midi instrument -> Muse .idf script.

[Christian S. <sch...@li...>]

On Friday, June 23, 2017 13:26:29 Andrew C wrote:
> So I spent the last 2 days writing 2 scripts that A) extracts the program
> and bank names from an LSCP file and B) converts it into Muse's .idf format
> for easy patch changes inside the sequencer.
> 
> I've read that guys like Anders Danielson and Chris Cherret wrote similar
> scripts way back in 2009, but I can't find them anywhere.

Probably part of the openoctave stuff.

> Would anyone be interested in these scripts? Should I post them to the LS
> forums for posterity's sake?
> 
> They are extremely crude, inefficient and my use/abuse of sed is probably
> horrifying to see, but they get the job done.

If you want I can upload them somewhere if you give some words to people how 
to use them.

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] Wrote an lscp midi instrument -> Muse .idf script.

[Andrew C <cou...@gm...>]

So I spent the last 2 days writing 2 scripts that A) extracts the program
and bank names from an LSCP file and B) converts it into Muse's .idf format
for easy patch changes inside the sequencer.

I've read that guys like Anders Danielson and Chris Cherret wrote similar
scripts way back in 2009, but I can't find them anywhere.

Would anyone be interested in these scripts? Should I post them to the LS
forums for posterity's sake?

They are extremely crude, inefficient and my use/abuse of sed is probably
horrifying to see, but they get the job done.

Andrew.

[Linuxsampler-devel] [linuxsampler-devel] 2 gigedit bugs found

[Andrew C <cou...@gm...>]

Found two bugs with gigedit:

1. 'changes apply to all regions' tickbox does not apply dimension changes
to all regions, only the current region selected.

2. Using 'combine instruments' and selecting the modwheel to combine the
instruments by results in only 1 modwheel dimension area having
samples(0-64), and the rest of the samples(64-127, etc) are unassigned/NULL.

Cheers.

Andrew.

Re: [Linuxsampler-devel] [linuxsampler-devel] Gigedit feature wishlist

[Andrew C <cou...@gm...>]

>You can also change the dimension type of all regions simultaneously like
>described in those old release notes. Just click the "All regions" check
box
>in the "Dimensions" dialog, then change the respective dimension type.

Think I have a bug here, then. I tried changing a dimension from 'velocity'
to 'layer' with the 'all regions' tickbox on.
It only changed the dimension for the currently selected region.

On Mon, Jun 5, 2017 at 1:51 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Monday, June 05, 2017 13:32:05 Andrew C wrote:
> > One other 'ease of use' thing, which in practice might bring up alot more
> > issues, but would it be possible to be able to select (via either ctrl
> > click or shift-click) all/a number of Regions and apply dimension changes
> > to them all at once?
>
> For most operations this already works like expected by you. No matter if
> you
> change some synthesis parameter, change the exact upper and lower limits
> of a
> dimension zone by dragging around the dimension zone boundaries with the
> mouse, and much more, those are already applied automatically to the
> selected
> regions and selected dimension regions.
>
> You can also change the dimension type of all regions simultaneously like
> described in those old release notes. Just click the "All regions" check
> box
> in the "Dimensions" dialog, then change the respective dimension type.
>
> > Individually adding a velocity dimension to say, each 88 regions of a
> piano
> > patch, would be a bit of a tedious thing.
>
> Same thing. Click on "All regions" of the "Dimensions" dialog. Then add the
> new dimension. It will automatically added to the regions which don't have
> that dimension yet.
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

[Linuxsampler-devel] Patch for ARM (raspberry PI) support

[Steve B. <st...@st...>]

The zynthian[1] project would like to upgrade to linuxsampler-2 but the
source currently requires patching to add ARM support.

The attached patch to RTPath.cpp and atomic.h is required. The patch will
also be maintained in this github repo[2] until it lands in trunk.

The Raspberry PI 3 is more than capable of running linuxsampler, so it
would be great if this patch could be applied to the main source tree.

[1] http://zynthian.org/
[2] https://github.com/steveb/rpi_linuxsampler_patch

Re: [Linuxsampler-devel] [linuxsampler-devel] Gigedit feature wishlist

[Christian S. <sch...@li...>]

On Monday, June 05, 2017 13:32:05 Andrew C wrote:
> One other 'ease of use' thing, which in practice might bring up alot more
> issues, but would it be possible to be able to select (via either ctrl
> click or shift-click) all/a number of Regions and apply dimension changes
> to them all at once?

For most operations this already works like expected by you. No matter if you 
change some synthesis parameter, change the exact upper and lower limits of a 
dimension zone by dragging around the dimension zone boundaries with the 
mouse, and much more, those are already applied automatically to the selected 
regions and selected dimension regions.

You can also change the dimension type of all regions simultaneously like 
described in those old release notes. Just click the "All regions" check box 
in the "Dimensions" dialog, then change the respective dimension type.

> Individually adding a velocity dimension to say, each 88 regions of a piano
> patch, would be a bit of a tedious thing.

Same thing. Click on "All regions" of the "Dimensions" dialog. Then add the 
new dimension. It will automatically added to the regions which don't have 
that dimension yet.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Gigedit feature wishlist

[Andrew C <cou...@gm...>]

Thanks alot for the informativ response, Christian. The release notes you
also linked were a good resource too.
Truthfully I had never even though of trying out the 'dimensions...' tab.
:P At least I know that now.

One other 'ease of use' thing, which in practice might bring up alot more
issues, but would it be possible to be able to select (via either ctrl
click or shift-click) all/a number of Regions and apply dimension changes
to them all at once?
Individually adding a velocity dimension to say, each 88 regions of a piano
patch, would be a bit of a tedious thing.

Andrew.

On Mon, Jun 5, 2017 at 11:50 AM, Christian Schoenebeck <
sch...@li...> wrote:

> On Sunday, June 04, 2017 23:01:15 Andrew C wrote:
> > In no particular order, there are some features I wouldn't mind seeing in
> > gigedit:
> >
> > Save individual instrument to its own gig file.
> > - We can merge instruments in gig files, why not split them too?
>
> 1. Press and hold "Ctrl" key.
> 2. Select the instruments you want to delete with the mouse.
> 3. Right click with mouse and select "Remove".
> 4. Select "Save as ..." from main menu and save the file under the desired
> new
>    file name.
> 5. Now click on the the "Samples" tab.
> 6. Right click on any sample, then select "Remove Unused Samples".
> 7. Select "Save" from the main menu.
>
> > Change dimension types after they're already created.
> > - Could it be possible to rightclick and change a dimension type, like
> > velocity dimensions to layer dimensions or modwheel/roundrobinkeyboard
> > dimensions and vice versa without having to destroy the whole layer and
> > rebuild the dimension from scratch?
>
> It actually works already like this!
>
> 1. Right click on region.
> 2. Select "Dimensions...".
> 3. Double click on the dimension type name of the respective dimension.
> 4. Select the new dimension type from the combo box and click "OK".
>
> BTW, changing the amount of dimension zones is maybe not that obvious. One
> might expect to be able to change that from that "Dimensions..." dialog as
> well. But it works differently, because it requires the additional info
> "where" exactly shall the new zone be added, or which existing ones exactly
> shall be removed.
>
> so to increase the amount of zones of a dimension:
>
> 1. Select a region.
> 2. Then right click on a specific dimension zone (at the bottom of the main
>    window).
> 3. Select "Split Dimension Zone".
>
> Likewise to decrease the amount of dimension zones:
>
> 1. Select a region.
> 2. Then right click on a specific dimension zone.
> 3. Select "Delete Dimension Zone".
>
> All those gigedit features already exist for a while. So you might also
> have a
> look at those old release notes:
>
> http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_
> 0_0/#gigedit_1_0_0
>
> CU
> Christian
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] [linuxsampler-devel] Gigedit feature wishlist

[Christian S. <sch...@li...>]

On Sunday, June 04, 2017 23:01:15 Andrew C wrote:
> In no particular order, there are some features I wouldn't mind seeing in
> gigedit:
> 
> Save individual instrument to its own gig file.
> - We can merge instruments in gig files, why not split them too?

1. Press and hold "Ctrl" key.
2. Select the instruments you want to delete with the mouse.
3. Right click with mouse and select "Remove".
4. Select "Save as ..." from main menu and save the file under the desired new 
   file name.
5. Now click on the the "Samples" tab.
6. Right click on any sample, then select "Remove Unused Samples".
7. Select "Save" from the main menu.

> Change dimension types after they're already created.
> - Could it be possible to rightclick and change a dimension type, like
> velocity dimensions to layer dimensions or modwheel/roundrobinkeyboard
> dimensions and vice versa without having to destroy the whole layer and
> rebuild the dimension from scratch?

It actually works already like this!

1. Right click on region.
2. Select "Dimensions...".
3. Double click on the dimension type name of the respective dimension.
4. Select the new dimension type from the combo box and click "OK".

BTW, changing the amount of dimension zones is maybe not that obvious. One 
might expect to be able to change that from that "Dimensions..." dialog as 
well. But it works differently, because it requires the additional info 
"where" exactly shall the new zone be added, or which existing ones exactly 
shall be removed.

so to increase the amount of zones of a dimension:

1. Select a region.
2. Then right click on a specific dimension zone (at the bottom of the main 
   window).
3. Select "Split Dimension Zone".

Likewise to decrease the amount of dimension zones:

1. Select a region.
2. Then right click on a specific dimension zone.
3. Select "Delete Dimension Zone".

All those gigedit features already exist for a while. So you might also have a 
look at those old release notes:

http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_0_0/#gigedit_1_0_0

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] Gigedit feature wishlist

[Andrew C <cou...@gm...>]

In no particular order, there are some features I wouldn't mind seeing in
gigedit:

Save individual instrument to its own gig file.
- We can merge instruments in gig files, why not split them too?

Automap feature.
- Or more like "Select files from a pop-up file browser and assign the wav
files to keys/dimensions in the order they're selected."

Change dimension types after they're already created.
- Could it be possible to rightclick and change a dimension type, like
velocity dimensions to layer dimensions or modwheel/roundrobinkeyboard
dimensions and vice versa without having to destroy the whole layer and
rebuild the dimension from scratch?

Andrew.

Re: [Linuxsampler-devel] Andrew's KISS instrument scripts: mono mode and alternation

[Christian S. <sch...@li...>]

On Saturday, June 03, 2017 08:58:57 Andrew C wrote:
> Hey list,
> 
> Guess someone might find these scripts useful.

Just some tips on these ones ...

>   if (%CC[64] = 127)
>      note_off($active_note)
>      $active_note := play_note($EVENT_NOTE, $EVENT_VELOCITY)
>        else
> 
>     $active_note := play_note($EVENT_NOTE, $EVENT_VELOCITY)
> 
>   end if

I would recommend you to always use a comparison like this

    if (%CC[64] > 63)
        ...
    end if

for any CC switches instead, especially since half damper (continuous) pedals 
become more and more popular. Otherwise your script will not work for those 
people.

> Alternation script:
> ---
> 
> on init
> declare $alt := 0
> end on
> 
> on note
> 
> select $alt
> 
> case 0
> change_note($EVENT_ID, $EVENT_NOTE) {up bow}
> $alt := 1
> case 1
> change_note($EVENT_ID, $EVENT_NOTE+36) {down bow}
> 
> $alt := 0
> end select
> 
> end on

Since you mentioned before that you have some legato/glissando gig files, you 
might also have a look at gig_set_dim_zone():

http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/Reference/gig_set_dim_zone_function/

That function is extremely useful for writing scripts for gig format sounds. 
For example your legato/glissando sounds most probably have their alternative 
samples mapped to zones of the "Smart MIDI" dimension. By calling the upper 
function i.e. like this:

	gig_set_dim_zone($myNoteID, $GIG_DIM_SMARTMIDI, 2)

you would force the sampler to pick the third zone (zero indexed) of the smart 
midi dimension for the requested note, and hence you can force the sampler to 
play a different sample to be played on the same key (/ same region).

Obviously you can also use this function with all other dimensions. If the 
region has more than one dimension, you can also call this function more than 
once on the same note, to specifically force one specific dimension zone for 
each dimensions.

CU
Christian

[Linuxsampler-devel] Andrew's KISS instrument scripts: mono mode and alternation

[Andrew C <cou...@gm...>]

Hey list,

Guess someone might find these scripts useful.

First one is a simple mono-mode script that makes the instrument monophonic
when the sustain pedal is pressed down.

The second one is a simple transposition script that alternates between
playing the note you've currently played and the note 3 octaves above it.
Useful for those sample libraries that have their up and down bows mapped
to different octaves on the keyboard.

Enjoy!

Andrew Coughlan.

Mono mode script:
--

on init
declare $active_note
end on

on note

ignore_event()


  if (%CC[64] = 127)
     note_off($active_note)
     $active_note := play_note($EVENT_NOTE, $EVENT_VELOCITY)
       else

    $active_note := play_note($EVENT_NOTE, $EVENT_VELOCITY)

  end if

end on

+++

Alternation script:
---

on init
declare $alt := 0
end on

on note

select $alt

case 0
change_note($EVENT_ID, $EVENT_NOTE) {up bow}
$alt := 1
case 1
change_note($EVENT_ID, $EVENT_NOTE+36) {down bow}

$alt := 0
end select

end on

Re: [Linuxsampler-devel] [linuxsampler-devel] New note object should be created when play_note() is called

[Christian S. <sch...@li...>]

On Tuesday, May 30, 2017 07:33:18 Andrew C wrote:
> I saw the following:
> "
> 
> on note
>   disallow_group($ALL_GROUPS)  { turn all groups off }
>   allow_group(0)                         { turn first group on }
>   ignore_event($EVENT_ID)         { inhibit triggering note from being
> played } play_note($EVENT_NOTE, $EVENT_VELOCITY, 0, -1)          { replay
> note } end note
> "
> 
> It's just a fragment, but yes, it seems like play_note can still
> trigger the note and follow the 'note_on/note_off' of the note handler
> itself.

Ok, since you say it is just a fragment of the overall code, I can just guess 
that this technique might he used as an alternative for calling change_*() 
functions for the triggered note.

I do see use cases which were not possible with our implementation of 
play_note(), so I just implemented the following behavior changes of the 
play_note() function:

* If -1 was passed for the "duration" argument and the parent note is already 
gone (i.e. because of a previous call to ignore_event()) then play_note() 
silently returns 0 as result value.

* Additionally I added a new special value -2 for argument "duration", which 
essentially enables what you demonstrated.

Here the updated docs:

http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/Reference/play_note_function/

Now I don't know Kontakt's precise behavior on this one, so I am not 
absolutely sure whether these changes are optimal. But let me describe the use 
cases for the two special values -1 and -2 and hence the reason why I think we 
need both:

* Use case for duration = -1 :
------------------------------

on note
  play_note($EVENT_NOTE+12, $EVENT_VELOCITY, -1, -1)
end on

This triggers an additional note (transposed upwards by one octave) each time 
you trigger a key on the keyboard. In this case the new note has a different 
note number, however you still want the new (transposed) note to be released 
when a note-off event arrives on $EVENT_NOTE, not on $EVENT_NOTE+12. So the 
new note's life time is sticked to its causing parent note.

In a more complex script of this use case, you might additionally have some 
logic code afterwards which might drop the original (parent) note on certain 
conditions, then also the already scheduled new (transposed) note should be 
dropped automatically as well, which our current behavior does. So this is a 
very handy feature in this case.

* Use case for duration = -2 :
------------------------------

on controller
  declare $someNoteNr := 60
  declare $someNoteVelocity := 127
  ...
  if ($CC_NUM = 1)
    play_note($someNoteNr, $someNoteVelocity, -1, -2)
  end if
end on

This triggers a new note (i.e. with note number 60) when the modulation wheel 
is used (MIDI CC#1), and sticks the life time of the new note to MIDI note/key 
number 60. So those new voice(s) shall play until a MIDI note-off arrives on 
MIDI note number 60.

As said, I don't know what Kontakt does exactly. It could be that Kontakt's 
duration=-1 case is what we now have as duration=-2, and that they don't have 
our duration=-1 behavior at all. Or their behavior could also be mix of our 
two -1 and -2 cases, such a mix behavior is not desirable IMO though. Maybe 
somebody can check what Kontakt really does here.

CU
Christian