How can I use libraries like “Midi Library” by Forty Seven Effects?
I can’t tell what the gcc include paths are, though it looks like only /opt/XOD IDE/resources/arduino-libraries (on linux).
So, my native node has
#include <MIDI.h>
which, of course, can’t be found.
(xod-client 0.16.0, linux ubuntu 14.04)
Hello!
Yes, that’s a problem. XOD can’t hook up external libraries yet. The very ugly but technically possible ways right now:
/path/to/ide/resources/arduino-libraries and ask library consumers to do the same*.h and *.cpp files of the library and paste the sheet right into patch.cpp 
An adequate solution to the problem is yet to be found and implemented and it would be interesting to hear your opinion. The draft variants are:
-Include directories of all XOD libraries (projects). So one could a required library at the root of his project or a well-known subdirectory (e.g. __code__)The former approach potentially leads to *.xodball bloat, conflicts and duplication across libraries, however, it allows the ad-hoc creation of C++ libraries solely for XOD. The latter approach is a bit harder to understand for a newcomer, but more concise.
Both ways would deprive us the pipeline: Show code for Arduino → Copy/Paste to Arduino IDE → Compile/Upload there. And that’s not great.
Treat the Arduino-IDE library location as a standard. “-I” that (e.g. on linux ~/Arduino/libraries). XOD could implement the mechanism to manage “arduino” libraries, but we have a fallback to the arduino-ide. Now XOD and Arduino-IDE share. This preserves the Show-Code->past-to-arduino-ide.
In libraries, it would be nice to develop native nodes that have multiple files, or that use some pre-written .cpp/.h files. On the XOD side, just “-I” the appropriate __lib__'s (someone should think about file-name collisions…). Obviously that can break the copy-to-arduino-ide thing. How important is that? How about generating a valid arduino-ide “project” instead?
xodball… I haven’t thought about the use-case for these. “package up a project to send to someone”? I don’t see how it affects that: a xodball doesn’t include all the library patches does it? I’m assuming that foreign libraries tend to belong to a xod library (or are #1’s).
foreign libraries in a project (or extra .h/.cpp’s). Seems like “-I” for your project would do the right thing. xodball would grab the whole project directory, and that seems to make sense.
So, a package manager? 
At least use a distributed (p2p) store (tahoe-lafs, ipfs), and don’t tie yourself too much to git. 
And, since you are doing that, let users use it to share projects (using git etc.). 
Thanks!
Well, it would work to some extent. One of the targets we’re trying to achieve is zero-hassle libraries sharing. So if a library (say, awgrover/midi) uses a MIDI Arduino library that shouldn’t cause any additional steps to be required for a xoder who wants to install it.
It’s harder to explain that one should (a) install the XOD library and then (b) install the Arduino library.
Here’s yet another idea… What if we will introduce a #pragma directive to define Arduino library dependency?
#pragma XOD require "https://github.com/FortySevenEffects/arduino_midi_library"
// ...
void evaluate(Context ctx) {
// ...
}
Then at build step, we could scan for dependencies and download them automatically. This way we:
#pragma is ignored by a compilerWhat do you think?
Interesting, will read more about them
Hi there - did you make any progress on how to implement foreign libraries into XOD?
Best Tobias
Oh, can’t believe eight months past since the beginning of this topic. The related issue is on GitHub already (#1218) and we plan to implement it 0.24.0 or 0.25.0.
Finally, it solved in the 0.24.0 