linuxsampler-devel

[Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi list,

I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
found a little oddity (two, actually): I have loaded a .sfz with a couple of 
synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31) 
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64 (output
device from LinuxSampler is JACK).

Though the events are identical with regard to velocity etc, I can clearly
hear that the samples produced by LinuxSampler are varying slight every now and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.

This is the corresponding line from the .sfz mapping this kick drum:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616 pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997 ampeg_release=200.199997 pitchlfo_freq=5.000919

That original .wav file is also attached.

I grabbed a short recording via jack_capture and looked at the resulting .wav
in a wave editor; here I clearly see why the sounds really sound different
(see attached pictures: orig_wave.png is the original .wav file, "soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there any
AMP envelope applied to every sample at playback?) and "hard_wave.png" is one
of the (more rare) sample playbacks with stronger reproduction of the original
sample's attack phase.

So, there are really two questions in this:
- Why is the playback not giving constantly the same audio output? Could this
  actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each and
  every sample playback (perhaps to avoid the "onset clicks"?), how can I disable
  it to be sure my original sample's playback is authentically reproduced?

Thanks,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Alby M. <alb...@gm...>]

Hi Frank,

Is that the whole SFZ file? I can see two possible causes in that snippet,
but there could be others if the file has other sections. The snippet sets
a rate for an LFO controlling pitch; while the depth of that modulation
should be zero, it's possible that it defaults to something else and that
that processing is responsible for the differences you hear. Another
possibility is that the amplitude envelope has a non-zero attack time. That
can be fixed by adding `ampeg_attack=0`.

Are all your input notes the same velocity?

Do you get the same results using this?:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616

Best,
A.

On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <bea...@we...> wrote:


Hi list,

I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
found a little oddity (two, actually): I have loaded a .sfz with a couple of
synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31)
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
(output
device from LinuxSampler is JACK).

Though the events are identical with regard to velocity etc, I can clearly
hear that the samples produced by LinuxSampler are varying slight every now
and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick
drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.

This is the corresponding line from the .sfz mapping this kick drum:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919

That original .wav file is also attached.

I grabbed a short recording via jack_capture and looked at the resulting
.wav
in a wave editor; here I clearly see why the sounds really sound different
(see attached pictures: orig_wave.png is the original .wav file,
"soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there any
AMP envelope applied to every sample at playback?) and "hard_wave.png" is
one
of the (more rare) sample playbacks with stronger reproduction of the
original
sample's attack phase.

So, there are really two questions in this:
- Why is the playback not giving constantly the same audio output? Could
this
  actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each and
  every sample playback (perhaps to avoid the "onset clicks"?), how can I
disable
  it to be sure my original sample's playback is authentically reproduced?

Thanks,
Frank
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Alby,

thanks for your suggestions.

> Is that the whole SFZ file? I can see two possible causes in that snippet,

The file is really a bit longer, but it contains just key assignments for 17
more samples, on different keys. No LFO definitions or some such, if you were
thinking of that. I now trimmed it down to really just that one line, same
results.

> but there could be others if the file has other sections. The snippet sets
> a rate for an LFO controlling pitch; while the depth of that modulation
> should be zero, it's possible that it defaults to something else and that
> that processing is responsible for the differences you hear. Another
> possibility is that the amplitude envelope has a non-zero attack time. That
> can be fixed by adding `ampeg_attack=0`.

I tried adding ampeg_attack=0 to that line in the .sfz, no effect.

> Are all your input notes the same velocity?

Yes; I was trusting my sequencer software, but now I also checked with
aseqdump. It's constant velocity across all events, in this case 64.

> Do you get the same results using this?:
> 
> <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616

Compared to my original .sfz file entry, you are also removing the 
"pitch_keycenter" variable which of course affects the sample playback
(I assume it's now played back 3 octaves deeper), but I guess you didn't
really want me to test that. I removed all other statements from that
.sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
still no difference.

Greetings,
Frank


> On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <bea...@we...> wrote:
> 
> 
> Hi list,
> 
> I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
> found a little oddity (two, actually): I have loaded a .sfz with a couple of
> synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31)
> and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
> (output
> device from LinuxSampler is JACK).
> 
> Though the events are identical with regard to velocity etc, I can clearly
> hear that the samples produced by LinuxSampler are varying slight every now
> and
> then in their attack phase. There is roughly 1 "different" (harder, more
> direct) kick drum in every 8 or so events.
> This is NOT due to some round-robin scheme; there really is only one Kick
> drum
> .wav file assigned to this key.
> Also, I observed no JACK xruns while testing this.
> 
> This is the corresponding line from the .sfz mapping this kick drum:
> 
> <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
> pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
> ampeg_release=200.199997 pitchlfo_freq=5.000919
> 
> That original .wav file is also attached.
> 
> I grabbed a short recording via jack_capture and looked at the resulting
> .wav
> in a wave editor; here I clearly see why the sounds really sound different
> (see attached pictures: orig_wave.png is the original .wav file,
> "soft_wave.png"
> is one of the (frequent) samples with somewhat softer attack (is there any
> AMP envelope applied to every sample at playback?) and "hard_wave.png" is
> one
> of the (more rare) sample playbacks with stronger reproduction of the
> original
> sample's attack phase.
> 
> So, there are really two questions in this:
> - Why is the playback not giving constantly the same audio output? Could
> this
>   actually be a bug?
> - If there is some kind of AMP envelope automatically applied upon each and
>   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> disable
>   it to be sure my original sample's playback is authentically reproduced?
> 
> Thanks,
> Frank
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Alby M. <alb...@gm...>]

Hi Frank,

That's strange. I'm not one of the LinuxSampler devs, so I can't say if
there's an obvious cause for this in LinuxSampler itself, but those tests
certainly remove any causes I can see in the SFZ file.

Your file doesn't contain any <group>s, <master>s, or <global>s, does it?

 - A.

On Tue, Jan 10, 2017 at 11:20 AM Frank Neumann <bea...@we...> wrote:

