C++ help for the unexperienced

OWL
#1

I’m on my second day with my owl and now I want to go into uncharted territory and start writing patches in C++.
First of all I need to get compiling.
I got it working with gen-patches no problem, and already got some good sound out of the module.

If I just copy the text of a .hpp file downloaded from the patch library and try to save it as a new .hpp-file, it wont compile. Someone else here on the forum posted a while back of the same problem, but then realized that he hadn’t done the “preprocessor-thing”.
And here I must admit, that I kinda know of preprocessors, but yes, I don’t really know what it is.
Can anyone explain to me how to use a preprocessor on my .hpp-files, so i can start compiling my own files?

Here is the online compiler error:

Patch Compilation Failed
StdoutStderr
/tmp/owl/owl-build-NsOkun/registerpatch.cpp: In function 'void setup(ProgramVector*)': 
/tmp/owl/owl-build-NsOkun/registerpatch.cpp:1:16: error: 'gaintest' does not name a type 
REGISTER_PATCH(gaintest, "untitled-tetestest", 2, 2); ^ ./Source/PatchProgram.cpp:45:73: note: in 
definition of macro 'REGISTER_PATCH' #define REGISTER_PATCH(T, STR, IN, OUT) 
registerPatch(STR, IN, OUT, new T) ^ make[1]: *** [/tmp/owl/owl-build-NsOkun/PatchProgram.o] 
Error 1 make: *** [patch] Error 2 ERROR: Patch build failed.
#2

I think I got it. Everything has to be named the same. Filename, patchname, #ifndef #define and so on names has to match for the preprocessor to figure it out.
Hopefully someone else in the future who as trying their first steps with C++ on the owl will find this, and not make the same mistake as me :slight_smile:

I’ll probably soon call out for help, when I encounter my next problem

1 Like
#3

Yes that’s right - and yes we should improve the docs for this!

1 Like
#4

It’s working great now and I’m well into writing some patches based on your fft-patch.
C++ isn’t so scary after all. The owl seems to be a great way to start learning c++ for dsp.

Is there any offline -compiler for Mac? And maybe more important, documentation :slight_smile: ? I’m not scared of using terminal and command line tools…

#5

:+1: that’s great!

The offline compiler is here: GitHub - pingdynasty/OwlProgram: Dynamically loaded OWL program
Have a look at the readme. OwlProgram requires separate installation of a number of prerequisites and has a bit of a steep learning curve.

There might be an easier way if you fancy trying out @bfabricius Docker image:

1 Like
#6

HI @andersskibsted,

Good to hear that you’re getting into hacking with the OWL. As Martin mentioned, I was looking for a way to easily compile and loading patches to the OWL from any machine without immediate need of uploading them to use the online compiler.
My idea with Howl is to have kind of a wrapper around OwlProgram that makes it easier for anybody to get up and running without having to get into all the intrinsics of how to get OwlProgram to run. Check out the mentioned thread to get and idea of whats currently going on with Howl and feel free to leave any feedback or your thoughts in the thread. Im keen to get as much feedback on how people would want to use something like this as possible.
Once i make Howl available for testing, there will be enough documentation to get up and running, maybe as time proceeds we can also add something like a quick start guide on how to use howl to compile cpp, pd, faust and gen patches. This quick start could also touch on typical cpp patch trip-wire stuff like naming, includes, preprocessor directives etc.

Good luck with your patching.

Cheers,
Ben

#7

Thanks.
I’m still doing simple stuff, but I will definitely take notes on which obvious problems i run into that could have been avoided with a sort of quickstart guide, for example the naming, so we could include it, for potential new users to get up and running quickly.

1 Like
#8

making progress and brushing up on my fourier transform-math…
But is there really now “easy” way to acces the phase part of a ComplexFloatArray the way there is with the magnitudes like getMagnitudes(…) ?
I tried with a for-loop and arctan and so on, but it seems like it is very cpu-heavy…

bins.getImaginaryValues(img);
bins.getRealValues(rea);
for (int q = 0; q<=blocksize; ++q) {
phase[q] = atan(img[q]/rea[q]);
}

Does anyone now of an easier, and most important a less cpu-hungry, way to do this?
Is it because I have to go hunting in the CSMIS-DSP library?

#9

There isn’t one in CMSIS unfortunately, though it’s been suggested many times: Calculate the phase of a complex number · Issue #293 · ARM-software/CMSIS_5 · GitHub
You could try using our fast_atan2f(y, x) which is based on https://dspguru.com/dsp/tricks/fixed-point-atan2-with-self-normalization/
I’ve not tested it for performance and precision so let us know if you use it! If it’s any good we should roll a getPhase(...) method into FloatArray.

BTW what are you working on? It sounds interesting!

#10

Ok I’ll try that. It seems that magnitude is so well covered but phase wasn’t…
I’ll look into and I’ll try and make something useful.

I’m just messing around with your fftthrough patch.
My c+±skills is still not very good but I’m slowly advancing.
I’ve been looking into the spectral-/phase vocoder-modes source code from MI clouds and see if I can implement some of the functions but with more detailed control.
I’ll share if I get something good coded up.

Btw. When I use your fft-patches I always get a lot frequencies present around the base-frequency of the fft and therefore a quite loud sinein the bottom. That of course goes lower as the blocksize and fft size increases… but is the best solution just to throw out the first few bins of my magnitude spectrum?
The fft through and spectral shift has been very helpful!