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

[Stephen S. <rad...@gm...>]

On Sun, Nov 16, 2008 at 8:30 PM, Kyle Machulis (qDot)
<ky...@no...> wrote:
> Just uploaded what I'm calling v1.0 of np_nifalcon. There's still some
> known crashers in it, but I'd rather not get into the "forever alpha"
> loop that I have with libnifalcon again. :)


*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.

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.

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.

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.

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.

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.


Steve