>
> Hi Alby,
>
> thanks for your suggestions.
>
> > Is that the whole SFZ file? I can see two possible causes in that
> snippet,
>
> The file is really a bit longer, but it contains just key assignments for
> 17
> more samples, on different keys. No LFO definitions or some such, if you
> were
> thinking of that. I now trimmed it down to really just that one line, same
> results.
>
> > but there could be others if the file has other sections. The snippet
> sets
> > a rate for an LFO controlling pitch; while the depth of that modulation
> > should be zero, it's possible that it defaults to something else and that
> > that processing is responsible for the differences you hear. Another
> > possibility is that the amplitude envelope has a non-zero attack time.
> That
> > can be fixed by adding `ampeg_attack=0`.
>
> I tried adding ampeg_attack=0 to that line in the .sfz, no effect.
>
> > Are all your input notes the same velocity?
>
> Yes; I was trusting my sequencer software, but now I also checked with
> aseqdump. It's constant velocity across all events, in this case 64.
>
> > Do you get the same results using this?:
> >
> > <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> > kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
>
> Compared to my original .sfz file entry, you are also removing the
> "pitch_keycenter" variable which of course affects the sample playback
> (I assume it's now played back 3 octaves deeper), but I guess you didn't
> really want me to test that. I removed all other statements from that
> .sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
> ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
> still no difference.
>
> Greetings,
> Frank
>
>
> > On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <bea...@we...> wrote:
> >
> >
> > Hi list,
> >
> > I was experimenting a bit with Linuxsampler and sequencer64 yesterday,
> and
> > found a little oddity (two, actually): I have loaded a .sfz with a
> couple of
> > synthetic drum samples into LinuxSampler (version LinuxSampler
> 2.0.0.svn31)
> > and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
> > (output
> > device from LinuxSampler is JACK).
> >
> > Though the events are identical with regard to velocity etc, I can
> clearly
> > hear that the samples produced by LinuxSampler are varying slight every
> now
> > and
> > then in their attack phase. There is roughly 1 "different" (harder, more
> > direct) kick drum in every 8 or so events.
> > This is NOT due to some round-robin scheme; there really is only one Kick
> > drum
> > .wav file assigned to this key.
> > Also, I observed no JACK xruns while testing this.
> >
> > This is the corresponding line from the .sfz mapping this kick drum:
> >
> > <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> > kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
> > pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
> > ampeg_release=200.199997 pitchlfo_freq=5.000919
> >
> > That original .wav file is also attached.
> >
> > I grabbed a short recording via jack_capture and looked at the resulting
> > .wav
> > in a wave editor; here I clearly see why the sounds really sound
> different
> > (see attached pictures: orig_wave.png is the original .wav file,
> > "soft_wave.png"
> > is one of the (frequent) samples with somewhat softer attack (is there
> any
> > AMP envelope applied to every sample at playback?) and "hard_wave.png" is
> > one
> > of the (more rare) sample playbacks with stronger reproduction of the
> > original
> > sample's attack phase.
> >
> > So, there are really two questions in this:
> > - Why is the playback not giving constantly the same audio output? Could
> > this
> >   actually be a bug?
> > - If there is some kind of AMP envelope automatically applied upon each
> and
> >   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> > disable
> >   it to be sure my original sample's playback is authentically
> reproduced?
> >
> > Thanks,
> > Frank
> >
> ------------------------------------------------------------------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Alby and all,

> That's strange. I'm not one of the LinuxSampler devs, so I can't say if
> there's an obvious cause for this in LinuxSampler itself, but those tests
> certainly remove any causes I can see in the SFZ file.
> 
> Your file doesn't contain any <group>s, <master>s, or <global>s, does it?

No, it's really just straight mappings.

What I am interested in - has anyone been able to reproduce this?

That is: Create a one-liner .sfz from the line I stated below, correct the
path to the .wav I had attached to an earlier mail of this thread, start up
Linuxsampler and arm a track with this .sfz, feed a constant (looped)
sequence of, say, quarter notes to it (10 beats should be enough), record
the audio output with e.g. jack_capture and inspect the .wav file in a wave
editor. The difference in the onset of the notes should become apparent pretty
soon as you zoom into the individual beats.

I want to make sure it's not me doing something stupid here - that has
happened before :-).

Thanks,
Frank


> 
> On Tue, Jan 10, 2017 at 11:20 AM Frank Neumann <bea...@we...> wrote:
> 
> >
> > Hi Alby,
> >
> > thanks for your suggestions.
> >
> > > Is that the whole SFZ file? I can see two possible causes in that
> > snippet,
> >
> > The file is really a bit longer, but it contains just key assignments for
> > 17
> > more samples, on different keys. No LFO definitions or some such, if you
> > were
> > thinking of that. I now trimmed it down to really just that one line, same
> > results.
> >
> > > but there could be others if the file has other sections. The snippet
> > sets
> > > a rate for an LFO controlling pitch; while the depth of that modulation
> > > should be zero, it's possible that it defaults to something else and that
> > > that processing is responsible for the differences you hear. Another
> > > possibility is that the amplitude envelope has a non-zero attack time.
> > That
> > > can be fixed by adding `ampeg_attack=0`.
> >
> > I tried adding ampeg_attack=0 to that line in the .sfz, no effect.
> >
> > > Are all your input notes the same velocity?
> >
> > Yes; I was trusting my sequencer software, but now I also checked with
> > aseqdump. It's constant velocity across all events, in this case 64.
> >
> > > Do you get the same results using this?:
> > >
> > > <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> > > kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
> >
> > Compared to my original .sfz file entry, you are also removing the
> > "pitch_keycenter" variable which of course affects the sample playback
> > (I assume it's now played back 3 octaves deeper), but I guess you didn't
> > really want me to test that. I removed all other statements from that
> > .sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
> > ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
> > still no difference.
> >
> > Greetings,
> > Frank
> >
> >
> > > On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <bea...@we...> wrote:
> > >
> > >
> > > Hi list,
> > >
> > > I was experimenting a bit with Linuxsampler and sequencer64 yesterday,
> > and
> > > found a little oddity (two, actually): I have loaded a .sfz with a
> > couple of
> > > synthetic drum samples into LinuxSampler (version LinuxSampler
> > 2.0.0.svn31)
> > > and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
> > > (output
> > > device from LinuxSampler is JACK).
> > >
> > > Though the events are identical with regard to velocity etc, I can
> > clearly
> > > hear that the samples produced by LinuxSampler are varying slight every
> > now
> > > and
> > > then in their attack phase. There is roughly 1 "different" (harder, more
> > > direct) kick drum in every 8 or so events.
> > > This is NOT due to some round-robin scheme; there really is only one Kick
> > > drum
> > > .wav file assigned to this key.
> > > Also, I observed no JACK xruns while testing this.
> > >
> > > This is the corresponding line from the .sfz mapping this kick drum:
> > >
> > > <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> > > kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
> > > pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
> > > ampeg_release=200.199997 pitchlfo_freq=5.000919
> > >
> > > That original .wav file is also attached.
> > >
> > > I grabbed a short recording via jack_capture and looked at the resulting
> > > .wav
> > > in a wave editor; here I clearly see why the sounds really sound
> > different
> > > (see attached pictures: orig_wave.png is the original .wav file,
> > > "soft_wave.png"
> > > is one of the (frequent) samples with somewhat softer attack (is there
> > any
> > > AMP envelope applied to every sample at playback?) and "hard_wave.png" is
> > > one
> > > of the (more rare) sample playbacks with stronger reproduction of the
> > > original
> > > sample's attack phase.
> > >
> > > So, there are really two questions in this:
> > > - Why is the playback not giving constantly the same audio output? Could
> > > this
> > >   actually be a bug?
> > > - If there is some kind of AMP envelope automatically applied upon each
> > and
> > >   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> > > disable
> > >   it to be sure my original sample's playback is authentically
> > reproduced?
> > >
> > > Thanks,
> > > Frank
> > >
> > ------------------------------------------------------------------------------
> > > Developer Access Program for Intel Xeon Phi Processors
> > > Access to Intel Xeon Phi processor-based developer platforms.
> > > With one year of Intel Parallel Studio XE.
> > > Training and support from Colfax.
> > > Order your platform today. http://sdm.link/xeonphi
> > > _______________________________________________
> > > Linuxsampler-devel mailing list
> > > Lin...@li...
> > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> >

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Monday, January 09, 2017 23:32:01 Frank Neumann wrote:
> So, there are really two questions in this:
> - Why is the playback not giving constantly the same audio output? Could
> this actually be a bug?

Yes, it seems to be a bug in the SFZ engine.

> - If there is some kind of AMP envelope automatically applied upon each and
>   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> disable it to be sure my original sample's playback is authentically
> reproduced?

It needs to be debugged, for example by commenting out various synthesis 
components to narrow down the source of this issue.

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Christian,

> > - Why is the playback not giving constantly the same audio output? Could
> > this actually be a bug?
> 
> Yes, it seems to be a bug in the SFZ engine.
> 
> > - If there is some kind of AMP envelope automatically applied upon each and
> >   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> > disable it to be sure my original sample's playback is authentically
> > reproduced?
> 
> It needs to be debugged, for example by commenting out various synthesis 
> components to narrow down the source of this issue.

You can use me as your guinea pig - just give me a hint how and where I can
comment/disable	them.

Thanks,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Alby M. <alb...@gm...>]

Hi all,

I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler 2.0.0
(built from source). Using the attached SFZ file I get no audible or
visible differences. I've attached an image of three hits from the
recording.

Frank, could you be using a different version of LinuxSampler?

 - A

On Wed, Jan 11, 2017 at 11:46 AM Frank Neumann <bea...@we...> wrote:

>
> Hi Christian,
>
> > > - Why is the playback not giving constantly the same audio output?
> Could
> > > this actually be a bug?
> >
> > Yes, it seems to be a bug in the SFZ engine.
> >
> > > - If there is some kind of AMP envelope automatically applied upon
> each and
> > >   every sample playback (perhaps to avoid the "onset clicks"?), how
> can I
> > > disable it to be sure my original sample's playback is authentically
> > > reproduced?
> >
> > It needs to be debugged, for example by commenting out various synthesis
> > components to narrow down the source of this issue.
>
> You can use me as your guinea pig - just give me a hint how and where I can
> comment/disable them.
>
> Thanks,
> Frank
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Alby,

> I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler 2.0.0
> (built from source). Using the attached SFZ file I get no audible or
> visible differences. I've attached an image of three hits from the
> recording.

Hm..interesting. Could you zoom in onto the onset (roughly the first 50ms) of
each beat? The "big picture" doesn't really show the effect I am seeing, you
have to look a lot closer.

> Frank, could you be using a different version of LinuxSampler?

Mine says 2.0.0.svn31; I don't know how to retrieve the Subversion version
from the binary, though.

Greetings,
Frank


> On Wed, Jan 11, 2017 at 11:46 AM Frank Neumann <bea...@we...> wrote:
> 
> >
> > Hi Christian,
> >
> > > > - Why is the playback not giving constantly the same audio output?
> > Could
> > > > this actually be a bug?
> > >
> > > Yes, it seems to be a bug in the SFZ engine.
> > >
> > > > - If there is some kind of AMP envelope automatically applied upon
> > each and
> > > >   every sample playback (perhaps to avoid the "onset clicks"?), how
> > can I
> > > > disable it to be sure my original sample's playback is authentically
> > > > reproduced?
> > >
> > > It needs to be debugged, for example by commenting out various synthesis
> > > components to narrow down the source of this issue.
> >
> > You can use me as your guinea pig - just give me a hint how and where I can
> > comment/disable them.
> >
> > Thanks,
> > Frank
> >
> >
> > ------------------------------------------------------------------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> >

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Alby M. <alb...@gm...>]

Hi Frank,

I've attached zoomed-in images of the transients of the first and fifth
hits. I still don't see any difference.

 - A

On Wed, Jan 11, 2017 at 12:49 PM Frank Neumann <bea...@we...> wrote:

>
> Hi Alby,
>
> > I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler
> 2.0.0
> > (built from source). Using the attached SFZ file I get no audible or
> > visible differences. I've attached an image of three hits from the
> > recording.
>
> Hm..interesting. Could you zoom in onto the onset (roughly the first 50ms)
> of
> each beat? The "big picture" doesn't really show the effect I am seeing,
> you
> have to look a lot closer.
>
> > Frank, could you be using a different version of LinuxSampler?
>
> Mine says 2.0.0.svn31; I don't know how to retrieve the Subversion version
> from the binary, though.
>
> Greetings,
> Frank
>
>
> > On Wed, Jan 11, 2017 at 11:46 AM Frank Neumann <bea...@we...> wrote:
> >
> > >
> > > Hi Christian,
> > >
> > > > > - Why is the playback not giving constantly the same audio output?
> > > Could
> > > > > this actually be a bug?
> > > >
> > > > Yes, it seems to be a bug in the SFZ engine.
> > > >
> > > > > - If there is some kind of AMP envelope automatically applied upon
> > > each and
> > > > >   every sample playback (perhaps to avoid the "onset clicks"?), how
> > > can I
> > > > > disable it to be sure my original sample's playback is
> authentically
> > > > > reproduced?
> > > >
> > > > It needs to be debugged, for example by commenting out various
> synthesis
> > > > components to narrow down the source of this issue.
> > >
> > > You can use me as your guinea pig - just give me a hint how and where
> I can
> > > comment/disable them.
> > >
> > > Thanks,
> > > Frank
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Developer Access Program for Intel Xeon Phi Processors
> > > Access to Intel Xeon Phi processor-based developer platforms.
> > > With one year of Intel Parallel Studio XE.
> > > Training and support from Colfax.
> > > Order your platform today. http://sdm.link/xeonphi
> > > _______________________________________________
> > > Linuxsampler-devel mailing list
> > > Lin...@li...
> > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> > >
>

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Wednesday, January 11, 2017 19:42:56 Frank Neumann wrote:
> > It needs to be debugged, for example by commenting out various synthesis
> > components to narrow down the source of this issue.
> 
> You can use me as your guinea pig - just give me a hint how and where I can
> comment/disable	them.

First of all, I would force a constant velocity value being used by the 
sampler, as provided by the attached hack. That way you can forget about all 
MIDI input issues for now and just concentrate on the actual bug.

Then your playground will be src/engines/common/AbstractVoice.cpp. You find a 
method there called AbstractVoice::Synthesize(). That's actually the heart of 
it all. Disable synthesis components there (i.e. EQ, EGs, filter, etc.) until 
the issue disappears.

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Wednesday, January 11, 2017 20:59:10 Christian Schoenebeck wrote:
> On Wednesday, January 11, 2017 19:42:56 Frank Neumann wrote:
> > > It needs to be debugged, for example by commenting out various synthesis
> > > components to narrow down the source of this issue.
> > 
> > You can use me as your guinea pig - just give me a hint how and where I
> > can
> > comment/disable	them.
> 
> First of all, I would force a constant velocity value being used by the
> sampler, as provided by the attached hack. That way you can forget about all
> MIDI input issues for now and just concentrate on the actual bug.
> 
> Then your playground will be src/engines/common/AbstractVoice.cpp. You find
> a method there called AbstractVoice::Synthesize(). That's actually the
> heart of it all. Disable synthesis components there (i.e. EQ, EGs, filter,
> etc.) until the issue disappears.

Any finding in the meantime Frank?

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Christian and all,

> > > > It needs to be debugged, for example by commenting out various synthesis
> > > > components to narrow down the source of this issue.
> > > 
> > > You can use me as your guinea pig - just give me a hint how and where I
> > > can
> > > comment/disable	them.
> > 
> > First of all, I would force a constant velocity value being used by the
> > sampler, as provided by the attached hack. That way you can forget about all
> > MIDI input issues for now and just concentrate on the actual bug.
> > 
> > Then your playground will be src/engines/common/AbstractVoice.cpp. You find
> > a method there called AbstractVoice::Synthesize(). That's actually the
> > heart of it all. Disable synthesis components there (i.e. EQ, EGs, filter,
> > etc.) until the issue disappears.
> 
> Any finding in the meantime Frank?

Hm...not a lot so far. Let me list:
- I hard-coded the velocity as per your suggestion, but that didn't change anything.
  I believe I can trust my sequencer software to produce stable velocity output :-).

- I disabled a couple of things in AbstraceVoice.cpp as you suggested (I have
  attached a diff against the current version of that file). Again, no change
  yet, this issue still appears.

- I noticed that - when comparing original sample playback against Linuxsampler's
  output - that LinuxSampler "gets it wrong most of the time" and only a minority
  of the events are playing back the sample correctly.
  The original sample has a pretty hard "click" at the beginning (I attached
  again a very close-up view of the first 50 or so frames of that sample as seen
  in Audacity, file "original_sample.png"), and it's this click I wanted to hear 
  reproduced by LinuxSampler. Most of the sounds it produces are a lot softer, 
  though, but I believe I stated that before.

- The only other interesting observation from today was to see what happens if
  I change the jackd buffer size. My standard buffer size here is 128 frames,
  and with that there is roughly one correctly played sample in about 10
  events.
  If I increase the buffer size to 1024 frames, the issue is a lot more rare -
  I have to wait up to a minute to hear one correctly played sample.
  One the other side, reducing the buffer size to 64 frames creates more correct
  playbacks - roughly 1 out of 4.
  Not sure if this brings us closer to the root cause, but still interesting.

- To make sure I am not fooled by some issue with my sound card (M-Audio
  Audiophile 2496), I set up playback of the same file with qtractor and 
  Rui's "drumkv1" LV2 plugin. That one delivers stable "correct" audio data,
  so the problem really appear to stem from LinuxSampler itself.

