compile without GUI about fat1.lv2

[lokkiikkol]

nice, that worked. but the plugin uses too much CPU that way (lots of underruns). will try to add in optimizations and see how far i can get.

[x42]

make BUILDOPENGL=no BUILDJACKAPP=no should do it

you may also want to override OPTIMIZATIONS (default assume intel, SSE). have a look at the first 15 lines of the Makefile, that should give you an idea.

make BUILDOPENGL=no BUILDJACKAPP=no OPTIMIZATIONS="-O3 -DNDEBUG"

[lokkiikkol]

thanks!! will try.

[x42]

Alternatively you could also grab an ARM binary from https://x42-plugins.com/x42/x42-autotune
That should run on the Cortex-A8

[lokkiikkol]

hmm, probably the better idea...what optimisations are in the arm version you provide? i got it to compile here with the "OPTIMIZATIONS="-O3 -DNDEBUG" that you suggested.

[x42]

-Wall -Wno-unused-function -O3 -ffast-math -fomit-frame-pointer -fno-finite-math-only -fvisibility=hidden -fdata-sections -ffunction-sections -DNDEBUG

and for armhf, also -mfpu=neon-vfpv4 -mfloat-abi=hard -mvectorize-with-neon-quad

[lokkiikkol]

thanks!!

[x42]

you're welcome. Let me know how things go.

[lokkiikkol]

hmm, not so great. it seems the LV2host on BELA is lacking some port compatibility (i guess midi input), i get this:

