On 23.07.2002 at 15:35:58, Paul Davis <[EMAIL PROTECTED]> wrote:
> >On Tue, Jul 23, 2002 at 07:48:45 -0400, Paul Davis wrote:
> >> the question is, however, to what extent is it worth it. the reason
> >> JACK exists is because there was nothing like it available for moving
> >> audio data around. this isn\'t true of the MIDI side of things, where
> >
> >If you actaully want to deal with raw MIDI (you\'d be mad, but...) then its
> >OK, as the maximum ammount of data per jack unit time is pretty small, but
> >I agree, it\'s better dealt with via the alsa api.
>
> well, what i was thinking was something more like this:
>
> struct jack_midi_buffer_t {
> unsigned int event_cnt;
> WhateverTheALSASequencerEventTypeIsCalled events[0];
> };
>
> a JACK client that handles MIDI as well would do something like this
> in its process() callback:
>
> jack_midi_buffer_t* buf = (jack_midi_buffer_t*)
> jack_port_get_buffer (midi_in_port, nframes);
>
> for (n = 0; n < buf->event_cnt; ++n) {
> process_midi_event (buf->events[n]);
> }
>
> a real client would probably look at the timestamps in the events too.
Does that mean that MIDI output can only be done from a callback? Is the
callback the same one as for the audio hardware? MIDI being sporadic just
doesn\'t seem to fit in JACK. Why not have a seperate API/daemon for MIDI and
have it and JACK both use the same UST timestamps?
--martijn
Powered by ASHosting