I'll continue fooling around with AbstraceVoice.cpp :-).

Greetings,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Friday, January 20, 2017 00:27:08 Frank Neumann wrote:
> - The only other interesting observation from today was to see what happens
> if I change the jackd buffer size. My standard buffer size here is 128
> frames, and with that there is roughly one correctly played sample in about
> 10 events.
>   If I increase the buffer size to 1024 frames, the issue is a lot more rare
> - I have to wait up to a minute to hear one correctly played sample. One
> the other side, reducing the buffer size to 64 frames creates more correct
> playbacks - roughly 1 out of 4.
>   Not sure if this brings us closer to the root cause, but still
> interesting.

Good to know.

> - To make sure I am not fooled by some issue with my sound card (M-Audio
>   Audiophile 2496), I set up playback of the same file with qtractor and
>   Rui's "drumkv1" LV2 plugin. That one delivers stable "correct" audio data,
> so the problem really appear to stem from LinuxSampler itself.

No doubt about that. As I said before, it seems to be a bug on LS side.

Since Alby M. said he was unable to reproduce that issue with the official 
tarball release LS 2.0.0, maybe you give that version a short try, just to see 
if that bug had been accidentally introduced in the meantime:

	svn update -r2789

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Christian,

> > - To make sure I am not fooled by some issue with my sound card (M-Audio
> >   Audiophile 2496), I set up playback of the same file with qtractor and
> >   Rui's "drumkv1" LV2 plugin. That one delivers stable "correct" audio data,
> > so the problem really appear to stem from LinuxSampler itself.
> 
> No doubt about that. As I said before, it seems to be a bug on LS side.
> 
> Since Alby M. said he was unable to reproduce that issue with the official 
> tarball release LS 2.0.0, maybe you give that version a short try, just to see 
> if that bug had been accidentally introduced in the meantime:
> 
> 	svn update -r2789

