Re: Unable to set renderer callback
Re: Unable to set renderer callback
- Subject: Re: Unable to set renderer callback
- From: William Stewart <email@hidden>
- Date: Tue, 4 Sep 2007 17:35:31 -0700
The SetRenderCallback is a callback that is only for providing audio
input to an AU that has audio input. As the music device doesn't have
audio input it fails as you see.
If you want to get called on the render thread of an AU you can add a
RenderNotify (AudioUnitAddRenderNotify) that will call you both
before and after the AU's rendering code is called (but on the same
thread while the AU is in its AudioUnitRender call).
MusicDeviceMIDIEvent is an API call that is made to schedule MIDI
events to a synth or effect that supports MIDI. Some releases ago, we
had a threading problem with scheduling notes on or off from the non-
render thread, but this has been fixed for some time now, so this
won't be your problem.
I would really look closely at the MIDI processing. I'd look at the
various MIDI messages you are sending and make sure they are correct.
A common mistake is how notes off are handled (they can be sent in
two different ways in MIDI - as the note off message, or as a note on
with a velocity of zero). You can do some kinds of transformation to
MIDI in AULab and we've not seen any problems here with stuck notes.
In AULab we do schedule the MIDI messages on the render thread (so we
can apply a buffer offset), but otherwise the calling should not be
much different from what you are doing.
Bill
On 04/09/2007, at 10:07 AM, Todd Blanchard wrote:
This is driving me nuts and has been for about 3 weeks now.
The underlying problem: Calling MusicDeviceMIDIEvent from the midi
receive thread drops events - I end up with stuck notes. I have
carefully logged the events I'm getting and I am absolutely
convinced there is no problem receiving the events. It is in the
sending of them.
My app does some note filtering and transposition of events so I
have to intercept, fiddle, and then send them on. I have logged
what I send. There is no problem there.
I read an earlier thread in the archives that implied that sending
calling MusicDeviceMIDIEvent from the receive thread might be a
problem and suggested queueing the events and sending them on in
the pre-render callback. So I'm trying to do that.
This device behaves properly from digital performer and various
other containers. So I assume the problem is mine.
However - all efforts to set the rendercallback using
AudioUnitSetProperty(au, kAudioUnitProperty_SetRenderCallback,
scope, 0, &cbstruct,sizeof(cbstruct))
where scope is input, output or global (how exactly is one supposed
to know - it is a soft synth - all the examples show it on the
input side of DefaultOutput?) fail with -10877 - no such element.
I've tried element 1 as well - just for grins.
I've tried delaying installation of the callback until after I call
graph update.
Is the callback supported universally or at the pleasure of the
component implementor?
Suggestions for either
1) improving the reliability of sending midi events or
2) getting the callback installed so I can try sending them on the
pre-render callback
would be gratefully received.
Todd Blanchard
_______________________________________________
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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