Re: Sample-accurate parameter automation? Possibe at all with AUs?
Re: Sample-accurate parameter automation? Possibe at all with AUs?
- Subject: Re: Sample-accurate parameter automation? Possibe at all with AUs?
- From: Greg X <email@hidden>
- Date: Thu, 13 Mar 2008 03:03:25 -0700 (PDT)
Mr. Stewart! (and other experienced people ;)
I think that I have to explain my questions a bit
more.
Facts:
- I'm inheriting from MusicDeviceBase.
- I use HandleMidiEvent directly. Not higher level
implementations.
In HandleMidiEvent:
I set up MIDI related variables directly depending on
the last MIDI event.
Like setting up values of internal CC variables,
setting up pitch bender variables, collecting pressed
keys, etc...
I do not care about inStartFrame and I don't implement
any scheduling. I'm just setting up variables
directly, that's all.
Why? Because the Render buffer will be automatically
split up at the same sample position at which this
HandleMidiEvent occured.
So, HandleMidiEvent will be followed by a Render slice
immediately starting at the same sample position as
this HandleMidiEvent.
Is that right?
In Render:
1. I only call GetParameter (for each parameter) once
at the beginning of Render.
Why? Because I think that the render buffer was
previouly split up on parameter change boundaries.
So, the parameter values are always the same for one
slice.
It is sample-accurate parameter handing this way.
Is that right?
2. I'm using the variables set up by HandleMidiEvent
directly and I do not care about any kind of MIDI
event polling.
Why? Because I think that the render buffer was
previously split up on any kind of MIDI events (CCs,
PB, note on/off, etc...).
So, the variables set up by the previous
HandleMidiEvent are sample-accurate at the beginning
of this slice I'm just rendering.
..and all of the next inNumberFrames samples have to
use the same MIDI related variable values (set up by
the last HandleMidiEvent).
Is that right?
My confusion (if this all is right):
What is the purpose of inStartFrame in
HandleMidiEvent?
If the render buffer will be automatically split up at
each MIDI event, it means that each render slice will
have its updated MIDI based variables at sample #0 and
these variables can't change during a slice, since a
next MIDI event will split up the buffer again.
I've read on this list that inStartFrame is an offset
into the next slice.
If the render will be sliced up on every MIDI event,
you *must* have always zero in this variable.
I simply don't get it how can these two things
co-exist. (automatic buffer slicing and non-zero
inStartFrame)
Do I have to care about the calling thread of
HandleMidiEvent when inheriting from MusicDeviceBase?
It would mean that I have to implement scheduling.
But if all of my initial statements are right, I don't
have to. Since each MIDI event will be followed
immediately by a render.
I hope your answers will make my serious confusion to
go away finally.
Thank you!
Greg1X
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
_______________________________________________
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