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 <beachn...@web.de> 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 <beachn...@web.de> 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
> > Linuxsampler-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
------------------------------------------------------------------------------
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
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
