[Libnifalcon-devel] Fading lights! (And changes to core function signatures but more importantly) Fading lights!

[Kyle M. (qDot) <ky...@no...>]

So, I spent this weekend working on libnifalcon and got quite a bit done 
in the way of internal fixes and stability. But, most importantly, 
fading lights! Decided to trying a variable duty cycle algorithm using 
just the USB communications, and it turns out that you can get a smooth 
ramp for all 3 front panel LEDs with a around a 20ms duty cycle. So, 
4.25 bits of color per LED! It actually looks pretty nice, even though 
there's no internal defuser so you still get the directional issues from 
the LEDs being point sources. This has been added as FalconColorTest in 
the falcon_test_cli example. I'd upload a video, but it looks like crap 
on recorded video. Damn you, Nyquist!

However, this brings up more important issues, like the fact that I also 
kind of changed the way I do all the array passing internally. :)

Since I decided to go ahead and use boost::shared_ptr for the pimpl 
stuff in FalconDevice (I really don't know what the hell I was thinking 
when I first put all this together, other than just not having written 
drivers like this before and not sure whether I could force people into 
using libraries, but, well, experience now tells me that I can, and if 
they don't like it, they can go write their own. :) ), I also decided to 
move all of the gross array reference passing to just use boost::array. 
Unfortunately, this is gonna break... Well, pretty much everything that 
needed to get positions or set forces. So, as not to completely screw 
everyone who's actually working with the library, all of this (array 
passing and fading lights) is off on its own branch for the moment:

http://github.com/qdot/libnifalcon/tree/boost-array-params

I really don't think this is going to cause too many issues with 
everyone's libraries (just change what goes into/out of these functions, 
everything else just looks like an array otherwise), and should 
hopefully be nearing the possible end of major external-facing function 
signature changes. I'd like to keep everything outside talking in arrays 
(versus vector objects from a math library) so that we maintain a level 
of abstraction between any specific math and just wanting to get data 
back and forth, especially with the upcoming move from gmtl to eigen 
inside libnifalcon.

I'll also probably be updating the np_nifalcon external binaries and 
code soon, as I've been getting a few requests for that lately anyways.