Re: [Hydrogen-devel] some ideas about using Hydrogen with external samplers

[Thijs v. s. <thi...@gm...>]

Hi Markus !

Now that's what i call a detailed analysis :-) !!!
There are some aspects in your mail that -as you know- are know issues
(like the "*Hydrogen can't drive an external sampler via MIDI unless
samples are defined in the drum kit, even if the output of the internal
sampler is not used"*)
The other remarks you have are new to my knowledge, therefore i would
suggest that you create a bug ticket for each remark (include the info you
provided in your email).  This will make sure that your info is not lost

Thanks for your contribution !

Grtz
Thijs

2017-10-28 21:15 GMT+02:00 Markus Grabner <mg...@w4...>:

> Am Freitag, 27. Oktober 2017, 00:52:15 CEST schrieb Markus Grabner:
> > Then I compared the timing accuracy of Hydrogen's internal sampler with
> an
> > external one (LinuxSampler connected via Jack MIDI). I created an
> artificial
> > drum sample consisting of a single pulse and recorded the generated
> output
> > with Ardour such that the timing can be evaluated with frame-accuracy
> when
> > maximally zooming into the wave form view. With a sampling rate of 48kHz
> > and a tempo of 108bpm, the samples had a distance of either 26666 or
> 26667
> > frames, i.e., the error was less than a frame, which is optimal. However,
> > repeating the same experiment with LinuxSampler, the individual samples
> > were spaced either 26624 or 26880 samples from each other, which are both
> > integer multiples of 256. I choose quite conservative settings for jack
> > when recording (4 periods of 256 frames) since latency (21.3ms with these
> > settings) can easily be compensated, while a single xrun can spoil the
> > greatest take. So timing seems to be accurate only to periods, but not to
> > single frames when using an external sampler via MIDI. The error caused
> by
> > this issue is in the order of the range a note can be shifted by the
> > lead/lag feature, i.e., not immediatetly noticeable when listening
> > casually, but too large to be totally ignored in my option.
> > To verify whether this is an problem with Hydrogen or LinuxSampler, I did
> > two more experiments: using LinuxSampler as an Ardour LV2 plugin
> internally
> > connected to an Ardour MIDI track, and using LinuxSampler as an external
> > application connected to Ardour via MIDI. Both gave frame-accurate
> results.
> > So let me summarize:
> > *) Ardour + Hydrogen with its internal sampler produce frame-accurate
> output
> > *) Ardour + LinuxSampler as an LV2 plugin produce frame-accurate output
> *)
> > Ardour + LinuxSampler connected to Ardour via MIDI produce frame-accurate
> > output
> > *) Ardour + Hydrogen + LinuxSampler connected to Hydrogen via MIDI don't
> > produce frame-accurate output
> > I believe that the problem is in or near the method
> > JackMidiDriver::JackMidiRead(), though I didn't spot any obvious mistake
> > there.
> I took a closer look at this method and found something interesting. The
> variable "t" always counts from 0 to 2 and then starts again at 0. It is
> used
> as the "time" parameter of the jack_midi_event_reserve() function.
> According
> to the extensive documentation (see http://jackaudio.org/files/docs/html/
> group__MIDIAPI.html#ga150dcdc37583e1ecbe0a6f16b6ac48a9), we learn that the
> "time" parameter means the "Sample offset of event". This leaves some room
> for
> interpretation at least, but I believe it means the number of frames w.r.t.
> the start of the current period when the event should be triggered. To
> verify
> this assumption, I did another pulse experiment with Ardour+Hydrogen
> +LinuxSampler (see above), but modified the code such that 100 is added to
> the
> "time" parameter of the jack_midi_event_reserve() function. Indeed the
> distances between adjacent pulses were again integer multiples of 256, but
> the
> absolute positions in time were delayed by exactly 100 frames.
>
> So here is probably the bug: the "time" parameter should indicate the
> fraction
> of the current period at which a note is to be played (which is a different
> value for each note unless the time between two notes happens to be an
> exact
> integer multiple of the period size), but instead the "time" parameter
> periodically counts from 0 to 2. We need to somehow compute the modulo of
> the
> absolute frame number when a note starts, and the period size, and pass
> this
> number to jack_midi_event_reserve(). I will try to figure out how to do
> this
> when I'm back from vacation next Friday. Do you have any comments or ideas
> on
> this issue in the meantime?
>
>         Kind regards,
>                 Markus
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Hydrogen-devel mailing list
> Hyd...@li...
> https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
>



-- 
follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !