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