On Fri, 16 Aug 2002 14:14:02 -0400 Paul Davis <[EMAIL PROTECTED]> wrote:
> > >We know that the ideal way of doing this is having both the > >sequencer and the softsynth access to the same exact clock for > >reference, then having the audio app a predefined "delay in time" > >consisting of the fragment size. After that it's a simple matter of > >taking the current time before mixing a block, and mix internally > >in smaller blocks while retrieving the event. > > this is how you handle incoming MIDI data,yes. but outgoing data > is not a "simple matter" if you want to pre-queue the data and/or > have a resolution that matches the MIDI data rate. Well, outgoing is basically the same, you just send the timecode in which you want the event to be played (if future), or the actual time if you want to play it as soon as possible. Personally i think the incoming data is the harder thing to implement in code. ALSA sequencer seems to take care of rearranging the order of the events, but wont give you propert timing info/ > > > I see this as something JACK could do > >really well (take the timing before mixing a block and give it to > >the processes, so even if one has to wait for the other according > >to the graph, the sync with midi would be fine. I guess basically > >this alone may justify giving jack midi superpowers, since we know > >how important a good midi sync is. > > yes, but "MIDI sync" isn't defined. as i've explained before, there > are two kinds: > > MIDI clock: a low resolution "tick" > MIDI timecode: a low resolution positional reference Yeah, midi clock and tick, but isnt that 10 milliseconds? That's basically just 100mhz timing. I was talking about something api-specific (which can become one of the other two when going outside the lib) which can work with UST. > > different kinds of devices use one or the other these, but rarely > both. most drum machines and analog-ish sequencers use MIDI > clock. most HDR systems and other digital audio systems use MTC. > > syncing to these two things is a very different task depending on > which one you pick. MIDI clock tells you how fast you are moving, > but doesn't necessarily contain any positional information. Of > course, many systems may also generate MIDI song position data along > with MIDI clock, just to confuse matters :) > Well, basically what i mean is having the high resolution clock as api internal, that doesnt necesarily mean ignoring other midi input/output sources, but i dont think any of those really fullfill the task needed. This is basically because when managing external stuff (hardware) the devices can keep up fine with with realtime data, because there is no latency problems, thing you do have with a softsynth/soundcard. Well, personally I'd like to contribute to MIDI support for jack, i think would be great if it can handle midi, since it's already nice and consistent. How are you planning to do this? adding midi in/out ports besides the audio ones? I think if going that far, it would be nice at future, if it could also add some sort of control streams, such as start/stop/pause/set position,etc. Cheers. Juan Linietsky