• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CoreMIDI question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreMIDI question


  • Subject: Re: CoreMIDI question
  • From: Doug Wyatt <email@hidden>
  • Date: Tue, 30 Apr 2002 15:50:51 -0700

On Monday, April 29, 2002, at 07:30 , Kurt Revis wrote:

On Monday, April 29, 2002, at 06:29 PM, Doug Wyatt wrote:

Well, virtual sources behave exactly like driver-owned sources from the perspective of MIDIReceived's implementation, which means that packets get passed on to the client immediately, and it's the client's job to interpret the timestamps correctly.

Right, that's how I understood it. The problems with the current setup are:

1) It's difficult for the application with the virtual source to send its events (via MIDIReceived()) right on time, due to the usual preemptive scheduling issues (although using a time-constraint thread may help a lot).
CoreMIDI already has a very good scheduler to do this, and it seems a shame to have to reimplement it.

True

2) Generally, clients haven't had to do much interpretation of timestamps of input events. They can assume that when an event comes in, it has already happened, and the timestamp indicates when it happened (or as close to that as possible given hardware limitations).
(It sounds like this will change in Jaguar for virtual destinations, for apps which set a schedule-ahead property on the virtual destination, but that's OK since the app will then be expecting to get events with timestamps in the future.)
However, it seems unrealistic to me to expect *all* client apps to look at the timestamps of input events, notice the ones which are in the future, and stick the future events in a queue to be handled later.

It's becoming more clear to me now ...

It would be bad to defer delivery of packets with future timestamps and assume that the client won't care to receive them until the timestamped time.

Can you explain more why this would be bad? That sounds exactly like what the CoreMIDI scheduler does for outgoing events sent by MIDISend(). (Taking into account any schedule-ahead amounts, of course.)

Actually, you're absolutely right ... a hardware source's timestamps are by definition supposed to always be in the past. And thus it's reasonable that a virtual source's timestamps could be supposed to always be in the past.

And destinations are opposite, timestamps only matter for events which are in the future.

If you could please give an example of how you'd like to use this, it would help me think about how to address the issue.

Basically, it comes down to a UI issue. Let's say I have an app which generates a MIDI clock, for the use of other applications. There are two possibilities for hooking together the two apps.

1) The Clock app just runs by itself, with no UI for setting where the clock events go. Other apps can select it as a source, as desired.

2) The Clock app provides a list of destinations to send the clock to. No UI is required in the other apps.

Obviously in case 1 the Clock app is using a virtual source, and in case 2 it's using the usual output port / MIDISend setup.

The problem I have, right now, is that I am not really sure which of these UIs is preferred. (I could imagine either case being better, depending on the exact application.) Apple hasn't really given any guidance in this regard yet, as far as I know.

1 is better because it doesn't require apps to create virtual destinations to be able to talk with your virtual source -- it just shows up among the hardware sources.

So in the lack of any prevailing direction, I'd like to make my app (or at least its underlying architecture) as flexible as possible. However, because the lack of scheduling makes it harder to implement a virtual source, this boils up to the UI level, and it seems that case 2 is preferred. Is this the message I should be getting, reading between the lines?

No, au contraire ...

Philisophically it would be nice to have a symmetrical system, in which it was just as easy to implement a virtual source as a virtual destination. I am still not sure if you guys are making the system asymmetrical intentionally, or if it's just falling out that way because of other design decisions. I can live with it either way--I'm sure you have good reasons for how you implement it-- but it would really be helpful if you could explicitly say one way or the other.

You've just pointed out that the system is missing some symmetry -- the scheduler is currently hardwired to deal only with the direction of output to destinations, but what you've raised here illustrates that it needs to be symmetrical and handle input from virtual sources (it'll only end up pushing events through the scheduler when the timestamps are in the future). It shouldn't be too hard, because in the internal implementation, sources and destinations are subclasses of MIDIEndpoint. I'll paste this thread into a Radar.

Thanks for the feedback,
Doug

____________________
Doug Wyatt
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: CoreMIDI question (From: Kurt Revis <email@hidden>)

  • Prev by Date: Re: Client notification wierdiness
  • Next by Date: QTMA MIDIServices Device?
  • Previous by thread: Re: CoreMIDI question
  • Next by thread: Re: CoreMIDI question
  • Index(es):
    • Date
    • Thread