I tried that revision, but the issue appears with that one as well for me (original
source code, none of my changes applied).

"I'll be back" when I have news :-).

Greetings,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Saturday, January 21, 2017 10:08:23 Frank Neumann wrote:
> I tried that revision, but the issue appears with that one as well for me
> (original source code, none of my changes applied).

Ok, so the bug existed already before the last tarball release.

> "I'll be back" when I have news :-).

I probably have some suspicion. Which audio driver are you using? JACK? ALSA? 
CoreAudio?

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Christian,

> On Saturday, January 21, 2017 10:08:23 Frank Neumann wrote:
> > I tried that revision, but the issue appears with that one as well for me
> > (original source code, none of my changes applied).
> 
> Ok, so the bug existed already before the last tarball release.
> 
> > "I'll be back" when I have news :-).
> 
> I probably have some suspicion. Which audio driver are you using? JACK? ALSA? 
> CoreAudio?

I have conducted all tests so far with the JACK driver; I tested just now with
the ALSA audio driver, but the problem is the same.

I'll next see if an older laptop I have here (running a 32bit LinuxMint
distribution) also shows the issue - maybe I have a 64bit problem.

Greetimgs,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi again,

> > Ok, so the bug existed already before the last tarball release.
> > 
> > > "I'll be back" when I have news :-).
> > 
> > I probably have some suspicion. Which audio driver are you using? JACK? ALSA? 
> > CoreAudio?
> 
> I have conducted all tests so far with the JACK driver; I tested just now with
> the ALSA audio driver, but the problem is the same.
> 
> I'll next see if an older laptop I have here (running a 32bit LinuxMint
> distribution) also shows the issue - maybe I have a 64bit problem.

