Re: MusicPlayerIsPlaying() : is it done yet?
Re: MusicPlayerIsPlaying() : is it done yet?
- Subject: Re: MusicPlayerIsPlaying() : is it done yet?
- From: Scott Ruda <email@hidden>
- Date: Fri, 25 Jul 2003 02:21:42 -0700
On Thursday, July 24, 2003, at 10:00 PM, Bill Stewart <email@hidden>
wrote:
We've added a track property in Panther to determine the "duration" of
a track
This is calculated (and can be done by you on Jaguar) by:
Iterate over the tracks in the sequence
Find the last event of each track (make a track iterator and seek to
the last event)
Is it later than my last kept know event time
- yes - that's my new last event time
I think there is a bug in the MusicEventIterator here too, at least in
the Java implementation.
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. So the iteration
continues searching for a time greater than 0 and you wind up getting
the time of the next to last event (usually a note or controller),
which is not usually the real length of the track. If it is a note,
even if you try to take the note time + its duration, you may not get
the true length of the track because there are often silence beats at
the end, e.g. to fill an even 8 beat pattern.
If you are just looking to stop the sequence approximately at the end,
just adding a few beats to the value derived from the iterator may be
OK. It may be important to look at the last note's duration, because it
could be more than a few beats.
This has been a problem for me as I've been trying to do looping which
requires an absolutely accurate length. (I think there may be a bug in
the MusicTrack LoopInfo property too, but I'm still investigating that.
Native event triggered looping would be so much better than doing it
with a polling task).
One workaround I'm currently doing in my Java code is to use the
JavaSound MidiSystem to load the SMF and ask it for the length, which
is accurate. You need to do a bit more stuff to turn its returned value
into a double beats value, but it can be done as
(tickLength/resolution) for a PPQ based sequence, or some other
gyration I haven't dealt with if it is a SMPTE based resolution.
Unfortunately that extra load is quite a waste of time, as the
JavaSound MidiSystem.getSequence call is horribly slow (compared to the
CA one). But at least it gets me the info I need.
I don't know if this same bug exists in the native implementation. If
it does, my only suggestion until it is resolved would be to parse the
SMF yourself to find the true length, which is not a trivial task. I've
written a few SMF Parsers, and there's quite a bit to it. You may be
able to get away easier if you only need to look for end-of-track
events, but that's still probably a few days of work at least.
_______________________________________________
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.