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

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

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

I think I've found a bug with gigedit:

I change the file from gigastudio v2 to gigastudio v3, save and then
re-open the file, but the 'properties' combo box is still set to V2, and I
get the warning when trying to combine instruments.

Andrew.

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

> 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
>
> ------------------------------------------------------------
> ------------------
> 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 crossfade bug

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

>There are simply other issues I find more important right now.
Understandable. Thanks!

On Mon, Jul 24, 2017 at 4:06 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Monday, July 24, 2017 15:44:56 Andrew C wrote:
> > Just to clarify, will the other standalone gigedit bug with the crossfade
> > sliders resetting be looked into in due course? Just wondering!
>
> As I said, that does not have a priority for me at least. So no, I won't
> fix
> that one soon. You just have to reload the new instrument once, then it
> works.
>
> There are simply other issues I find more important right now.
>
> 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 crossfade bug

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

On Mon, Jul 24, 2017 at 10:44 AM, Andrew C <cou...@gm...> wrote:

> Just to clarify, will the other standalone gigedit bug with the crossfade
> sliders resetting be looked into in due course? Just wondering!
>
> Cheers!
>
> Andrew.
>

Without speaking for Christian, I would be willing to wager that patches
are welcome.

In Christ,
Aaron Laws

Re: [Linuxsampler-devel] [linuxsampler-devel Gigedit crossfade bug

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

On Monday, July 24, 2017 15:44:56 Andrew C wrote:
> Just to clarify, will the other standalone gigedit bug with the crossfade
> sliders resetting be looked into in due course? Just wondering!

As I said, that does not have a priority for me at least. So no, I won't fix 
that one soon. You just have to reload the new instrument once, then it works. 

There are simply other issues I find more important right now.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel Gigedit crossfade bug

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

Just to clarify, will the other standalone gigedit bug with the crossfade
sliders resetting be looked into in due course? Just wondering!

Cheers!

Andrew.

On Fri, Jul 21, 2017 at 1:12 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Thursday, July 20, 2017 15:40:23 Andrew C wrote:
> > I forgot, any crossfade programs already made in gigastudio/sampler work
> > fine in LS. Creating new ones with LS seems to be a problem.
>
> Crossfade curves and velocity curves are cached by the sampler. So right
> now
> you need to reload the instrument for those changes to become audible.
> Resolving that is also on my huge TODO list, but honestly it does not have
> a
> high priority for me right now.
>
> 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] EGs

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

On Wednesday, July 19, 2017 13:13:26 Christian Schoenebeck wrote:
> I see, you are right, that behavior regarding attack and decay came from
> your side. Then I am going to make that configurable as another LS
> extension to the gig format and leave the current behavior as default
> behavior.
> 
> In the end I will add 3 additional check boxes to gigedit which allow to
> select for 1.) "attack" stage, 2.) "attack hold" stage and 3.) "decay" stage
> whether the respective stage should be played entirely to its end on
> note-off. That checkbox trio will be available for all 3 EGs separately
> (amp EG, pitch EG, filter EG) as individual configuration.

Ok, I just committed changes for those EG behavior changes to libgig, 
linuxsampler and gigedit.

In gigedit there are now 5 additional checkboxes for EG1, as well as for EG2, 
which allow to configure (on dimregion level) individually whether Attack, 
Attack Hold, Decay 1, Decay 2 and Release may be cancelled.

The previous EG state machine behavior is preserved as default value for those 
settings on libgig level. Which means those 5 checkboxes are all enabled by 
default.

Since EG3 just has one stage (decay) it does not have any options.

On libgig level a linuxsampler specific RIFF chunk is added as extension to 
the gig file format for those new EG options. However that chunk will only be 
added to the gig file if the user changed the settings differing from the 
default values.

I hope I did not break anything. If I did, let me know!

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] cannot open qsampler: cannot find libgig.so.7

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

On Saturday, July 22, 2017 00:52:21 Andrew C wrote:
> I'm not sure if Rui follows this mailing list or not?
> 
> Getting an error with Qsampler having built it from the latest svn:
> qsampler: error while loading shared libraries: libgig.so.7: cannot open
> shared object file: No such file or directory