Port 0 has unsupported type
Fat1.lv2 error: Host does not support urid:map
error: Unable to instantiate plugin `http://gareus.org/oss/lv2/fat1'
Segmentation fault

EDIT: maybe the BELA team can look into porting the lv2host from MOD, that seems to run the autotune plugin.

[lokkiikkol]

ok, got a little further. there is an old BELA port of jalv that i compiled. when i run the fat1.lv2 with jalv i get:

root@bela:~/Bela/projects/jalv-Bela/build# ./jalv http://gareus.org/oss/lv2/fat1
Plugin: http://gareus.org/oss/lv2/fat1
UI: None
Plugin requires 1 inputs and 1 outputs
Sample rate: 44100 Hz
Block length: 64 frames
MIDI buffers: 4096 bytes
Comm buffers: 65536 bytes
Update rate: 25.0 Hz
Illegal instruction

[x42]

Illegal instruction

That usually indicates the the binary is not compatible with the CPU. Assuming this is from the plugin (and not jalv), perhaps try to compile it without any optimizations. Maybe simply
make clean ; make OPTIMIZATIONS="-DNDEBUG

[x42]

try increasing "Block length: 64 frames" to maybe 256
also start adding some optimizations back in. Maybe make OPTIMIZATIONS="-O2 -DNDEBUG

[lokkiikkol]

thanks, it runs with "-O3 -DNDEBUG" and i get no more underruns. will try to add in the other optimisations one by one :-)

[lokkiikkol]

this works really well on BELA with the jalv host. i have almost all optimisations back in there, had to use "-mfpu=neon" since the BBB is not armv8 but 7. i am running it at a block size of 64 with 14% CPU, great. it also doubles as quite a fast pitch shifter via the bendrange control.
is there a "plugin" reason why this does not work at a block size of 32 or 16 even (i start getting frequent underruns even though the CPU still sits at about 16%) or is this something to look into on the host (BELA, jalv) side? thanks for porting this to lv2!!

[x42]

That's great news!

Tweaking your system to run reliably at 32 or 16 fpp wlll likely be significant work. I hazard a guess that you even get x-runs without the plugin already. I/O limited, probably some other IRQs get in the way and block the bus and or CPU.

With 64/48k, the nominal round-trip latency is 2.6ms. While plugin adds 21ms latency by default (in fast mode 5.3ms). That dominates jack settings, so there's likely no reason to tweak jack anyway.

[lokkiikkol]

nono, the hard work has already been done by the BELA team. they have a system that works reliably down to 8 blocks with c-code. so no, without the plugins it works perfectly well with 16! (even with a synth patch and reverb) one of the BELA devs has taken jalv and integrated the BELA backend into it (no need for jack anymore) so it should theoretically work at those low latencies as well. but as a matter of fact i am happy with 64 for this autotune use case, the latency in fast mode is good enough for my needs. i was just wondering if theoretically it was something in the plugin that prevents it to run on smaller block-sizes.

[lokkiikkol]

so, to close this off (thanks for your help again):

-could the fat1 plugin pitchbend feature (accessed via pitchbend messages) be expanded to be port controllable as well? reason i ask is because the BELA lv2host does not support midi at the moment, so i could control it via port. related to this, the bend range max is 7 semitones (as reported by the plugin) however i can easily set it to 12 or even 24 semitones and it still works. so maybe that max needs changing as well.

-second thought: how is the architecture of the plugin right now? is there some part in a worker thread already? (sorry did not yet look at the source) it seems that the fat1 plugin is generating some CPU spikes in BELA which could maybe be flattened if CPU intensive calculations could be moved to a worker thread.

cheers again, so happy to have this running!

[x42]

-could the fat1 plugin pitchbend feature (accessed via pitchbend messages) be expanded to be port controllable as well?

That could lead to conflicting data, e.g. a MIDI event may pull the bend up while a control-port even pulls it down, so no.

However, you can use the "Correction" port. Internally the pitch-bend value is simply added to that.

the bend range max is 7 semitones (as reported by the plugin) however i can easily set it to 12 or even 24 semitones

Yes, it's a soft-limit, not enforced by the DSP, you can set it to any finite value. It should probably be limited internally to the same range as stated in the .ttl.

-second thought: how is the architecture of the plugin right now?

The plugin collects data until there is sufficient context to determine the pitch and then processes data. Load from then on is constant as long as the pitch is changed.

I've seen some cases where near pitch-detection near silence produces a high-load on ARM CPUs.
you could try to add -DMOD to the the compile flags to skip processing data < -45dBFS/RMS.

maybe be flattened if CPU intensive calculations could be moved to a worker thread.

While this may seems like a good idea at first, yet it isn't for various reasons: The plugin does not know at which priority a realtime process thread should run. Starting threads will interfere with host-side parallel processing since the host does not know how many threads a plugin may start. Also synchronization primitives are expensive, in particular with low-latency applications.

[lokkiikkol]

On Thu, Dec 26, 2019, 12:00 Robin Gareus ***@***.***> wrote: -could the fat1 plugin pitchbend feature (accessed via pitchbend messages) be expanded to be port controllable as well? That could lead to conflicting data, e.g. a MIDI event may pull the bend up while a control-port even pulls it down, so no. However, you can use the "Correction" port. Internally the pitch-bend value is simply added to that.

ah very nice!! so that will have the same soft limits? meaning i can go up or down to octaves, that would be great!

the bend range max is 7 semitones (as reported by the plugin) however i can easily set it to 12 or even 24 semitones Yes, it's a soft-limit, not enforced by the DSP, you can set it to any finite value. It should probably be limited internally to the same range as stated in the .ttl.

please rather adjust the .ttl since values above 7 semitones can be useful for efffects rather then subtle correction

-second thought: how is the architecture of the plugin right now? The plugin collects data until there is sufficient context to determine the pitch and then processes data. Load from then on is constant as long as the pitch is changed. I've seen some cases where near pitch-detection near silence produces a high-load on ARM CPUs. you could try to add -DMOD to the the compile flags to skip processing data < -45dBFS/RMS.

ah good call!! i will try to recompile with that.

maybe be flattened if CPU intensive calculations could be moved to a worker thread. While this may seems like a good idea at first, yet it isn't for various reasons: The plugin does not know at which priority a realtime process thread should run. Starting threads will interfere with host-side parallel processing since the host does not know how many threads a plugin may start. Also synchronization primitives are expensive, in particular with low-latency applications.

i see, that makes sense. thanks

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17?email_source=notifications&email_token=ADDSM376D4XKTUPTXTSNLQLQ2SFEPA5CNFSM4JYTNRS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHVNJVQ#issuecomment-569038038>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDSM3ZPDYQ3F2COPONCAATQ2SFEPANCNFSM4JYTNRSQ> .

[lokkiikkol]

ok, i added the -DMOD to the cxxflags in the makefile, is that correct? if so, it does unfortunately not make a difference, but thanks!

[x42]

Yes that's correct. it was motivated by moddevices.com where it's common to have low level noise and no signal, the worst-case for auto-correlation to detect the pitch.