libnifalcon-devel Mailing List for Novint Falcon Open Source Library

Does anyone in the project group have experience using Matlab to control 
Falcon?

	-tcaarset

Great! I encourage the ambition and the work. One day I also hope we can have
open hardware for haptics, which certanly would help the community grow.

Jonas

2010/5/25 Kyle Machulis <ky...@no...>:
> Ok, after a nice 8 month break from libnifalcon, I'm starting to take a look
> at the library again, and am planning for the next 2 versions, 1.5 and 2.0.
> For 1.5, I'm thinking I need to take things in a simpler direction. I
> originally wrote libnifalcon in C, just to finish out the protocol, then
> decided to try writing it in C++ in order to make it as extensible as
> possible, allowing developers to easily switch out firmware, grip, and
> kinematics cores. I went a little overboard with this by making the
> FalconDevice class composable via templates, though I scaled that back a bit
> with the "DefaultDevice" class. However, I've found that I'm really the only
> one that cares about the kinematics cores, and until the firmware and grip
> protocols are reversed (which will have to happen at the same time, since
> the firmware dictates the grip communication), there aren't a lot of choices
> to be had in firmware and grip core classes. So, I'm thinking I may slide a
> lot of the code back down to C, and implement the current API on top of that
> again. This will make the library more usable for those that don't want to
> screw with C++, make it easier for me to debug on things like Max/Pd
> externals, and shouldn't really affect the API that's already in place. I'd
> also like to go ahead and add all of the declspec calls and what not to make
> it actually compile into a DLL on windows, too, though that's not a super
> high priority.
> I'm also taking a look at libftdi-1.0, which would clean up the mess I made
> of the comm code by implementing a crude version of libftdi on top of
> libusb-1.0 myself. However, it's currently still just a git branch in the
> libftdi repo, so I'm not sure how complete it is.
> I'm still planning on v2.0 being the point where the grip/firmware is
> reversed, which means not any time soon, unless some enterprising student
> feels like taking it on as a project. It's happened before, after all.
> Anyways, does anyone else have any requests for v1.5? Any opinions on what
> I've got planned so far?
> Who knows, maybe I'll actually write an application with this thing someday
> too.
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Libnifalcon-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libnifalcon-devel
>
>

Ok, after a nice 8 month break from libnifalcon, I'm starting to take a look
at the library again, and am planning for the next 2 versions, 1.5 and 2.0.

For 1.5, I'm thinking I need to take things in a simpler direction. I
originally wrote libnifalcon in C, just to finish out the protocol, then
decided to try writing it in C++ in order to make it as extensible as
possible, allowing developers to easily switch out firmware, grip, and
kinematics cores. I went a little overboard with this by making the
FalconDevice class composable via templates, though I scaled that back a bit
with the "DefaultDevice" class. However, I've found that I'm really the only
one that cares about the kinematics cores, and until the firmware and grip
protocols are reversed (which will have to happen at the same time, since
the firmware dictates the grip communication), there aren't a lot of choices
to be had in firmware and grip core classes. So, I'm thinking I may slide a
lot of the code back down to C, and implement the current API on top of that
again. This will make the library more usable for those that don't want to
screw with C++, make it easier for me to debug on things like Max/Pd
externals, and shouldn't really affect the API that's already in place. I'd
also like to go ahead and add all of the declspec calls and what not to make
it actually compile into a DLL on windows, too, though that's not a super
high priority.

I'm also taking a look at libftdi-1.0, which would clean up the mess I made
of the comm code by implementing a crude version of libftdi on top of
libusb-1.0 myself. However, it's currently still just a git branch in the
libftdi repo, so I'm not sure how complete it is.

I'm still planning on v2.0 being the point where the grip/firmware is
reversed, which means not any time soon, unless some enterprising student
feels like taking it on as a project. It's happened before, after all.

Anyways, does anyone else have any requests for v1.5? Any opinions on what
I've got planned so far?

Who knows, maybe I'll actually write an application with this thing someday
too.

Hi,

I downloaded libnifalcon since I would like to use Falcon on OS X.

I succeeded in installing libnifalcon through CMake.

