I have been learning a bit about Flucoma and the max help and example patches have me interested in integrating some of the c++ code into open frameworks.
Cheers!
Hello!
I’m sure @weefuzzy will reply with more details, but it has been my ambition to try that next year… but the code is coming soon on GitHub and looking at the structure of the code could allow you tap into it at different level before I do so…
Hi @bafonso!
No-one’s attempted this yet, no; I’m not an Ofx user, so I’ve not really much of an idea how folks would expect feature extractors and the like to be used in that context. However, because it’s still C++, you’d have the option (once you have the source…) of using the algorithms’ code directly: for making the Max/SC/PD/CLI stuff we have quite a lot of template goo which is probably not as useful in this context.
Really soon 
In any case, we’d be delighted if someone started to investigate this, and happy to support where we can.
Hey @weefuzzy! Thanks for your reply. Yes, my idea was to incorporate the c++ code into ofx. I am mostly interested in avoiding reinventing the wheel as far as audio analysis goes. I have a couple of projects where the visual mangling has been developed and I am now looking forward to modulating it using audio hence my interest in flucoma. Being c++ I thought it would be a great potential fit that and working with a modern c++ library instead of aggregating or rewriting code for common analysis.
Always in favour of not reinventing wheels! In that spirit, it might also be worth checking out the Maximillian project if you don’t already know it: it’s a mature codebase, with some ofx audio analysis examples included.
One of its maintainers, @m.zbyszynski, might be listening and have some shareable wisdom about ofx and audio…
I was also wondering about using Flucoma in c++.
Maximilian has an openFrameworks module, which I use to teach. It can also run on its own. JUCE integration might be another interesting area.
Watching this thread.
Will you share your discovery here? I really hope this place will be a space to discuss this kind of integration independent of implementation, so using any toolset is for me less important than the musicianly (ab)uses you’ll make of them all… and I’m also a part-time oF person like so many of us here 
This is definitely a design goal: I guess we’ll find out how well it works out once people have the code and can start hacking. This explanation will make more sense once you can actually see the code base, but there are three broad layers:
Algorithms: do the actual number crunchingClients: aggregate algorithms and define parameters / interfaceHosts: use template magic to emit the appropriate glue that manifests a client in a given environment (Max, SC, PD etc.)The general idea is that the algorithms layer should be useful as an API in its own right. What comes out of the clients is currently more geared to being easy for machines to deal with via template goo than towards being a human-friendly API.
From my limited ofx-understanding, it looks like using the algorithms directly would work well enough for ofx, because it doesn’t seem to have especially strong expectations about the form that classes take. JUCE is closer to being a host in the same sense as Max etc., and it will be interesting to see how well their inheritance based model can be made to jive with our clients.
I suspect that in both cases we’ll discover room for improvement 
What about compilation to things like shared libraries? Not sure to extent these kinds of things are on your mind, but with an option to compile algorithms to shared libraries they could be pulled into a number of environments easily as you are likely aware. Of course I am thinking of immediately making a decent python wrapper with support for passing and receiving numpy arrays that are then easily written to audio files or then transpiled to music on the blockchain.
Our code is header only, precisely so that people can use it directly from C++ without the need to talk to pre-compiled stuff. If you wanted to make python bindings (which I gather is a special kind of fun), you could just include the headers and have at it.
Generally, there are wrinkles with exposing C++ APIs through shared libs, because there’s no built-in guarantee of binary interface compatibility between compilers or versions of the standard (e.g. a program compiled with X might not be able to lookup C++ symbols in shared lib compiled with Y). This is one reason why shared APIs are so often C interfaces, because this issue doesn’t arise. IOW, if you wanted to do this sort of thing, in general, you’d probably end up making a C-style interface to export. (Cases in point are both the Max and SC APIs, which are C interfaces to C++ code bases)
Okay that is enlightening. I have never had to make Python bindings, but have dabbled in shared libraries to get the speed of a compiled lang with the simple grammar of Python to do calls and setup logic. When the code gets released, I’ll try have to have some fun with the headers.
I recently came across using c++ code from python (processing audio files using VST plugins using c++ with python to generate different “presets”). One project used boost.python and another was using swig but claimed issues and was not working. Apparently another option is Cython. This stack overflow post has a good list of options with these 3 at the top. I did not find terribly hard to understand how boost.python worked and going from c++ std::vector to numpy seems fairly straightforward. As far as speed goes, I believe most python people use Cython to embed c++ optimized algorithms. I look forward to the Github repo unveiling
Yes I ran into Maximillian a few weeks ago. I was hoping to use flucoma’s extended audio analysis though 
Yes, this is what I had in mind, basically feeding raw audio into flucoma’s objects, potentially running it in a separate thread. I am guessing flucoma’s processing is based on buffers of double or float arrays , similar to juce, Maximillian or ofx, where mainly you are given a pointer (or an object keeping track of this) to a buffer array.
