Once upon a time I made thats two object for my live performance. But at that time midiclikin did not work well cause of jitter. And keep compatibility with MAX on Macintosh, They were voided.
I dont have Linux so it was NT only.
Sorry my strange English.
[Larry Troxler ] wrote at (09/30):- - - - - - - - - - - - - - - -
I've got a few questions about the implementation of "midiclkin" and "midirealtimein".
First, there is an error issued that "midirealtimein" doens't work under "NT". Judging from the ifdef, I think that what this error message really is trying to say is that it doesn't work on "Microsoft Windows version NT". That's well and good, but I think that, except for a couple of bugs which are OS independent, that it works ok on Linux as well. So I suspect that maybe the ifdef is wrong in this case.
Next, the midi realtime object gets hit for anything >= 0xf8, which means it grabs midi clocks as well. Usually I don't care much about efficiency and optimisation, but I wonder if this case if it would have been worth it to route MIDI clocks to a seperate object.
And indeed there is a "midiclikin" object, but it seems to be an orphan, because it is never called from the midi parser! What the heck is up with
that?Finally, why on earth, in midi_realtimein, does the pd_list call specify "1" as the list length, instead of "2"??
I guess a final issue is why these objects aren't included in the MIDI help patch, but I guess the reason is that they were experimental.
Kinda sad becase with a little debugging I think they could be made to work.
Larry
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
end of quote: - - - - - - - - - - - - - - -
Toshinori Ohkouchi ohk@d1.dion.ne.jp