Re: behaviour of MIDIFlushOutput
Re: behaviour of MIDIFlushOutput
- Subject: Re: behaviour of MIDIFlushOutput
- From: "Evan Laforge" <email@hidden>
- Date: Wed, 10 Sep 2008 17:39:49 -0700
> I don't know where you're getting the idea that time stamp ticks are
> 1/100000ths of a second. The right constant is
> CAHostTimeBase::GetFrequency().
Oh, right, my app uses ms, so I was doing
AudioConvertHostTimeToNanos(AudioGetCurrentHostTime())/1000000 and
back again (MIDITimeStamp sends me to HostTime.h). When I copied the
timing over to the test program I just used those numbers, without
checking if they were correct.
> The extra note-off is because flush is protecting itself against a race and
> generating a note-off for a scheduled note-on without regard for whether the
> note-on has really been played.
>
> Thanks for catching a bug about pitch bend; CoreMIDI is stupidly sending
> 0xEn 0x00 0x00 instead 0xEn 0x00 0x40 to reset it to the center.
I see, so is part of the specification for MIDIFlushOutput that it
also stops sounding notes? The documentation doesn't say that... Are
there any bits of channel state other than note on and pitchbend it
will try to "undo" when descheduled?
While center is certainly a better guess than the bottom, it should
really be what pitchbend was before the flush. And I notice it
doesn't seem to try for other controllers? Aftertouch? Channel
pressure? It would be awkward if I were doing pitchbend from a base
other than the center, but fortunately I don't think I'll need to do
that. So I guess center will do well enough for me. Setting other
controllers to 0 regardless of what they were before would be awkward
though.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden