FloatMatrix doesn't compile in the patch library

OWL
, ,
#1

I was trying to use FloatMatrix last night, but when compiling using the patch library on the website I got an error about missing definitions for the FloatMatrix class. Only including the header when compiling works, so it seems like the file does exist in the compilation environment, but maybe the cpp file is not compiled?

Not sure if related, but I found that when I got the FloatMatrix compilation errors, I also got a warning about using SineOscillator::getNextSample, which it reported as deprecated and to use generate instead, which doesn’t exist for SineOscillator in the OwlProgram repo on the master branch.

#2

OwlProgram has received a pretty big refactoring a few months ago, some less common things might have ended up broken. And it looks like not all fixes have been merged to master branch yet, so you should stick to development branch for writing code. I’m sure that @mars would certainly fix master branch soon and update web patcher.

Also, I’m really curious what are you planning to do with those matrices!

#3

Ok, cool, I will switch to develop locally so I can see what’s up. But yeah good to know the website runs off develop and not master.

Part of a patch I’m working on involves rotating 3D points, so I wanted to see if using FloatMatrix would be more performant than the code I’ve written. Although I’m just assuming the Lich is ARM Cortex and can take advantage of that.

The patch will be public soon and I’ll post it here :slight_smile:

1 Like
#4

I didn’t say that site uses development branch, merely suggested to use it locally until everything is fixed there.

Yeah, OWL uses vendor-provided optimized code for ARM from CMSIS library. But it’s also true that Cortex-M MCUs don’t have something like vector instructions (Neon) that would actually provide performance boost in hardware. So it’s absolutely possible to reach the same speed in hand-written normal C++ code. This is the ARM library code for reference - https://github.com/pingdynasty/OwlProgram/tree/develop/Libraries/CMSIS/DSP_Lib/Source/MatrixFunctions

#5

Hi @damikyu,

I’m excited to see what you will do with this!
I think you are right, that FloatMatrix.cpp is missing in the sources list, and I’m afraid this is still the case with current develop branch. I’ll fix it up in a PR and deploy to the website to test, I’ll just have to take care of some other changes first.

And yes, the website has had develop or even feature branches deployed lately, in order to roll out and test new features a bit faster.

Finally regarding Cortex optimisations, it’s true there’s no NEON support but the cores have some SIMD features, so that 16-bit and 8-bit data can be processed 2 or 4 at a time. The CMSIS libs (which we take advantage of e.g. in the FloatArray and FloatMatrix classes) leverage this, but for floats SIMD doesn’t make any difference. However we still find the optimised functions tend to run a bit faster, probably thanks to loop unwinding and making the most of the many float registers. Other functions like sin, cos and FFTs use table lookups, and they perform great regardless of data type.

#6

Thanks for the additional info @antisvin and @mars. In looking at the CMSIS source I’m not sure that FloatMatrix will be faster than my in-place code, but I’m curious to try it. I think for the rotation code most of my cycles are going to setting up the matrix with sin and cos calls. The patch in general utilizes sin and cos heavily with CPU hovering around 68%, which seems pretty good to me!

#7

You should consider if your patch requires that matrix to be updated once per sample or per audio block. If rotational vector position is updated by patch parameters, then it can be changed once per audio block and you don’t need to update it more frequently (unless you’re applying smoothing to those parameter values). That’s generally should be considered for other parts of your patch as well. And for devices with display some things can computed with even slower sampling rate (once every 20 ms from display update callback).

Second obvious optimization for C++ patches is to use block-based function calls when available. That’s not related to matrices as they don’t support that, but you may be using something that supports block based calls in other parts of the patch.

It was one of the major goals of the recent library refactoring to add based classes for processing arrays or sample buffers and to convert various parts of the library to have the same conventions. This is done with process() and generate() calls. Now I wonder if we need to add some classes that to support the most common 3D operations. Martin was doing it with hand-written code before - for rendering Lorenz atttractor’s projection on display for one of the demo patches on Magus.

#8

Hi @damikyu, if you are compiling offline then this PR, or branch feature/synth-updates, should fix the problem with linking patches with FloatMatrix.
Should be deployed on the live server in the next few days.

#9

Yeah, I do have direct rotation control on one of the parameters and when I tried updating rotation once per-block it introduced some light sizzle to the sound, so my current implementation calculates rotation per-sample and smooths the direct rotation control parameters.

1 Like