How do you develop your C/C++ based algorithms?

Audio Plugins
1

Hi JUCE community,

I hope that I created this topic in the right category. If not please let know as it is my first topic in the JUCE forum. :slight_smile:

I would like to discuss with all of you how you develop your audio signal processing algorithms with C/C++. As I will be the author of this thread I will start to discribe my workflow.
Most of the time I started with a protoype in Python or a MATLAB environment. If everything seems to work I ported the code to C++ objects because I now will have the possibility to integrate the developed algorithm into the most famous environments like JUCE or any other audio plugin. As I really like to watch movies with Kodi I started to join this open source community and integrated my work there.
Very soon I noticed, I have to verify that the code base from my prototype is working in the same way as my C++ implementation.
This was the reason why I started some research to find a solution. I stumbled across shared libraries, MEX files and other similar integrations for scripting languages. But to be honest it requires some effort to get everything working and to me it seems not very intuitive for rapid prototyping your idea. Most of the I somehow lost my focus and worked more in the area of tooling instead of developing my algorithms. Consequently I say there isn’t a real solution, which would suit me requirements to quickly analyze or test my C/C++ based algorithms.
What tools or workflows do you use? It really feels like that a C/C++ signal processing code base is hard to debug or to test with the tools on the market.
This was the reason why I started to write my own tool which hopefully will close this gap. This topic isn’t to advertise my tool but I’m open to discussions as well. What I would really like to discuss is your workflows or tools you use. I’m also thinking about a JUCE integration but I don’t know if you would be interested.

I’m looking forward to interesting discussions.

2

Good question! I too have been trying to find a workflow that works well.

After several iterations, my approach moving forward will likely be a JUCE Shared Library project which wraps my DSP nodes with Boost.Python (https://www.boost.org/doc/libs/1_67_0/libs/python/doc/html/tutorial/tutorial/exposing.html) so that I can more easily use the vast set of scientific tools in Python (NumPy, SciPy, Matplotlib, etc) to verify and measure behavior.

Then for my audio applications or plugins I’ll use git submodules/subtrees for including that work in my project.

1 Like
3

When it comes to VST plugins, Matlab’s capability of hosting VST plug-in comes in quite handy when comparing prototype code (Matlab) with the product code (VST). But it would be way better if they would render the GUI :slight_smile:

2 Likes
4

I used to have the same problems that you described when porting my code into C++. Errors were accidentally introduced that were extremely difficult to track down. So, my solution was to create my own simple environment in C++ that I would then re-use for all my tests. If I need new tools or features, I just develop them myself.

1 Like
5

I start by prototyping them in Python, then I have the unit tests, then I do the C++ implementation, wrapped with pybind11 (because Boost.Python is…). And everything fits properly in my pipeline workflow.

3 Likes
6

This is my workflow too. Other helpful things are the signal processing module in scipy and matplotlib.

2 Likes
7

Basically, most of people uses one of those :

  • MATLAB / Sci-Lab / Octave
  • Python
  • Faust
  • Small test apps / plug-ins directly in C++
1 Like
8

Hi guys,

thank you for sharing your current workflows! Reading your responses makes me very happy and sad at the same time. Because on the one hand the current available tools seem not to be powerful enough for large scale projects or quick development cycles. On the other hand we seem to solve the same problems in slightly different ways. We all want to develop C/C++ signal processing algorithms and need the help of the analyzation tools from scripting language environments. This really reduces the effort for analyzation tool development.
Furthermore we also need to develop a custom UI for plugins. This topic is way different then algorithm development, which I guess should be focused in a other topic. At first I will try to solve the signal processing section. :wink: But I fully agree that it would be cool if Mathworks would render the full UI, so we wouldn’t have to switch between environments.

Furthermore I really hoped that you would have a killer tool, which I didn’t know yet. :slight_smile:

My next questions are:

  1. Are you happy with the current workflow/tooling you use?
  2. What do you miss in your current workflow/tooling?
  3. Would you be interested in generalizing the workflow/tooling you currently use?
  4. Are you using unit tests for your signal processing algorithms?
9

Haha, Mathworks doing something that makes sense, don’t count on it. They are going down, just like Mathematica does.

SO, yes, very happy with my workflow, nothing missing, and no need to generalize by workflow, it’s already freely available for everyone to use and unit tested.

10

You’re right! I definitely don’t count on mathworks. In my view they missed to implement a lot of features for C/C++ developers. E.g. generating C/C++ code of m-files or simulink model is awesome but they don’t provide a easy to setup method to integrate the generated code again into MATLAB.