That probably does not have anything to do with QSampler. This is a common 
error, which in most cases is caused by remains of old libgig installations:

	http://bb.linuxsampler.org/viewtopic.php?f=6&t=264

So get rid of all remains of old libgig versions on your system then recompile 
QSampler.

> On a related note, there are a few 'bugs'/nice-to-haves i've encountered
> with Fantasia, but I wouldn't expect Christian to get his hands full of
> Java, either (and i've read gregor iliev hasn't been seen in a while)!
> (Anyone wanna code a GTK front-end? J/K :D )

Exactly: No, thanks! For both suggestions. :)

BTW, personally I would not pick GTK for any new projects anymore. There are 
so many issues with GTK you have to deal with just for achieving very simple 
tasks, it is not documented at all, and sometimes I have the feeling as if I 
were one of like 5 people still developing with GTK. For example in contrast 
to other toolkits, when I google for a certain GTK issue, I either get links 
to auto generated GTK API docs, or links to the gigedit svn sources. You get 
the point.

So in short: Developing on top of gtk(mm) requires much more development time 
than with other toolkits / APIs. And for your app to behave correctly, you 
should probably even branch your own version of the GTK libs for the project.

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] cannot open qsampler: cannot find libgig.so.7

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

I'm not sure if Rui follows this mailing list or not?

Getting an error with Qsampler having built it from the latest svn:
qsampler: error while loading shared libraries: libgig.so.7: cannot open
shared object file: No such file or directory

On a related note, there are a few 'bugs'/nice-to-haves i've encountered
with Fantasia, but I wouldn't expect Christian to get his hands full of
Java, either (and i've read gregor iliev hasn't been seen in a while)!
(Anyone wanna code a GTK front-end? J/K :D )

Andrew.

Re: [Linuxsampler-devel] EGs

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

