Is it possible to capture a line-in signal with NAudio in exclusive, event-driven mode?
If yes, is there an example available?
The WasapiCapture class does not support event mode currently. As it happens, I just did a check-in to support exclusive mode though, which will be part of NAudio 1.7 when it is released shortly. If you need event-driven mode, then you could just take a copy of the WasapiCapture class and make the modifications yourself.
Related
I'm using Rohitab's excellent API monitor tool to monitor the DLL calls that Keil uVision is making to Segger's JLinkARM.dll so that I can replicate them within an automated test environment.
As part of this I'm trying to understand the mechanism through which uVision communicates with the flash loader program to download the image being debugged.
I understand that uVision download's a flash loader program to the target device's RAM and that loader interacts with the onboard flash to erase it and download the new image, though I'm struggling to see the DLL calls which are made from uVision to actually stream the image down to the flash loader.
I would have expected to see a whole bunch of JLINKARM_WriteMem calls to stream the data down but I don't. I can see a bunch of JLINK_WriteReg and JLINK_ReadReg calls but not enough to comprise the image. My guess is they are for monitoring the flashing process. I know Jlink support a number of flash download related APIs but I don't see them used here. I don't see any paths being passed either. JLink's own log file is similarly unhelpful here. Is there some out of band mechanism I'm missing here?
Sorry. I shouldn't be posting questions like this when I'm tired. JLINKARM_WriteMem is exactly the mechanism used. I don't know why I didn't see them the first time I tried it.
I know you can use the AudioQueueGetCurrentTime method to get the current time. Is there a callback or something that continuously gets called to update your timeline? Or do you just have to create a timer to continuously call AudioQueueGetCurrentTime?
I don't remember any other way than timer, but I guess it is possible to implement periodic notifications without timer since you manually enqueue buffers and you know bitrate, etc...
As a side note: why not give a try to AVFoundation (available since iOS 4), it's all implemented there and until you have standard formats playback or you have to support iOS 3.x you don't really have to deal with AudioQueue horror.
I'm hacking the Kinect using some simple-openni based processing apps for a talk I plan to give soon and I found an API that appears to control the motor. There is a moveKinect method that appears to be added to the main ContextWrapper interface but I can't seem to get it to work. Looking through the svn history and release notes it appears to have been added last year with a note that explains it doesn't work with the newest drivers(5.1.02,Linux64). I've tried calling the method giving it values in degress and radians but nothing happens. I get no error and no movement. Has anyone else played with this? I'm running with the 2nd to latest processing 2.0 build (the link to processing 2.0.1 doesn't work) and the latest SImpleOpenNI package I could download.
SimpleOpenNI is the wrapper for OpenNI which allows access to the RGB/IR/Depth streams and the middleware for body/hand detection, but does not allow access to hardware like the LED, accelerometer or motor.
You should try Kinect P5 which uses libfreenect behind the scenes and supports motor control. Bare in mind you won't have support for the middleware.
If you need both middleware and hardware access you can try OpenFrameworks with the ofxOpenNI addon. It has a has a hardware class that works on OSX and Linux (as sudo) allowing use of both the middleware and motor.
I want to try and make my own application for my Novation Nocturn, which is a USB DJ controller surface. The application software interacts with it to send out MIDI messages to software like Traktor, Ableton and Cubase.
I'm aware of libusb, but that's as far as I've got. I've successfully installed it to interact with my device but stopped there.
I'm after some suitable reading material basically. USB specs, MIDI specs and such. If I'm honest the full USB 2.0 spec looks like it holds loads of stuff I don't need.
Just looking for something interesting to do now that I've finished my degree (Computer Science). My current programming knowledge is C++ and mainly C#.
Could do with some direction on how to get stuck into this task.
edit:
Update to include some info from the Device Manager on the Nocturn.
Hardware IDs:
USB\VID_1235&PID_000A&REV_0009
USB\VID_1235&PID_000A
Compatible IDs:
USB\Class_FF&SubClass_00&Prot_00
USB\Class_FF&SubClass_00
USB\Class_FF
Device Class:
MEDIA
USB MIDI is probably one abstraction layer lower than you want to deal with. I'd suggest finding a good MIDI framework and interacting with the device via MIDI instead.
For C++, Juce is probably the way to go, as you didn't mention a target platform or any other specific requirements.
If you want to go the .NET route, the easiest way to get started is with the C# MIDI Toolkit code:
http://www.codeproject.com/KB/audio-video/MIDIToolkit.aspx
In there, you'll find all the basics for opening an device, reading input, and writing output. Alternatively, NAudio has some MIDI classes, but they are somewhat incomplete.
As you develop, you'll want a reference for the MIDI spec handy.
A tool that you will find invaluable is MIDI-OX. In fact, I suggest that before you start coding, you fire up MIDI-OX and use it to sniff the messages coming from the Novation. It will give you a good idea of what the Novation sends. You can use it in conjunction with MIDI Yoke (a configurable virtual MIDI port) to insert itself between the Novation, and Ableton Live (or whatever software you normally use with your Novation) so you can see all of the messages in normal use.
Done... Kidding, but I've started on this in Python - I personally want linux support. I am teaching myself python, but I only dabble in programming.
You can see basic functionality at https://github.com/dewert/nocturn-linux-midi. The guy who reverse engineered it (i.e. the leap I wouldn't have been able to make myself) doesn't seem to be doing any more with it. His code is at https://github.com/timoahummel/nocturn-game
I am using PyPortMIDI and PyUSB, both of which I believe are wrappers for the C equivalents. I think this is all ok on Windows, but haven't tried.
What is currently on my github is crap, but it is proof-of-concept. I'm working on doing it properly now, with threading and proper configuration options.
The driver for the Nocturn makes it appear to system as a MIDI device, even though it isn't a USB MIDI device at the hardware level. The Automap software works entirely at the MIDI level, receiving MIDI instructions and sending different instructions in response - it is separate from the driver and not neccesary.
Alternatively, look at https://github.com/timoahummel/nocturn-game for an example of talking to it directly over USB from Python. You can probably port this to another language with libusb bindings.
Old thread, but I've just recently started looking into this.
I had a look at the Python application that dewert has written. Interestingly, it turns out that the data that the Nocturn emits is in fact MIDI, although it doesn't register itself as a USB MIDI device.
But looking at the actual data coming from the device, it actually emits control change messages (0xB0 controller value) for everything. Also the control commands that are sent to it are also control change messages, albeit only the data bytes, as the Nocturn seems to support MIDI running status (i.e. when sending multiple control change messages, it is not necessary to repeat the data byte).
Indeed, the looking at the magical initialization data it is actually just a bunch of control changes: it starts with 0xb0 and from there on the data comes in twos. For instance the last two bytes in the init string are 0x7f 0x00 which simply turn off the LED for the rightmost forward button. (There is something subtle happening as a result of the initialization being sent though, as the Nocturn sometimes emits some messages which appear to be some form of timeout events, and that behavior changes depending on whether the initialization string has been sent or not.)
Using MIDI-like messages makes sense, as Novation would be well aware of the MIDI protocol, so it would be easiest for them to use it for the communication even if the device is not strictly a MIDI device.
Note though that the incrementors just send the values 1 or 127, i.e. +1 or -1 step, so even with some trivial mapping software it's not really useful as it is. (Actually, if turned quickly, one can get 3 or 125 for instance, with the 125 corresponding to -3.) The only controller which sends a continuous value is the slider, which emits an 8 bit value when moved.
I suppose you'll want to know about USB classes in general and USB MIDI class in particular. The latter is the best what you can hope for in case you don't posess documentation for some proprietary protocol (whether it's used there instead).
I'm writing a program that needs to take input from an XBox 360 controller. The input will then be sent wirelessly to an RC Helicopter that I am building.
So far, I've learned that this can be done using either the XInput library from DirectX, or the Input framework in XNA.
I'm wondering if there are any other options available. The scope of my program is rather small, and having to install a large gaming library like DirectX or XNA seems like excessive. Further, I'd like the program to be cross platform and not Microsoft specific.
Is there a simple lightweight way I can grab the controller input with something like Python?
Edit to answer some comments:
The copter will have 6 total propellers, arranged in 3 co-axial pairs. Basically, it will be very similar to this, only it will cost about $1,000 rather than $15,000. It will use an Arduino for onboard processing, and Zigbee for wireless control.
The 360 controller was selected because it is well designed. It is very ergonomic and has all of the control inputs needed. For those familiar with helicopter controls, the left joystick will control the collective, the right joystick with control the pitch and roll, and the analog triggers will control the yaw. The analog triggers are a big feature for the 360 controller. PS and most others do not have them.
I have a webpage for the project, but it is still pretty sparse. I do plan on documenting the whole design though, so eventually it will be interesting.
http://tricopter.googlecode.com
On a side note, would it kill Google to have a blog feature for googlecode projects?
I would like the 360 controller input program to run in both Linux and Windows if possible. Eventually though, I'd like to hook the controller directly to an embedded microcontroller board (such as Arduino) so that I don't have to go through a computer, but its not a high priority at the moment.
It is not all that difficult. As the earlier guy mentioned, you can use the SDL libraries to read the status of the xbox controller and then you can do whatever you'd like with it.
There is a SDL tutorial: http://sdl.beuc.net/sdl.wiki/Handling_Joysticks which is fairly useful.
Note that an Xbox controller has the following:
two joysticks:
left joystick is axis 0 & 1;
left trigger is axis 2;
right joystick is axis 3 & 4;
right trigger is axis 5
one hat (the D-pad)
11 SDL buttons
two of them are joystick center presses
two triggers (act as axis, see above)
The upcoming SDL v1.3 also will support force feedback (aka. haptic).
I assume, since this thread is several years old, you have already done something, so this post is primarily to inform future visitors.
PyGame can read joysticks, which is what the X360 controller shows up as on a PC.
Well, if you really don't want to add a dependency on DirectX, you can use the old Windows Joystick API -- Windows Multimedia -> Joystick Reference in the platform SDK.
The standard free cross plaform game library is Simple DirectMedia Layer, originally written to port Windows games to Unix (Linux) systems. It's a very basic, lightweight API that tends to support the minimal subset of features on each system, and it has bindings for most major languages. It has very basic joystick and gamepad support (no force feedback, for example) but it might be sufficient for your needs.
Perhaps the Mono.Xna library has added GamePad support, which would provide the cross platform functionality you were looking for:
http://code.google.com/p/monoxna/
As far as the concerns about the library being too heavy weight, sure, for this option it may be true ... however, it could open up opportunities to do some nice visualization in the future.
disclaimer: I'm not familiar with the status of the mono xna project, so it may not have added this feature yet. But still, 'tis an option :-)