5 Oct
2010
5 Oct
'10
2:47 p.m.
On 05/10/10 20:55, fons(a)kokkinizita.net wrote:
On Tue, Oct 05, 2010 at 09:51:35AM +0200, Arnout
Engelen wrote:
Yes, but it provides a simple way to improve an existing
application using Jack-midi, withour requiring very deep
changes to the audio code to make it fully 'sample accurate'.
You will probably already have something like:
jack_process (nframes)
{
read_jack_midi_data(); // read full buffer, create new notes,
// mark those being released.
... improving the way it currently handles the create new + mark
released processing is what's needed, and from where I sit it's a
fairly daunting task. I'll probably have a go at it, ... but I'm not
a young man :-(.
What
seemed most promising was to break the audio generation into smaller
blocks, applying pending midi events between blocks.
[ But, but ... ] synthesize(nframes); // audio processing for
current notes
}
[ ... ]
This is how I added Jack-midi support to Aeolus. It
has an internal
'period' of 64 frames which really can't be changed without rewriting
all of it. Reading the midi data in slices of 64 frames and alternating
this with the synthesis code provides a jitter of +/- 32 frames, which
is probably OK (at least it is for an organ).
All up, serious food for thought and very much appreciated!
Thank you!
Cal