I compiled and ran libnifalcon. However when launcining the examples,  
I found that only "finfalcons" and "findfalcons_mult"2 examples work.
When running "falcon_mouse", I get the following message on OS X  
terminal:


~ andrea$ /Applications/libnifalcon-1.0.1/build/bin/Release/ 
falcon_mouse ; exit;
No device index specified to open, cannot continue (--help for options)
logout


Please, could you tell me how to fix this issue?

Thank you in advance.

Best Regards,

Andrea Moglia


Andrea Moglia, PhD


EndoCAS, Center for Computer Assisted Surgery
University of Pisa
via Paradisa 2
56124 Pisa, Italy

Phone:	+39 050 995 689
Fax:		+39 050 995 676
e-mail:	and...@en...
web:	www.endocas.org

On Tue, Mar 2, 2010 at 5:18 AM, Andrea Moglia <and...@en...>wrote:

> Hi,
>
> I tried to compile Libnifalcon using CMake GUI to cerate project files
> for Xcode (I am a OS X user), but I have problems with both Boost
> 1.42( installed as explained at:
> http://www.boost.org/doc/libs/1_42_0/more/getting_started/unix-variants.html
> )
>  and Boost-CMake 1.41 (installed as explained at:
> http://sodium.resophonic.com/boost-cmake/current-docs/)
> .
>
> If I use Boost 1.42, after pressing "Configure" in CMake GUI, I get
> the message "Boost NOT found" although I inserted the path to the
> "Boost/include" directory.


Yeah, this comes from cmake 2.6 not being very flexible about new boost
versions. I'll need to update the cmake code to add the versions it should
look for (anything >= 1.33 should work, honestly).


> If I use Boost-CMake 1.41, after presssing
> "Configure" in CMake GUI I get the message
> "Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG-NOTFOUND" and
> "Boost_THREADS_LIBRARY_DEBUG-NOTFOUND" in CMake GUI. This is due to
> the fact that when compiling Boost-CMake 1.41 only libraries in
> release mode are created.
>
> Please, could you indicate me how to install preficiently Boost and
> then Libnifalcon?
>
>
Does the cmake configure step actually fail after this? It shouldn't require
the debug libraries, should just say it can't find them, which is fine.

Hi,

I tried to compile Libnifalcon using CMake GUI to cerate project files  
for Xcode (I am a OS X user), but I have problems with both Boost  
1.42( installed as explained at: http://www.boost.org/doc/libs/1_42_0/more/getting_started/unix-variants.html) 
  and Boost-CMake 1.41 (installed as explained at: http://sodium.resophonic.com/boost-cmake/current-docs/) 
.

If I use Boost 1.42, after pressing "Configure" in CMake GUI, I get  
the message "Boost NOT found" although I inserted the path to the  
"Boost/include" directory. If I use Boost-CMake 1.41, after presssing  
"Configure" in CMake GUI I get the message  
"Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG-NOTFOUND" and  
"Boost_THREADS_LIBRARY_DEBUG-NOTFOUND" in CMake GUI. This is due to  
the fact that when compiling Boost-CMake 1.41 only libraries in  
release mode are created.

Please, could you indicate me how to install preficiently Boost and  
then Libnifalcon?

Thank you in advance.

Best Regards,


Andrea

I wouldn't recommend actually shorting it for any length of time but if you
stick resistor across two of the pins (I think the middle two) it should
stay on for about five minutes, at least the ones I tried do.

 

Good luck,

Ally

 

  _____  

From: Kyle Machulis [mailto:ky...@no...] 
Sent: 02 November 2009 21:11
To: Stephen Sinclair
Cc: lib...@li...
Subject: Re: [Libnifalcon-devel] Anyone near austria that has an extranovint
falcon grip? :)

 

I'm honestly not sure. I think the grips have some sort of identification
with the firmware (since I /think/ they released a firmware update when the
pistol grip came out, for example, but I may be making that up). I might try
shorting things and seeing what happens though. My grip arrives saturday
morning otherwise, which just means I have 5 days to work on other things.
:)

Kyle

On Mon, Nov 2, 2009 at 3:42 PM, Stephen Sinclair <rad...@gm...>
wrote:

Yikes, maybe you could short two of the grip connections using a wire?

Steve



On Sat, Oct 31, 2009 at 2:06 PM, Kyle Machulis <ky...@no...>
wrote:
> So, I'm in Vienna, Austria for the next 5 weeks as part of an artist
> residency. Just started unpacking all of my hardware here, and realized
that
> when I disassembled my falcon, I forgot to throw the grip in with it,
making
> me pretty dead in the water since the falcon won't communicate without a
> grip. Now, I can get one next week when another friend comes into town
that
> can bring the one I forgot with them, but I was wondering if anyone on the
> list here is in Vienna and happens to have an extra grip I could borrow?
:)
>

>
----------------------------------------------------------------------------
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Libnifalcon-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libnifalcon-devel
>
>

----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libnifalcon-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libnifalcon-devel

 

I'm honestly not sure. I think the grips have some sort of identification
with the firmware (since I /think/ they released a firmware update when the
pistol grip came out, for example, but I may be making that up). I might try
shorting things and seeing what happens though. My grip arrives saturday
morning otherwise, which just means I have 5 days to work on other things.
:)

Kyle

On Mon, Nov 2, 2009 at 3:42 PM, Stephen Sinclair <rad...@gm...>wrote:

> Yikes, maybe you could short two of the grip connections using a wire?
>
> Steve
>
>
> On Sat, Oct 31, 2009 at 2:06 PM, Kyle Machulis <ky...@no...>
> wrote:
> > So, I'm in Vienna, Austria for the next 5 weeks as part of an artist
> > residency. Just started unpacking all of my hardware here, and realized
> that
> > when I disassembled my falcon, I forgot to throw the grip in with it,
> making
> > me pretty dead in the water since the falcon won't communicate without a
> > grip. Now, I can get one next week when another friend comes into town
> that
> > can bring the one I forgot with them, but I was wondering if anyone on
> the
> > list here is in Vienna and happens to have an extra grip I could borrow?
> :)
> >
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Libnifalcon-devel mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libnifalcon-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Libnifalcon-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libnifalcon-devel
>

Yikes, maybe you could short two of the grip connections using a wire?

Steve


On Sat, Oct 31, 2009 at 2:06 PM, Kyle Machulis <ky...@no...> wrote:
> So, I'm in Vienna, Austria for the next 5 weeks as part of an artist
> residency. Just started unpacking all of my hardware here, and realized that
> when I disassembled my falcon, I forgot to throw the grip in with it, making
> me pretty dead in the water since the falcon won't communicate without a
> grip. Now, I can get one next week when another friend comes into town that
> can bring the one I forgot with them, but I was wondering if anyone on the
> list here is in Vienna and happens to have an extra grip I could borrow? :)
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Libnifalcon-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libnifalcon-devel
>
>

So, I'm in Vienna, Austria for the next 5 weeks as part of an artist
residency. Just started unpacking all of my hardware here, and realized that
when I disassembled my falcon, I forgot to throw the grip in with it, making
me pretty dead in the water since the falcon won't communicate without a
grip. Now, I can get one next week when another friend comes into town that
can bring the one I forgot with them, but I was wondering if anyone on the
list here is in Vienna and happens to have an extra grip I could borrow? :)

It appears that gravity compensation can be added to the device:

http://libralis.dii.unisi.it/

Calibration requires a win32 system but the the .dat file produced  
could be used in libnifalcon with some work (I think).

I spent a lot of time this weekend working on np_nifalcon, the falcon
external for Max and PureData. It's now much more stable, and has a few more
customizable features.

https://sourceforge.net/projects/libnifalcon/files/libnifalcon%20Max_Pd%20External/1.5/

I've currently posted source code, and binaries for Mac OS X 10.5 Intel for
Pd-extended 0.41.4 and Max 5. I'll also try to get windows builds of these
together soon. If anyone needs builds for any other OS or version and
doesn't have the means to do it themselves (flext building is a little odd),
send me email and I'll see what I can do.

libnifalcon v1.0.1 is out. Available at:

