drfriendly

I am writing an external that enables access to the analog and digital inputs & outputs of the National Instruments USB 6008, an inexpensive ($150) and compact USB DAQ with pretty good performance. An OS X API is available from NI, which is what I'm using.

I have been able to access all the capabilities but not without some odd side-effects.

When the NI code is called for the forst time within Max, the program freezes for several seconds, after which it works pretty quickly. However, in every case where I run the NI code, Max stops responding to the Quit command (command -Q or the menu item), and can only be shut down using Force Quit.

The NI API for OS X is not thread-safe according to the readme files, so I put all calls to the NI code in critical regions. This doesn't eliminate the problems, though.

Any thoughts or interest in working with me on this?

I am writing an external that enables access to the analog and digital inputs & outputs of the National Instruments USB 6008, an inexpensive ($150) and compact USB DAQ with pretty good performance.  An OS X API is available from NI, which is what I'm using.

When the NI code is called for the forst time within Max, the program freezes for several seconds, after which it works pretty quickly.  However, in every case where I run the NI code, Max stops responding to the Quit command (command -Q or the menu item), and can only be shut down using Force Quit.

The NI API for OS X is not thread-safe according to the readme files, so I put all calls to the NI code in critical regions.  This doesn't eliminate the problems, though.

national-instruments-daq-api-troubles

Can you spawn another thread that inits the NI code? I understand 

that it's not thread-safe, but if all of the calls to the NI stuff is 

happening from the same thread, you should be okay. I've had similar 

problems with open / save dialogs in Carbon apps when I have some 

You might be causing your main thread (that binds to the runloop) to 

block. This will block all processing of AppleEvents, including the 

quit event, in addition to mouse events etc.

Can you spawn another thread that inits the NI code?  I understand  
that it's not thread-safe, but if all of the calls to the NI stuff is  
happening from the same thread, you should be okay.  I've had similar  
problems with open / save dialogs in Carbon apps when I have some  
sleeping media attached to the machine.

You might be causing your main thread (that binds to the runloop) to  
block.  This will block all processing of AppleEvents, including the  
quit event, in addition to mouse events etc.

if you are still interested i have done a very simple and very beta-version of such an external... many things to do but it goes

National Instruments DAQ API troubles