On Wednesday, July 19, 2017 17:25:50 Andreas Persson wrote:
> I fine tuned the sfz EG and modeled it after SFZ Player and Rapture
> 2010-01-30. So, that the attack is linear and the decay and release are
> exponential are deliberate (didn't even the original sfz spec say that
> it should be like that? I don't remember).

Most EG implementations use linear for rising stages (i.e. attack) and 
logarithmic curves for falling stages (i.e. decay, release). That has 
historical reasons, since the first EGs based on analogue circuits with their 
simple RC components behaved like that.

> For exponentials the
> interpretation of time values is hard as it depends on how close to the
> target level you count as finished, but I tried to make the calculation
> as close as possible to the SFZ Player/Rapture behavior.

Yes, that's in general the problem with logarithmic stages. To make this more 
clear: Since i.e. a logarithmic release stage will fall down towards zero with 
constantly reduced speed, it never reaches zero level. So which EG level do 
you then consider as end of the release stage? -12 dB? -24 dB? -120 dB? In the 
end we must pick one level to be the "end" level. And accordingly depending on 
which end level we pick, the duration is different to EG implementations of 
other players which have picked another EG level as "end" level.

Since sfz is highly configurable and extensible, maybe somebody already 
suggested an opcode for setting a specific "end" level.

CU
Christian

Re: [Linuxsampler-devel] problem with SFZ release samples

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

On Wednesday, July 19, 2017 12:22:12 David Gritter wrote:
> there are two problems:  In recent linuxsampler implementations
> (2.0.0svn68) the release sample sounds silently (that is no sound is
> heard, but qsampler indicates a sample playing after note off) if the
> region defining it has not lovel/hivel qualifiers.  If these qualifiers
> are present the release sample is never activated.  This leads me to
> believe that the engine is not preserving the note on velocity for use
> with the release sample, and that it is also ignoring a group
> amp_veltrack=0 command.

I haven't checked this, but I guess the sfz engine is using the note-off 
velocity for the release triggered samples instead. And most probably your 
MIDI keyboard is sending note-offs with velocity 0. Maybe somebody who is more 
familiar with the sfz format details can comment on the common expected 
behavior here.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel Gigedit crossfade bug

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

On Thursday, July 20, 2017 15:40:23 Andrew C wrote:
> I forgot, any crossfade programs already made in gigastudio/sampler work
> fine in LS. Creating new ones with LS seems to be a problem.

Crossfade curves and velocity curves are cached by the sampler. So right now 
you need to reload the instrument for those changes to become audible. 
Resolving that is also on my huge TODO list, but honestly it does not have a 
high priority for me right now.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel Gigedit crossfade bug

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

I forgot, any crossfade programs already made in gigastudio/sampler work
fine in LS. Creating new ones with LS seems to be a problem.

On Thu, Jul 20, 2017 at 3:38 PM, Andrew C <cou...@gm...> wrote:

> Found a bug in gigedit's crossfade feature in standalone mode:
>
> Changing any of the 'crossfade' sliders resets the sliders back to 0.
> So if you change 'crossfade in start' to 10 and then 'crossfade in end' to
> 20, 'crossfade in start' gets reset to 0.
>
> Also when I tried making a crossfade in 'live' mode, the crossfade only
> worked for the first velocity layer.
>
> Thanks,
>
> Andrew.
>
> (Should I post these bugs to the bugtracker? I kinda feel like I'm
> spamming the mailing list!)
>

[Linuxsampler-devel] [linuxsampler-devel Gigedit crossfade bug

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

Found a bug in gigedit's crossfade feature in standalone mode:

Changing any of the 'crossfade' sliders resets the sliders back to 0.
So if you change 'crossfade in start' to 10 and then 'crossfade in end' to
20, 'crossfade in start' gets reset to 0.

Also when I tried making a crossfade in 'live' mode, the crossfade only
worked for the first velocity layer.

Thanks,

Andrew.

(Should I post these bugs to the bugtracker? I kinda feel like I'm spamming
the mailing list!)

[Linuxsampler-devel] lscp2idf

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

On Tuesday, July 11, 2017 18:19:00 Christian Schoenebeck wrote:
> 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.

Done:

	http://doc.linuxsampler.org/lscp2idf/

	https://www.linuxsampler.org/misc/lscp2idf/lscp2idf.tar.bz2

	http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/doc/docbase/lscp2idf/

Thanks!

CU
Christian

Re: [Linuxsampler-devel] EGs

[Andreas P. <and...@ou...>]

Den 2017-07-19 kl. 13:24, skrev Christian Schoenebeck:
> On Wednesday, July 19, 2017 10:27:47 you wrote:
>> Hi,
>> I noticed that years ago, but never been able to investigate it, thanks for
>> fixed it. (I used loopmode=one_shot to partially resolve this) While you
>> are watching the EG behaviour, could you please check the ahdsr ramps?
>> Weeks ago I started to write documentation for these opcodes, and I noticed
>> two things I don't know are corrects: 1. Ampeg_decay value should be the
>> time (in seconds) the AMPEG envelope takes to go from "hold" to "sustain",
>> but actually is shorter. 2. Ampeg_release ramp is not linear, while attack
>> and decay are linear.
> No idea about those two. Maybe Andreas can comment on this?
> It could be a left over from the gig engine's EGs. Because the sfz engine was
> originally "branched" from the gig engine and then elements were replaced one
> by one for the required, expected sfz behaviors.
I fine tuned the sfz EG and modeled it after SFZ Player and Rapture 
2010-01-30. So, that the attack is linear and the decay and release are 
exponential are deliberate (didn't even the original sfz spec say that 
it should be like that? I don't remember). For exponentials the 
interpretation of time values is hard as it depends on how close to the 
target level you count as finished, but I tried to make the calculation 
as close as possible to the SFZ Player/Rapture behavior.

/Andreas

[Linuxsampler-devel] problem with SFZ release samples

[David G. <dlg...@am...>]

I have been trying to implement release sample  (trigger=release) in 
linuxsampler using the sfz engine. For these cases the sample triggered 
by note on is looped with loop_continuous, and on note off the release 
sample which contains instrument turn off and room acoustic information 
should be triggered so that the note on sample release time and the 
release sample attack time providing a cross fade so that there is no 
audible transient during the transition.   This approach has worked well 
in the past using GIG files

there are two problems:  In recent linuxsampler implementations 
(2.0.0svn68) the release sample sounds silently (that is no sound is 
heard, but qsampler indicates a sample playing after note off) if the 
region defining it has not lovel/hivel qualifiers.  If these qualifiers 
are present the release sample is never activated.  This leads me to 
believe that the engine is not preserving the note on velocity for use 
with the release sample, and that it is also ignoring a group 
amp_veltrack=0 command.

In earlier linuxsampler implementations, the release sounds audibly for 
both of the cases above. However, the release time for the playing 
sample and the attack time for the release sample are not happening 
properly.  In most cases I see the release time of the playing sample to 
be much faster than specified, and the attack time of the release sample 
to be the specified time.  Also, the release of the playing sample 
occurs some time before the beginning of the attack of the release 
sample.  In order for cross fade to work these both need to begin at the 
same instant in time.  In other cases I have seen behavior where the 
attack and release profiles have large steps in them.

I have copied below an SFZ file to demonstrate these behaviors. The 
sample=sine.wav refers to a 262 Hz sine wave of fixed amplitude duration 
5 seconds that I created with audacity.  The octave below middle C has 
the lovel/hivel qualifiers, the octave above has no such qualifier.  The 
sfz file sounds the release pitched an octave higher than the note on 
pitch so recordings with audacity can easily show the transitions 
between samples.

<group>
amp_veltrack=0
ampeg_attack=0.05
ampeg_release=0.05
sample=sine.wav

<region>
lokey=60
hikey=71
pitch_keycenter=60
loop_mode=loop_continuous


<region>
lokey=60
hikey=71
trigger=release
pitch_keycenter=48
ampeg_hold=0.2
ampeg_decay=2
ampeg_sustain=0
loop_mode=no_loop

<region>
lokey=48
hikey=59
lovel=30
hivel=100
pitch_keycenter=60
loop_mode=loop_continuous


<region>
lokey=48
hikey=59
trigger=release
lovel=30
hivel=100
pitch_keycenter=48
ampeg_hold=0.2
ampeg_decay=2
ampeg_sustain=0
loop_mode=no_loop


Thanks for your attention
Dave Gritter

Re: [Linuxsampler-devel] [linuxsampler-devel] QOL gigedit features?

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

On Wednesday, July 19, 2017 09:04:40 Andrew C wrote:
> Hello all,
> 
> I was thinking of a few QOL features for gigedit:
> 
> 1. Multiple region selection (ctrl click for individual regions. shift
> click for 'from currently selected region to target region selection)

I have that on my TODO list for quite a while, but had no time for it yet. 
Because it actually requires a bunch of changes all over the gigedit code 
base. 

> 2. Move/delete selected regions via keyboard (ctrl+delete to delete, drag
> the regions around with the mouse?)

Moving one region by mouse is already implemented.

For deleting and moving by keyboard shortcut: we will see. I started to use as 
a general keyboard shortcut pattern the Alt key for actions on dimension 
region level, and the Ctrl key instead for actions on region level.

For example you can already navigate among regions with Ctrl + arrow 
left/right.

Likewise you can navigate among dimension region zones with Alt + arrow 
up/down/left/right. And you can even select multiple dimension region zones by 
using Alt + Shift + arrow up/down/left/right.

> 3. Shift click to select multiple instruments in the 'instruments' tab and
> using 'delete' to remove them all at once. I realise you can also ctrl
> click each instrument and then select 'remove' from the instrument menu, so
> I guess this is a shortcut :-)

Well, that is one of the oddities of Gtk I had to fight with. To delete 
multiple consecutive instruments simultaneously first select the first 
instrument in the list view, then press and hold shift, and then the trick: 
click right by mouse, not left! Then select "Remove" from the popup menu.

The problem is if you click left first, and then try right click, the multi 
selection is cleared. I know that behavior is a bit strange, but I remember I 
tried find a workaround for this behavior clash on Gtk level, but it did not 
work. So I was pragmatic and aborted my attempts on fixing that at that point, 
because the described right click trick does it for now.

CU
Christian

Re: [Linuxsampler-devel] EGs

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

On Wednesday, July 19, 2017 10:27:47 you wrote:
> Hi,
> I noticed that years ago, but never been able to investigate it, thanks for
> fixed it. (I used loopmode=one_shot to partially resolve this) While you
> are watching the EG behaviour, could you please check the ahdsr ramps?
> Weeks ago I started to write documentation for these opcodes, and I noticed
> two things I don't know are corrects: 1. Ampeg_decay value should be the
> time (in seconds) the AMPEG envelope takes to go from "hold" to "sustain",
> but actually is shorter. 2. Ampeg_release ramp is not linear, while attack
> and decay are linear.

No idea about those two. Maybe Andreas can comment on this?
It could be a left over from the gig engine's EGs. Because the sfz engine was 
originally "branched" from the gig engine and then elements were replaced one 
by one for the required, expected sfz behaviors.

Since I am going to address the other EG issues mentioned by me as 
configurable options on gig file format level, I take from your response that 
we must also address this for the sfz engine, right? If yes, are there precise 
suggestions for sfz opcodes?

CU
Christian

Re: [Linuxsampler-devel] EGs

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

On Wednesday, July 19, 2017 07:25:50 Andreas Persson wrote:
> Christian Schoenebeck wrote:
> > Correct me if I am wrong, but as far as I can see it right now, you worked
> > on the actual EG curve shapes to replicate the original shapes as
> > accurate as possible, for example that the stages are actually a
> > combination of linear and logarithmic curves in GSt, and the way the
> > durations were calculated by GSt.
> > 
> > However I think that particular issue, that the attack and decay phases
> > are
> > not played entirely to their end, like it is usually the case with EGs in
> > general, is still from the very first EG version that I wrote long time
> > before that. So I think I caused that "bug", and you probably did not
> > compare this precise behavior aspect with GSt. Am I wrong?
> 
> Yes, I think so. I remember doing measurements on how GSt reacted on
> note off in the different stages of EG. I don't remember how much I
> actually had to change the implementation, but at least in the comment
> of my commit r783 I wrote "Release stage can now start before attack
> stage ends."

I see, you are right, that behavior regarding attack and decay came from your 
side. Then I am going to make that configurable as another LS extension to the 
gig format and leave the current behavior as default behavior.

In the end I will add 3 additional check boxes to gigedit which allow to 
select for 1.) "attack" stage, 2.) "attack hold" stage and 3.) "decay" stage 
whether the respective stage should be played entirely to its end on note-off. 
That checkbox trio will be available for all 3 EGs separately (amp EG, pitch 
EG, filter EG) as individual configuration.

