Re: [Libnifalcon-devel] np_nifalcon v1.0 + mac binaries released

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

Stephen Sinclair wrote:
>
> *clap clap clap*.. :)
>
> Your idea of "forever alpha" pales in comparison to some previous
> efforts of mine.  Hell I've got software that's still "alpha" after
> several years of work.  ;-)  I think it's a subconscious effort to
> make sure I never have any "users" to support.
>
>   
Yeah, that's why I went ahead and rolled things into beta, and just 
called np_nifalcon v1.0. I promised that this year I'd actually roll 
already started projects to v1.0 instead of just getting v0.1 out and 
running off to do something else, and I'm still determined. :)
> Anyways: I wouldn't get overly worried about the API itself.
> Personally I think making it "flat" is the best approach, but it
> depends on how much you think it will be expanded in the future, and
> need the kind of run-time flexibility that pulling pointers to objects
> gives you.  In this particular case, I think that's not really an
> issue.
I did some more thinking about this, and I'm fine with where things are 
now, I think. libnifalcon is really just a library of behaviors (comm, 
firmware, grip, kinematics) that form to make up a usable falcon object. 
FalconDevice just glues them and only combines them for the I/O loop.  
I'm going to make the I/O loop a little smarter (i.e. don't run 
kinematics unless raw values have actually changed), but other than that 
I figure it'll probably stay the way it is. Anyone that wants to do more 
(i.e. filtering the encoder/kinematics) will probably either do it above 
or below the FalconDevice level, so it's not really something to worry 
about too much. I just like worrying. :)
> One thing to consider is that calling a function that calls another
> function is slightly less performant than pulling a pointer and
> calling a function directly.  But it's mostly negligible compared to
> I/O speed.
>   
Not to mention, all of those function calls will probably be inlined 
into trivialness, either through inlined pointer accesses 
(pimpl/compiler firewall design) or becoming behaviors (policy design).
> In the end, most people will probably end up using libnifalcon through
> another API.  I've already started working on a CHAI3D driver for it,
> for example, and you've got the HDAL thing going too.
>   
Cool. :D I'm going to be concentrating on the max/pd external, falcon 
mechanics demo, and hdal layers for the moment, in order to figure out 
what else I need to make stable inside the driver itself.
> By the way, CHAI 3D is a good example of a haptics framework that
> provides timing support outside of the I/O call.  In libnifalcon when
> you call runIOLoop() you're committing to a sleep of 1 ms or so, which
> would get in the way of an already-well-timed haptic callback.
>
>   
You're only commiting to that sleep on libftdi, and then, possibly only 
on linux. FTD2XX has status calls since they have a thread maintained 
internal buffer, so I can exit early there. libusb-1.0 has early exit 
through poll calls.

> Hm.. okay I just looked at how it works, and it may not be a problem:
> You call libusb_handle_events_timeout(), which blocks until data is
> ready or there has been a timeout.  So if the software has already
> waited 1 ms in another loop, at least runIOLoop won't incur extra
> waiting.  Anyways I'll let you know more when I've tried it properly.
>   
libusb_handle_events_timeout() should never block, as it's called with a 
0 timeout. It handles whatever it needs to and returns ASAP. That means 
it should deal with polling the file descriptors, calling the callbacks 
if needed (which is where any non-trivial block would happen) and 
returning otherwise.

http://libusb.sourceforge.net/api-1.0/group__poll.html#g6deff4c7d3a6c04bb9ec9fd259b48933