https://sourceforge.net/projects/libnifalcon/files/

This is pretty much a bug-fix release to get multiple falcon access working
again. It's really only been tested with 2 falcons at the moment, but I
don't see why it wouldn't work with any number, limited only by computing
power.

Change list:

    * Fixed bug with connecting to/using multiple falcons using libusb
communications
    * Added adjusted geometry measurements by Niall Begley
    * Fixed bug with reloading firmware through reused FalconDevice object
    * Added ability to test multiple falcons to findfalcons
    * Added findfalcons_multi example to test multiple falcons with
simultanious access

I pushed fixes to a few major bugs today:

- libusb wasn't being passed the object's libusb_context object when
polling, meaning having more than one device object never worked.
- libusb now allocations transfers at the time of transfer, versus trying to
allocate two transfers ever and only use those (caused random lockups)
- Successful read counts were never being reset on firmware loading, meaning
trying to load firmware multiple times to the same object did weird things
- Reversed the updated r/s values in FalconGeometry from nia11.
- findfalcons now iterates through all available falcons and tests them.
- added findfalcons_multi for testing having multiple falcons open and
running at once

I'm going to keep testing on these and probably release v1.0.1 on Sunday,
since it's not possible to use multiple falcons on a non-windows system with
v1.0.0. :)

Kyle

http://www.youtube.com/watch?v=mVm1kYulHnE

Neat video of integration with the Blender Game Engine and HAPI using
libnifalcon for cross platform access. :D

One of the things I skipped when released libnifalcon v1.0 was testing, of
pretty much any rigorous kind. So, I'd expect that we're going to start
seeing a lot of point releases from here on out. :)

I was notified this week that using libnifalcon with libusb on multiple
falcons wasn't working correctly. Sure enough, I was being a little too
fancy with my read/write transfer allocations in the libusb core, trying to
operate using 2 transfers, ever, period, and just refilling them as needed.
This seems to cause issues when trying to use multiple falcons, or when
closing and reopening a falcon device in the same process. I've got the
allocation part fixed, but will be continuing to test for a bit to make sure
it's solid this time around. Expect v1.0.1 out this weekend. :)

My god. It's done. It's actually done. libnifalcon v1.0 is out.

https://sourceforge.net/projects/libnifalcon/files/libnifalcon/1.0/libnifalcon-1.0.tar.gz/download

I spent all day writing up doxygen comments, and the software now has
something almost maybe resembling a manual.

http://docs.nonpolynomial.com/libnifalcon/devel/doxygen/html/

I also pulled back some of the comm library changes. libftdi is still gone,
and I still compile one of the comm behaviors directly into libnifalcon now
(versus having outside comm libraries), but the header for whatever comm lib
your platform uses is still distributed, so your pre libnifalcon-1.0 code
may still work. :)

Off to update blogs and start work on the next release of the pd/max
externals.

Kyle

Ok, just merged kill-libftdi back into release-merge. The libftd2xx and
libusb classes are still the same, but are no longer exposed to the
developer in the API. The FalconDevice object creates a comm type on
construction. This comm type is decided on at the time of libnifalcon
compilation. This creates an extra dependency from the core library, but I'm
not really all that worried about that at this point.

