Everyone, if it will be helpful I offer my solution: I just created a delayed task that would begin the play of the music a fraction of a second after requesting the draw of the newly loaded composition. This is pretty clean; the view does all it wants to do in much less time than I'm giving it, yet to the user the play seems to begin immediately after the music appears. And in that time the drawing has completed any adjustments it needed.
Syncing is another matter, and that is handled separately - a timer process checks for the need to scroll, to move markers, etc. Coordination is not mathematically exact, but it is close enough that it would be difficult to notice any discrepancy between the audio and the visual. Jeff On Feb 4, 2016, at 4:52 PM, Doug Hill wrote: Jeff, AV sync issues are definitely tricky. I would be interested in hearing opinions from others on how they deal with these sync issues. I think you’re on the right track, in that you’re trying to use messages to determine when your visual state will match the audio state. As you’re seeing, using the mechanics of NSView to derive these messages is problematic as there are so many optimizations going on under the hood that I doubt there’s a good way to get low-latency, reliable messages that you want. One idea that comes to mind is that view animations have completion callbacks when they’re finished which might be an avenue to explore. Anyways, hopefully there are others out there that have had to deal with these AV sync issues and can give more feedback. Doug > On Feb 4, 2016, at 4:39 PM, Jeff Evans <jev...@ars-nova.com> wrote: > > Doug, I had found that if the drawing mechanism was still cleaning up a few > visual details - adjusting a beam or stem length after getting the context of > the drawing as a whole, etc. - then it looked bad if the music began playing > before that was finished. There are doubtless multiple issues here; I'm > translating something from ios - but it struck me that if I just waited until > no more draws were coming in that would be one way out. > > > On Feb 4, 2016, at 4:31 PM, Doug Hill wrote: > > Jeff, > > Are you attempting to sync the drawing with the music or are you attempting > to deal with a performance issue? > > Doug Hill > >> On Feb 4, 2016, at 3:52 PM, Jeff Evans <jev...@ars-nova.com> wrote: >> >> Clark, it's a music app; a piece is composed and placed on the screen; >> there's a lot of massaging going on as the music adjusts visually. I want >> the play of the example to begin once there are no more updates remaining. >> That is no noticeable delay in terms of human time, but makes a difference >> in the appearance. >> >> So I figure: the system presumably knows if it is about to send more redraw >> requests to that view. Is there any way I could know what it knows? >> >> Jeff >> >> >> On Feb 4, 2016, at 3:31 PM, Clark S. Cox III wrote: >> >> >>> On Feb 4, 2016, at 15:07, Jeff Evans <jev...@ars-nova.com> wrote: >>> >>> Suppose one wants to do a task in an NSView only once it has no drawRect >>> calls pending. Is there any way to tell, for a particular NSView, if there >>> are any drawing events coming up? Whether, that is, the view is up to date? >>> >>> I've tried counting my explicit uses of setNeedsDisplay and decrementing >>> that count at drawRect, but the trouble is that one can call >>> setNeedsDisplay many times and that will not translate into the same number >>> of drawRects. >>> >>> One idea was to call getRectsBeingDrawn at drawRect and hope that the >>> number of rects is equal to the number of update requests combined into >>> that call. But the number of rects does not appear to equal the number of >>> draw requests. >> >> Multiple invalid regions can be merged. >> >>> But there must be some place that contains a queue of upcoming draw >>> requests. If so, is there access to it? >> >> There really isn't any such queue. There are only areas of the view that are >> marked as invalid. >> >>> I'm hoping this is a dumb question. >>> >>> Thanks, Jeff >> >> I hate to be "that guy", but what are you actually trying to do? If this email is spam, report it to www.OnlyMyEmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