I guess that should be fine for everybody.

> > No, that behavior was also from the very first EG version I wrote. I think
> > back then I had a piano string in mind, which would stop being dampened as
> > soon as you press the piano key down again. And at that point I already
> > knew this behavior aspect would deviate from common EG implementations,
> > but I did not care.
> 
> Yes, you're right. This sounded familiar, so I had to search the mailing
> list archives: It seems I noticed this behavior and asked if it was a
> bug in 2004:
> https://sourceforge.net/p/linuxsampler/mailman/linuxsampler-devel/thread/14d
> f1c3e04120514066f89786d%40mail.gmail.com

Ok, then this one doesn't matter anymore. Since I have to add a file format 
extension for the attack/attack hold/decay behavior configuration, I will also 
add that one as configurable behavior extension to the gig format as well and 
leave the current behavior as default one as well.

CU
Christian

Re: [Linuxsampler-devel] EGs

[Nicola P. <nic...@gm...>]

Hi,
I noticed that years ago, but never been able to investigate it, thanks for fixed it. (I used loopmode=one_shot to partially resolve this)
While you are watching the EG behaviour, could you please check the ahdsr ramps? Weeks ago I started to write documentation for these opcodes, and I noticed two things I don't know are corrects:
1. Ampeg_decay value should be the time (in seconds) the AMPEG envelope takes to go from "hold" to "sustain", but actually is shorter.
2. Ampeg_release ramp is not linear, while attack and decay are linear.