That test again showed no difference from the behaviour on a 64-Bit LinuxMint
system (my regular desktop PC).

However - finally *some* good news for the weekend :-). When I disable the
whole CONFIG_INTERPOLATE_VOLUME block in AbstractVoice.cpp (I simply replaced
line 231,

#ifdef CONFIG_INTERPOLATE_VOLUME

with 

#if 0
)

THEN, the issue is gone and the kick sound comes through correctly each time
(listened for some 2 minutes now).

Furthermore, if I reduce the "if(pSignalUnitRack...)" code in there a little,
the issue also remains gone:

242c242,244
<                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
---
>                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
> //                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
> 
244c246,248
<                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
---
>                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
> //                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
> 

So then, it's somewhere in the pEG1 or pSignalUnitRack handling. A small step ahead :-).

Greetings,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi once more,

> However - finally *some* good news for the weekend :-). When I disable the
> whole CONFIG_INTERPOLATE_VOLUME block in AbstractVoice.cpp (I simply replaced
> line 231,
> 
> #ifdef CONFIG_INTERPOLATE_VOLUME
> 
> with 
> 
> #if 0
> )
> 
> THEN, the issue is gone and the kick sound comes through correctly each time
> (listened for some 2 minutes now).
> 
> Furthermore, if I reduce the "if(pSignalUnitRack...)" code in there a little,
> the issue also remains gone:
> 
> 242c242,244
> <                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
> ---
> >                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
> > //                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
> > 
> 244c246,248
> <                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
> ---
> >                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
> > //                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
> > 
> 
> So then, it's somewhere in the pEG1 or pSignalUnitRack handling. A small step ahead :-).

Just summarizing, for clarity sake: With these 2 changes applied, the issue
is gone (of course this is not a fix yet):

--- src/engines/common/AbstractVoice.cpp.orig   2017-01-15 13:08:46.174155350 +0100
+++ src/engines/common/AbstractVoice.cpp        2017-01-23 00:31:28.283565968 +0100
@@ -241,7 +241,8 @@
             if (pSignalUnitRack == NULL) {
                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
             } else {
-                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
+                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
+//                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
             }
 
             finalSynthesisParameters.fFinalVolumeLeft  = finalVolume * VolumeLeft  * PanLeftSmoother.render();
@@ -526,9 +527,9 @@
                 }*/
                 // TODO: ^^^
 
-                fFinalVolume   *= pSignalUnitRack->GetEndpointUnit()->GetVolume();
-                fFinalCutoff    = pSignalUnitRack->GetEndpointUnit()->CalculateFilterCutoff(fFinalCutoff);
-                fFinalResonance = pSignalUnitRack->GetEndpointUnit()->CalculateResonance(fFinalResonance);
+//                fFinalVolume   *= pSignalUnitRack->GetEndpointUnit()->GetVolume();
+//                fFinalCutoff    = pSignalUnitRack->GetEndpointUnit()->CalculateFilterCutoff(fFinalCutoff);
+//                fFinalResonance = pSignalUnitRack->GetEndpointUnit()->CalculateResonance(fFinalResonance);
                 
                 finalSynthesisParameters.fFinalPitch =
                     pSignalUnitRack->GetEndpointUnit()->CalculatePitch(finalSynthesisParameters.fFinalPitch);

Greetings,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Monday, January 23, 2017 00:32:40 Frank Neumann wrote:
> Just summarizing, for clarity sake: With these 2 changes applied, the issue
> is gone (of course this is not a fix yet):

@Grigor, @Andreas: are you still around on this list? Maybe you can comment as 
well, because I am not very familiar with the SignalUnitRack stuff of the SFZ 
engine.

I had a look at this issue described by Frank. It is a bug in the 
SignalUnitRack handling. In very short, the following would fix the issue 
Frank encountered with his SFZ file:


Index: src/engines/common/SignalUnit.cpp
===================================================================
--- src/engines/common/SignalUnit.cpp	(revision 3099)
+++ src/engines/common/SignalUnit.cpp	(working copy)
@@ -25,6 +25,6 @@
 
 namespace LinuxSampler {
     bool SignalUnit::DelayStage() {
-        return (DelayTrigger() >= pRack->GetCurrentStep());
+        return (DelayTrigger() > pRack->GetCurrentStep());
     }
 } // namespace LinuxSampler


But, and there is a big "but", that short patch would just cure the symptom in 
Frank's particular case, as far as I can see it, the bug would still be 
triggered in other scenarios (more complex SFZ files) though. So here is a 
more detailed description about this issue:

The SFZ engine is calling:

	pSignalUnitRack->GetEndpointUnit()->GetVolume()

