No luck compiling pd Patches, they always consume 200+ % cpu

[cosmono]

Hi there!

I'm just getting my hands dirty uploading pd patches but got stuck trying to get them to work on the owl. Whenever I compile a patch (I just downloaded working patches from the library like "Granular Delay" or "Cloud Delay") they compile with this output:

stdout:

Building patch expressive granular delay e[93mWarning:e[0m The release "r2017.01" expired on 2017-07-31. It may be removed at any time! Job URL: https://enzienaudio.com/h/owl/owl/1787 Heavy release: r2017.01 Downloaded files placed in: * c-src: /tmp/owl/owl-build-Xcmxep/Source Total request time: 1361ms Built sysex expressive granular delay in /tmp/owl/owl-build-Xcmxep/patch.syx INFO: make exit code is 0. INFO: Build successful!

stderr:

warning: unresolved symbol: stpncpy

But when I upload them to the owl via Browser or OwlControl they consume lots of cpu and audio drops out.

Is there an issue with a new heavy release or something?
Please help!

[mars]

So you don't have the same problem when you upload an already compiled binary? e.g. https://hoxtonowl.com/patch-library/patch/Cloud_Delay

Have you changed your blocksize with OwlControl? The patches should all run fine with blocksize = 128.

I don't have an OWL to hand at the moment so can't reproduce. Since the Heavy releases are now versioned we should be getting the same code back even when they make updates and changes.

[cosmono]

Sorry for the delay.
Yes, uploading compiled binaries works. Only pd patches going through the compilation process are affected.

I did not change any settings and block size is 128.

Can I fetch you some logs somewhere or anything - maybe with OwlProgram? I'm not afraid of terminals...

[jrp]

Might be incidental, but coding PD patches similarly in gen~ (if possible) reduced CPU usage from 100% to 20-25% here... maybe that is an option.

[mars]

I found this happened recently when recompiling the Jet Engine patch. I'll look into it now...

[mars]

So the culprit appears to be new calls to fmaf(), floating-point multiply and add. The standard library version uses way more processing power than the built in operators. No surprise, since the compiler converts them to a single-instruction VFMA (floating point multiply and accumulate) operation.

I've deployed a new version (also updated to Heavy release 2017.2) on the server and pushed to the master branch of OwlControl. With this, Cloud Delay runs with 52% CPU.

I don't know when exactly the change happened and if it was done on our side or Heavy, but if you've had poor performance from your Pd patches recently then pls try recompiling and see if this update improves it.

[cosmono]

That sounds perfect!
You updated OwlProgram, right? Any chance this patch will make it into OwlControl anytime soon?

[mars]

Yes so this update changes how the patches are compiled. It doesn't matter how they are loaded, with OwlControl or from the website, they'll still work fine if they're compiled with the right version of OwlProgram.

If you are compiling your patches off-line you will have to update your installation of OwlProgram (git pull origin master should do it!). If you are using the online compiler there's nothing you need to do, just recompile

[cosmono]

Ah sure.. I guess I got confused. After recompilation it now works just fine, thanks a lot!