Il 18 luglio 2017 13:46:41 CEST, Christian Schoenebeck <sch...@li...> ha scritto:
>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
>
>------------------------------------------------------------------------------
>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

-- 
Nicola

[Linuxsampler-devel] [linuxsampler-devel] QOL gigedit features?

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

Hello all,

I was thinking of a few QOL features for gigedit:

1. Multiple region selection (ctrl click for individual regions. shift
click for 'from currently selected region to target region selection)

2. Move/delete selected regions via keyboard (ctrl+delete to delete, drag
the regions around with the mouse?)

3. Shift click to select multiple instruments in the 'instruments' tab and
using 'delete' to remove them all at once. I realise you can also ctrl
click each instrument and then select 'remove' from the instrument menu, so
I guess this is a shortcut :-)

Andrew.

Re: [Linuxsampler-devel] EGs

[Andreas P. <and...@ou...>]

Christian Schoenebeck wrote:
> Correct me if I am wrong, but as far as I can see it right now, you worked on 
> the actual EG curve shapes to replicate the original shapes as accurate as 
> possible, for example that the stages are actually a combination of linear and 
> logarithmic curves in GSt, and the way the durations were calculated by GSt.
> 
> However I think that particular issue, that the attack and decay phases are 
> not played entirely to their end, like it is usually the case with EGs in 
> general, is still from the very first EG version that I wrote long time before 
> that. So I think I caused that "bug", and you probably did not compare this 
> precise behavior aspect with GSt. Am I wrong?

