Re: NSTimer and trackpad and mouse clicks
Re: NSTimer and trackpad and mouse clicks
- Subject: Re: NSTimer and trackpad and mouse clicks
- From: Brian Willoughby <email@hidden>
- Date: Mon, 07 Nov 2011 17:45:07 -0800
Mark, it seems like you're sending Tom off if the wrong direction if
you're suggesting that he has to customize every UI object in his
application to avoid everything coming to a halt when the mouse
button is held down.
It's difficult for me to say without Tom's source, but everyone
should keep in mind that NSTimer works with a Run Loop, and the
default run loop is shared by the entire application for UI. If
Tom's NSTimer is attached to the main run loop, then all UI code will
be competing with his MIDI code.
The better solution would be to create a separate Run Loop, or, more
likely, just create a new NSThread and use the automatically-create
Run Loop for that thread. Dedicating a thread to the timing of MIDI
is far more sensible that rewriting AppKit to avoid all blocking API
(of which there are many).
See the documentation for NSTimer, NSRunLoop and NSThread - and be
sure to follow all links in the documentation to related concepts.
Just because it's easy to use NSTimer without doing your homework
doesn't mean you're going to get the best results in every
situation. :-)
Brian Willoughby
Sound Consulting
On Nov 7, 2011, at 17:31, Mark Pauley wrote:
So: subclassing would change the way your event handling code
fundamentally works.
What I'm saying is that to do what you want, you need to customize
the UI objects. The default behavior for buttons is to not take
action until the mouseUp happens inside of the button's frame.
Other folks get around this by subclassing the button and
triggering a custom event from mouseDown / mouseDragged etc. The
default behavior of NSButton won't give you what you want.
I still don't get how this blocks your MIDI code from running...
your buttons should get a mouseDown event (which they eat) and then
bail... at which time your process is sitting in the main run loop
waiting for your sequencer timers to fire and/or more events to
come in. If your sequencer stops running, maybe you could grab a
sample of this (via Activity Monitor) and post it here.
On Nov 7, 2011, at 4:55 PM, Tom Jeffries wrote:
Mark, to the best of my knowledge I'm using absolutely standard
calls. I put the buttons on the interface using Interface Builder
and set up IBAction calls to tell me when they are pressed. I set
a breakpoint on the IBAction function and nothing happens until I
release he mouse button. Here's one of the functions:
- (IBAction) key1 : (id) sender
{
[self RespondToKey : KEY_1];
}
I'm not sure what subclassing would do, the IBAction function is
not called until the mouse button is released or you take your
finger of the trackpad.
I'm no Mac guru, so it's entirely possible I'm missing something
obvious.
On Mon, Nov 7, 2011 at 3:52 PM, Mark Pauley <email@hidden> wrote:
You could make your own subclass and handle mouseDown...
What do you mean by 'it all stops'? If your sequencer stops when
the mouse button is down, something is really wrong. The main
thread ought not lock up under those circumstances.
On Nov 7, 2011, at 3:25 PM, Tom Jeffries wrote:
I've got my CoreMIDI sequencer working fine under most
circumstances. I use NSTimer to get a rough timing, then use
properly computed times that I send to MIDIPacketListAdd to get
the accurate timing. NSTimer is running a bit in advance of the
correct time so that even if it's late the data gets to the
right place in time.
However, if I start the sequence playing, then use either the
trackpad or a mouse to go to a button on the screen, and hold
the trackpad or mouse button down, it all stops. I put a
breakpoint on the IBAction function that responds to the mouse/
trackpad click, and it is not called until the mouse is released
or the finger comes off the trackpad. I've seen other programs
handle this correctly, so there has to be a better way.
_______________________________________________
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