Re: MusicPlayerIsPlaying() : is it done yet?
Re: MusicPlayerIsPlaying() : is it done yet?
- Subject: Re: MusicPlayerIsPlaying() : is it done yet?
- From: Bill Stewart <email@hidden>
- Date: Fri, 25 Jul 2003 21:50:28 -0700
There is no EOT event, so nothing to report...
What the seek to EOT does is just move the time stamp value of the
iterator to a value that is very high and thus not found in a track..
then when you seek the iterator to the previous event, it will go to
the last event in the track... This gives you the time of the last
event of the track - if that is a note event, you can look at the
duration... With Panther we will take into account the time stamp of
the EOT Meta Event, and take that into account when reporting the track
duration (This event is often tagged sometime after the last MIDI event
in a track to allow for reverb tails to die-down gracefully, etc)...
The tests for has current/next/previous event, should be performed to
complete an iteration cycle...
So, I think this is behaving as we'd expect - but let me know if you
still have questions
EOT Meta events are not retained by the MusicSequence when it parses a
MIDI file. It uses these events to know when it has reached the end of
a track. The MS doesn't need these events (and having them in a
sequence is an absolute pain if you are editing it!)... They are
correctly written when you save a sequence to an SMF of course.
Bill
On Friday, July 25, 2003, at 06:18 PM, Scott Ruda wrote:
I wrote in a previous post:
When iterating over the MusicTrack and you get the last event, which
should always be an EndOfTrack meta event, iter.getEventTime()
incorrectly reports a time of 0 for that event.
I see now that I was somewhat incorrect here. The timestamps are
reported correctly in the reverse iteration. I had tracks with nothing
in them but other meta events at time 0 in my test file and I
incorrectly assumed they were EndOfTrack meta events, which I was
expecting to see. Sorry for that misleading info. But...
It turns out that EOT meta events are not reported by the iterator at
all. Neither are kMusicEventType_Last events, which I'm not sure what
they are supposed to be for or even ever exist (I've never seen one).
Which means my primary assertion is still true - you can't really find
the true length of a track by looking at the timestamps of the events
returned by the current implementation of the iterator. It seems there
would need to be some kind of marker at the true end of the track
independent of notes and controllers and such to account for any
potential silent beats at the end of a track. Hopefully a solution to
this issue shows up at some point in a future release.
_______________________________________________
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.
--
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
________________________________________________________________________
__
_______________________________________________
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.