Yes, I think so. I remember doing measurements on how GSt reacted on
note off in the different stages of EG. I don't remember how much I
actually had to change the implementation, but at least in the comment
of my commit r783 I wrote "Release stage can now start before attack
stage ends."

>>>     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.
>>
>> I don't remember that one - it could be a simulated GigaStudio
>> weirdness, but I don't know when it would be useful.
> 
> No, that behavior was also from the very first EG version I wrote. I think 
> back then I had a piano string in mind, which would stop being dampened as 
> soon as you press the piano key down again. And at that point I already knew 
> this behavior aspect would deviate from common EG implementations, but I did 
> not care.

Yes, you're right. This sounded familiar, so I had to search the mailing
list archives: It seems I noticed this behavior and asked if it was a
bug in 2004:
https://sourceforge.net/p/linuxsampler/mailman/linuxsampler-devel/thread/14df1c3e04120514066f89786d%40mail.gmail.com

:)

/Andreas

Re: [Linuxsampler-devel] EGs

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

On Tuesday, July 18, 2017 15:02:23 Andreas Persson wrote:
> >     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.
> 
> Long time ago I put a lot of time and effort to get the behavior as it
> is now I think. My goal back then was to make the EGs behave as closely
> as possible to how the EGs of GigaStudio behaved.

Yes, I know that of course. I reviewed the current code and also the SVN 
history. Because I remember that you worked hard on that.

Correct me if I am wrong, but as far as I can see it right now, you worked on 
the actual EG curve shapes to replicate the original shapes as accurate as 
possible, for example that the stages are actually a combination of linear and 
logarithmic curves in GSt, and the way the durations were calculated by GSt.

However I think that particular issue, that the attack and decay phases are 
not played entirely to their end, like it is usually the case with EGs in 
general, is still from the very first EG version that I wrote long time before 
that. So I think I caused that "bug", and you probably did not compare this 
precise behavior aspect with GSt. Am I wrong?

> I think I have piano sounds that would behave strangely after a change
> like this: they have a very long decay (for some unknown reason) which
> is supposed to get interrupted by a note off.

Nothing changed yet. That's why I am bringing up this issue here.

On doubt, it will become a configurable behavior change. But it must be 
addressed in some way. Because otherwise it is impossible to resemble 
percussive instruments in a realistic way.

> >     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.
> 
> I don't remember that one - it could be a simulated GigaStudio
> weirdness, but I don't know when it would be useful.

No, that behavior was also from the very first EG version I wrote. I think 
back then I had a piano string in mind, which would stop being dampened as 
soon as you press the piano key down again. And at that point I already knew 
this behavior aspect would deviate from common EG implementations, but I did 
not care.

CU
Christian

Re: [Linuxsampler-devel] EGs

[Andreas P. <and...@ou...>]

Aaron Laws wrote:
> On Tue, Jul 18, 2017 at 7:46 AM, Christian Schoenebeck
> <sch...@li... <mailto: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.

Long time ago I put a lot of time and effort to get the behavior as it
is now I think. My goal back then was to make the EGs behave as closely
as possible to how the EGs of GigaStudio behaved.

I think I have piano sounds that would behave strangely after a change
like this: they have a very long decay (for some unknown reason) which
is supposed to get interrupted by a note off.

>     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.

I don't remember that one - it could be a simulated GigaStudio
weirdness, but I don't know when it would be useful.

/Andreas

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