I have a VS2010 project which is a windows application that acquires data from a particular bluetooth device. All I want to do is alter my acquisition thread to send the data it acquires using OSC.
I spent a long time trying to use a library called LIBLO but it appears to function using POSIX style asynchronicity. I spent even more time trying to make pthreads-win32 work for me so that I could still use this library but still had no luck.
I switched to trying to use the OSCPACK library which I could not get to compile using the batch file included in the release. I was eventually able to get my VS2010 project to recognise the library but all I get now are linker errors (LNK2019 and LNK2001). The relevant directories are listed in “Additional Include Directories” in the project properties. I know this should be something easy to fix but after a day of frustration I am at my wits’ end. I am used to working with xcode in osx so find it difficult to accomplish anything in VS2010. Do I need to give additional instructions to the linker?
can anyone either suggest a simple, prebuilt OSC library compatible with windows/VS or how I can fix my problem with unresolved externals?
OSC is a very simple protocol, especially if you only need to send outgoing OSC messages and don’t care about receiving (and parsing) incoming OSC messages. One thing you can do is simply read the spec and look at some examples and write your own function that adds OSC data into a byte buffer in the prescribed format. That’s only a few hours of work to do. Then it’s just a matter of sending that char buffer out over a UDP socket, which is also quite straightforward to do. Depending on your needs, that might be easier that trying to integrate with a third-party OSC library (which I agree can be frustrating, especially under Windows).
Another possibility is to use OSCPACK, but instead of trying to build it separately and then link to the resulting DLL/LIB file, simply copy the necessary OSCPACK .c files directly into your own project’s source tree and compile them in to your executable the same way you compile your own code. That will avoid any annoying build/link issues that can come with trying to get two different build systems to work together, and it also gives you full control over your (bastard) copy of the OSC code… e.g. if you want a particular function in OSCPACK to work differently, you can simply modify your copy of that function. (If you do that, be sure to make it obvious that the code is no longer ‘stock’, to avoid confusion… and of course try not to modify it in such a way as to break protocol compatibility with other OSC-using software)