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
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
I don't know about the other issues you raised, but I remember Daniel Heckenberg's patches were really helpful to me. They fix some NT problems with midi sync. (this was back in Pd .36, are these changes made in .37 as well?)
see: http://old.iem.at/mailinglists/pd-list/2003-04/003427.html
--eric
Toshinori Ohkouchi wrote:
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
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
------ http://USFamily.Net/info - Unlimited Internet - From $8.99/mo! ------
On Wednesday 01 October 2003 22:08, Toshinori Ohkouchi wrote:
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.
Ahh. I understand then that you put in the error message only because Windows NT was the only OS you were able to test on?
Well, with the one fix I mentioned, midirealtimein works just fine on Linux,
If you don't mind, I have some questions:
You were doing some kind of timing stuff in the midi clock object code. What was that for? Also, do you think that we should put that object back in action? And if so, do you think we should stop sending the clock to the midi realtime object, if the seperate MIDI clock object is working?
Your English is very understandable and probably more carefull than mine!
Larry
NT was the only OS you were able to test on?
yes.
Well, with the one fix I mentioned, midirealtimein works just fine on Linux,
If you don't mind, I have some questions:
You were doing some kind of timing stuff in the midi clock object code. What was that for? Also, do you think that we should put that object back in action? And if so, do you think we should stop sending the clock to the midi realtime object, if the seperate MIDI clock object is working?
Usualy we should receive MIDI CLOCK(0xF8) at [midirealtimin] but when we need 0xF8, we will need critical timing. so I thought it is more better separate 0xF8 and other [MIDI realtime message] at source code level than at pd patch level. midi Sequence START and STOP does not need critical timing. and few years ago PC spec was still poor.
I made them and I offer it to Mr.Miller at that time. But keep to compatibility with MAX , It did not implement. I think we need to consult it with Mr.Miller
Toshinori Ohkouchi ohk@d1.dion.ne.jp
-
e skogen -
Larry Troxler -
ohk＠d1.dion.ne.jp