inside of method AbstractVoice::Synthesize() to get the current volume factor 
to be applied for the voice in the current audio (sub)fragment. Since Frank's 
sfz file is very simple (no volume modulators), that GetVolume() call would 
always return 1.0f (neutral volume factor), except of one case: at the very 
beginning of the life time of each voice (that is when pVoice->Pos == 0.0) 
that GetVolume() call returns 0.0f instead. And that is wrong.

GetVolume() does return 0.0f at the very beginning of a voice's life time, 
because EndPointUnit::GetVolume() calls
suVolEG.GetLevel() [SfzSignalUnitRack.cpp, line 617], which is implemented 
like this [SfzSignalUnitRack.h, line 165]:

	virtual float GetLevel() { return DelayStage() ? 0 : EG.getLevel(); }

Now in Frank's case, it is simply a bug to assume that it would be in a delay 
stage at the beginning of the voice's life time and the short patch above 
would fix it. But apart from Frank's case, simply returning 0 here looks odd 
to me.

As I said, I am not familiar with the SignalUnitRack code base, but 
intuitively I would rather expect the GetLevel() implementation either

a) to always return EG.getLevel() (even in delay stage) or

b) to return an "identity element" in delay stage instead, which depends on 
whether that result is going to be used in a mathematical add operation (in 
which case the identity element is 0) or rather in a mathematical multiply 
operation (in which case the identity element is 1).

Thoughts? Am I missing something?

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Monday, January 23, 2017 17:04:34 Christian Schoenebeck wrote:
> Index: src/engines/common/SignalUnit.cpp
> ===================================================================
> --- src/engines/common/SignalUnit.cpp	(revision 3099)
> +++ src/engines/common/SignalUnit.cpp	(working copy)
> @@ -25,6 +25,6 @@
> 
>  namespace LinuxSampler {
>      bool SignalUnit::DelayStage() {
> -        return (DelayTrigger() >= pRack->GetCurrentStep());
> +        return (DelayTrigger() > pRack->GetCurrentStep());
>      }
>  } // namespace LinuxSampler

Frank, I just committed this little patch to SVN which should fix this issue 
for you.

I got no response from Grigor or Andreas about this issue, so I will probably 
address the other potential cases (where this misbehavior might occur as well) 
of the SFZ format in some way in the next couple days. Requires a bunch of 
changes in the SFZ engine.

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Christian and all,

> On Monday, January 23, 2017 17:04:34 Christian Schoenebeck wrote:
> > Index: src/engines/common/SignalUnit.cpp
> > ===================================================================
> > --- src/engines/common/SignalUnit.cpp	(revision 3099)
> > +++ src/engines/common/SignalUnit.cpp	(working copy)
> > @@ -25,6 +25,6 @@
> > 
> >  namespace LinuxSampler {
> >      bool SignalUnit::DelayStage() {
> > -        return (DelayTrigger() >= pRack->GetCurrentStep());
> > +        return (DelayTrigger() > pRack->GetCurrentStep());
> >      }
> >  } // namespace LinuxSampler
> 
> Frank, I just committed this little patch to SVN which should fix this issue 
> for you.

Confirmed! Tried it just now, clean playback of that kick drum sample for
several minutes now. I'm happy, thank you so much! :-)

> I got no response from Grigor or Andreas about this issue, so I will probably 
> address the other potential cases (where this misbehavior might occur as well) 
> of the SFZ format in some way in the next couple days. Requires a bunch of 
> changes in the SFZ engine.

Thanks, very much appreciated. I have not noticed any other places with
similar issues, but then again my test scenario (including the .sfz files
themselves) was very limited and simple until now.

Greetings,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Sunday, February 05, 2017 11:29:04 Frank Neumann wrote:
> > Frank, I just committed this little patch to SVN which should fix this
> > issue for you.
> 
> Confirmed! Tried it just now, clean playback of that kick drum sample for
> several minutes now. I'm happy, thank you so much! :-)

No problem!

> > I got no response from Grigor or Andreas about this issue, so I will
> > probably address the other potential cases (where this misbehavior might
> > occur as well) of the SFZ format in some way in the next couple days.
> > Requires a bunch of changes in the SFZ engine.
> 
> Thanks, very much appreciated. I have not noticed any other places with
> similar issues, but then again my test scenario (including the .sfz files
> themselves) was very limited and simple until now.

Right, it works for you now because your sfz files seem to be very simple. The 
other cases where one can still encounter this issue, occur when defining some 
modulators in the sfz file which shall become active with a delay after a 
certain amount of time. But I'm on those issues as well, so they should be 
fixed soon.

CU
Christian