It means that you have to do that tricky 'sequencing' part, which consists
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 15, 2013 at 10:33 AM, M Donalies wrote:
> On Friday 15 February 2013 11:12:04 Paul Davis wrote:
Content-Type: text/html; charset=UTF-8
On Fri, Feb 15, 2013 at 10:33 AM, M Dona=
lies <email@example.com> wrote:
On Friday 15 February 2013 11:12:04 Paul Davis wrote:
> between ports.
Does that mean:
Don't even think about it unless you're a systems programmer becaus=
1000 low-level subtleties involved.
Or is it just the tedium of turning all the midi events into binary and mak=
sure all the events are in order to be processed by the target (fluidsynth =
soundcard or whatever)?
I can handle the latter, but certainly not the former. My idiot-level
algorithm is kind of like writing realtime midi to a port and looks somethi=
1) My app has a buffer of the binary midi data. Jack is running and I'v=
created a midi out port.
2) Jack let's me know what time it is through a callback.
3) To play, I record the current time as my starting time. Then write some<=
events to the port.
4) Wait for another callback and write more data.
Ok, you can stop banging your head on or desk, exclaiming "How does th=
even know how to post a message to the list!" I have the feeling this =
equivalent of the car question, "Now tell me again, why do I have to u=
icky motor oil stuff? Pouring water in the reservoir fills it just the same=
it's far less messy."
br>It means that you have to do that tricky 'sequencing' part, whic=
h consists of scheduling (MIDI) events and only placing them onto the JACK =
buffer at the appropriate instant. ALSA MIDI does this for you, as well as =
providing a nice API for generating the MIDI events. That's not the tri=
ckiest part though, the real mess begins when you want to deal with the JAC=
K Transport/Timebase API to follow or generate tempo changes.