Now, if someone /really/ wants to set up their own comm core, they still
can, by compiling in their own library with a class derived from FalconComm
and using the setFalconComm function to create a new device behavior of that
type. I'm going to be really surprised if anyone finds a decent reason to do
that though (I have a FalconCommNetwork core that I was thinking about doing
for device simulation for testing kinematics, but I'm not sure how much
that's needed). :)

Anyways, this means no more weird #if'ing for LIBUSB or LIBFTD2XX or
whatever for comm library includes and behavior settings. The communications
are now just rolled into the core library. Much simpler, and hopefully won't
be too much code for everyone else to change (I'll handle the H3D patch
before I release v1.0).

I also moved falcon_mouse back into the examples. Dunno why I ever moved
that out to its own repo in the first place.

On to cleaning up documentation,
Kyle

Ok. I've had it with trying to maintain multiple comm cores. libftdi is just
getting in the way, and libusb-1.0 works everywhere that ftd2xx doesn't now.
Trying to maintain all of the library choices is just silly at this point
(and is one of the worst problems with developing with libnifalcon in my
opinion, since you have to pay attention to which core you're using for
include files, have to deal with preprocesor defines, etc...), so here's the
plan:

- Remove libftdi completely
- Remove all non-polling comm logic blocks
- Remove the ability to work with multiple comm cores per libnifalcon
install, default to ftd2xx on windows, libusb on os x and linux with build
option for switching to ftd2xx
- Remove all comm defines from code and only compile one core

This is all happening over in the kill-libftdi branch. I should have it done
this evening, at which point it'll merge back into the 'release-merge'
branch, which currently contains

- barrow_mechanics - Alastair Barrow's fixes to the RL Stamper kinematics
system
- new_build_system - My updates to the project using the CompilyBuildd
system (my own set of scripts for dealing with quick and easy cross platform
development in cmake).
- default_device - Pyplusplus and SWIG bindings to the FalconDeviceBridge
proxy class

After kill-libftdi comes in and I decide that's all I'm gonna do, I'm
planning on bringing other projects (mouse support, Pd/Max external, etc...)
in line with it and pushing the whole thing as the v1.0 release. I just want
to make sure I have things in a state I'll be happy with for a while (and
that won't require code breaking API changes) before going to v1.0.

I've been creating a few new branches lately on the libnifalcon github repo,
with lots of exciting new features:

- barrow_kinematics: Alastair Barrow sent me a new implementation of the RL
Stamper kinematics system this week. It fixes quite a few of the bugs we
were experiencing in the old implementation, while also being a lot less
complex, source-wise. I'm just going to do an in-place switch of the
systems, no outside should need to be changed. Things will just be a lot
more stable. This is mostly done, just needs a little cleanup and
commenting.

- default-device: This branch is rather oddly named for what it turned into.
I finally decided to take the leap into supporting other languages on top of
libnifalcon. The first try is python by way of boost::python and
pyplusplus/pygccxml. This happening by way of a new FalconDeviceDefault
class, which will be changing names to something like "FalconDeviceBridge"
before I merge back in, because default doesn't make much sense. I'm
basically trying to distill down libnifalcon to a single class, derived from
FalconDevice, that removes templates (hence the 'default', it sets the comm
core, kinematics, firmware, and grip behaviors), can run communication,
allow for access to raw input and output (for building kinematics or other
low level interaction in other languages), and also allow usage of the C++
kinematics cores if need be. I got most of this done and checked in today,
and have all of the test in falcon_test_cli running at full speed in python
now. The next goal is building FalconDeviceWhateverIEndUpCallingIt under
SWIG so I can get Ruby and Java going. I'm honestly not sure why anyone
wants direct device access in those languages versus going through an
engine, but I get a lot of requests for them, so I figure if it's not much
work, I'll give it a shot. If anyone has any advice on SWIG, I'm happy to
take it, though I'm hoping it'll just be a case of having to do an include
on the header, and that's it.

- new-build-system: This is more for me than anyone else. Been doing a lot
of work on the build system lately to make it more large project friendly
(started using it at my day job and they're letting me take everything I've
developed there back into my own projects :D ), so I'm working on bringing
all of my projects in line with that.

Once all of these are done, I'll merge them down to master and throw another
email out on the list. Depending on how much testing they get, and how much
documentation I get done, this will either end up as beta 5, or I may just
roll the whole thing as v1.0 and be done with it. I don't really have any
testing in place at the moment, and I'm not sure how much testing happens
per release, and I'd really like to get out of the v1 release period I've
been in for... 11 months now.

BTW, you may've noticed, sourceforge completely yanked the wiki, so all of
the links that used to go to it lead nowhere now. I'm trying to replicate
that information elsewhere, but it's slow going for the moment. I hate
sourceforge so much at the moment, but hopefully we'll be mostly free of
them (outside of file releases, though I'd LOVE to find a different place to
release as sourceforge has been completely unreliable for 2+ months now, and
this mailing list, which I'm debating moving to google groups) soon.

Kyle

http://www.edgegamers.org/forums/showthread.php?t=95178

Or, just go to their store and use the coupon code EGO22

I've been playing with the falcon and H3D with the new libnifalcon device
node this week, things are coming along pretty well. :D

Hi All!

 

Thanks for all your good work on the libnifalcon project. I just wanted
to announce that the main development branch of H3D API and HAPI
(www.h3d.org) now includes support for using the libnifalcon library to
communicate with Novint Falcon devices. If you try it out please report
any issues back to us so we make sure that it is used in the best
possible way.

 

Regards,

Daniel Evestedt

 

Lead Developer

SenseGraphics AB

www.sensegraphics.com

Well, Sourceforge said they were getting rid of stuff, but they certainly
aren't giving much prior notice. They're removing wikispaces tomorrow, which
means the libnifalcon wiki will disappear. I think a decent amount of the
information has been reflected onto the new website at
http://libnifalcon.nonpolynomial.com, but I haven't gotten nearly as far I
was hoping with transfering the information into asciidoc format.

I'll be exporting the wiki and continuing work on the documentation transfer
at some point, just wanted to give a heads up.

Kyle

So, I've been doing more playing with force generation, and I've managed to
better isolate the issues with forces. Ally Barrow (who I believe is on this
list, but I'm too lazy to go check :) ) has been a great help with these so
far, but I figured I'd throw out one of the other problems I've found this
weekend, and that I know others have experienced. I'm working on this right
now, but figured I'd see if anyone else had any ideas.

---

When using the x-wall and y-wall tests, forcing the effector into the area
behind the barrier region causes different events depending on the sign of
the force the barrier region is producing. For instance, if using the x-wall
test, pushing the effector into the barrier region when it is to the right
(positive direction on the x-axis), the force output of the barrier region
is to the left (negative direction on the x-axis), and the program produces
the expected result, that no matter where the effector is in the barrier
region, it feels like it is being pushed back toward the left. When this
situation is reversed, and the end effector is being pushed toward the left
(negative), the barrier region seems to react with some correct force
(positive) while the effector is near the barrier region border. If the
effector is pushed farther into the region, the forces seem very wrong,
actually pulling the effector farther in.

The force calculation for each barrier region with the wall test is the
same, the signs just end up being switched depending on which direction
you're going. This bug exists somewhere in the calculation of the joint
forces based on the cartesian forces, most likely jacobian calculation.
---

Hope that made sense. :)

The issue tracking is at:

http://github.com/qdot/libnifalcon/issues/#issue/3

Also: Wow, Sourceforge did a MAJOR site overhaul without really warning
anyone. I knew that were going to start switching out utilities and
programs, but the whole front page changing this week was a bit of a shock.
I'm getting LOTS of 500's off the site now, and am trying to step up getting
all the information moved from SF to the standalone website. If you have any
problems or need anything that has disappeared, just poke me.

Yeah, i liked the icon too.

having not touch a falcon all year i'm planning to be working with one again
from next month and looking forward to using the latest libnifalcon.

great to see the project doing so well, a year on from when i first looked
at it.

Liam


On 5/27/09, Stephen Sinclair <rad...@gm...> wrote:
>
> Nice!  Like the icon.
>
> Steve
>
>
>
> On Wed, May 27, 2009 at 2:16 AM, Kyle Machulis <ky...@no...>
> wrote:
> > http://qdot.github.com/libnifalcon/
> >
> > Gave jekyll on github a shot, it's worked out really well. libnifalcon
> now
> > has a nice web page, and a new logo for the software. I'll be trying to
> > update this pretty often as development progresses, and as I get
> information
> > about projects using the software. I'm still working on the documentation
> > section, too.
> >
>
> >
> ------------------------------------------------------------------------------
> > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> > is a gathering of tech-side developers & brand creativity professionals.
> > Meet
> > the minds behind Google Creative Lab, Visual Complexity, Processing, &
> > iPhoneDevCamp as they present alongside digital heavyweights like
> Barbarian
> > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> > _______________________________________________
> > Libnifalcon-devel mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libnifalcon-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Libnifalcon-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libnifalcon-devel
>