Re: Alternative to Delay()
Re: Alternative to Delay()
- Subject: Re: Alternative to Delay()
- From: Geoff <email@hidden>
- Date: Thu, 1 Jan 1970 23:50:05 +1000
On Wed Jul 30, 2003 7:42:07 AM Australia/Sydney
B.J. Buchalter <email@hidden> said:
Now this is probably off the point of the original Delay question --
which I agree is not a great user experience. But TrackMouseLocation
used properly is pretty cool.
I posted the original question and the reason I mentioned
TrackMouseLocation was to pursue the possibility that there might be a
Delay type routine that worked similarly. As for your point about it
being pretty cool I have to agree. I have a piano control and I'm
trying to make the interaction with it as realistic as possible. I use
an action proc to enable responding from the point of the mouse down.
If you put the mouse down on a key (action proc is called with part ==
key and hilite == key) and then drag off the key (hilite == zero), like
a real piano the key goes back up and so the note stops sounding. If
you slide the mouse back over the key (part == key and hilite == key) -
not what you would do with a real piano if your finger slid off a key -
I don't want the note to restart because with a real piano you would do
this by lifting up your hand and depressing the key again (another
mouse down). So, if and when the mouse first goes out of the key I use
TrackMouseLocation to wait for the mouse to go back up. The user is
meanwhile holding the mouse down outside the piano for no particular
reason and would have to let go before doing anything else with my app.
If they don't let go, what are they waiting for, Godot perhaps?
TrackMouseLocation only returns when the mouse state changes which is
hardly taxing the system, meanwhile the system is in charge. The main
point here is that you can't click the mouse down on something else
while it's still down from the last click.
I am writing a very computation/algorithm intensive app, many thousands
of lines of code to provide MIDI related services and one of the things
I love about OS X is that I can use routines like
RunApplicationEventLoop and not have to worry about too many of the GUI
details and focus on what my app actually does. If I start introducing
some of the micro management that's been mentioned here I'll never
finish.
That doesn't mean I don't care about the user interface and that I'm
willing to compromise the user experience, sometimes an acceptable
solution just requires thinking differently about the problem rather
than throwing masses of complexity at it . I've tested MPDelayUntil and
I'm aware that if the user tries to do anything else in my app while
waiting for it to return they get the spinning colour wheel but my
problem is that I'm writing an Editor/Librarian (one life's work) not a
sequencer (another life's work) so for the sake of sending a shortish
test tune I can't afford to be too fancy, so I've simply dispensed with
the delay, and if the user wants to piddle with the tune button and
overlap multiple copies who cares? Or if they want to do something else
more productive before the tune is finished, well, it's already gone
down the cable so they can do that if they want.
Cheers Geoff %^>
_______________________________________________
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.