Could it be GUI?
Perhaps, but OB-Xf looks to be JUCE-based just like OB-Xd.
When browsing some more through the code though I did notice some assert()s inside the oscillator antialiasing loops, and not an NDEBUG (which disables them) in sight, which could account for this though. They look really out of place as their arguments do not depend on any variables that change during the loop. Iād have to experiment though to see if this really could be the culprit or I simply have missed something somewhere.
EDIT: NDEBUG is set globally on the build command line so itās not that either.
I wonder if it could a lack of enabled optimizations for ARM ?
EDIT2: Thinking about it more clearly, since the DSP code is practically disabled when there are no voices playing, thereās either something very wrong somewhere, or it is indeed the GUI as @riban suspected.
EDIT3: The GUI (via VNC) is increadibly sluggish, which again points to the GUI. Turning off VNC causes the CPU load to drop from 100+% to 18% or so when idle (as measured with top), but it is still a lot more than for instance OB-Xd under the same conditions, which uses about 2% (and the MiMi-d with its complete lack of GUI is at about 1% when idle). All on an RPi4 Zynthian.
EDIT4: Itās something else too, like optimizations; with 4 voices playing OB-Xf jumps from 18 to 48% CPU load (with no GUI), whereas OB-Xd goes from 2.7 to 7% under the same circumstances. All very approximate because itās not the same patch playing, etc, but still quite indicative.
1 Like
@jofemodo Is this in Vangelis, Oram staging, or Stable ? Right now (with oram-2511.3) I get a long list of patches called Default which are - default, i.e. a simple sawtooth wave with organ envelope.
I wonder if it is the second LFO? This is a new feature and apparantly per voice, so for each note/voice a new LFO gets triggered.
Reducing the polyphony makes CPU usage going down. Still, in Carla, OB-Xf is also triple the load of OB-Xd for the same polyphony of 8 voices.
Patches are working for me, but there are still several bugs.
Did not have time yet to further update the TTL, but keep in mind this plugin is still in BETA.
This issue seems to relate to CPU usage:
1 Like
OB-Xd already has two LFOs (except one is earmarked for Vibrato and corresponds to the LFO on the bender panel on the original) but not per voice though. However, I donāt believe an extra LFO per voice would account for the threefold increase in CPU load per voice compared to the OB-Xd. The LFOs are very lightweight as there is no antialising or key tracking.
I did raise an issue with the OB-Xf project ( Plugin uses an unexpectedly large amount of CPU on Linux ARM64 Ā· Issue #555 Ā· surge-synthesizer/OB-Xf Ā· GitHub ) regarding the CPU load, because there ās no obvious reason to me why the load should be so excessive. Apparently they have found an issue, but it seems related to the GUI (which has already come down from 100%+ CPU on an RPi4 Zynthian for the version currently included in Zynthian to 18% (still vastly more than the 2% that OB-Xd uses) on the current top of the main branch) and not to the DSP code. Iām going to try it out tomorrow.
Unfortunately, just switching to the top of the main branch is not practical, because the URN of the plugin is not the same (it has the added suffix ā-reworkā which will eventually be removed before a proper release ( Plugin on main branch presents itself as org.surge-synth-team.OB-Xf-rework Ā· Issue #556 Ā· surge-synthesizer/OB-Xf Ā· GitHub ). EDIT: This has now been fixed.
Itās good that they have some ideas for optimizing the code in the ticket you mention (some of which I think mirror the changes done in DiscoDSPās code between version 2 and 3 ( OB-Xd 2.x vs 3.x Comparison: Complete Technical Analysis | discoDSP )) , but I think before they even start on that they should try to get the CPU load down to the OB-Xd level to start with, as there seems to be something hogging the CPU as it is now, whether it is pure code or just some compiler (or linker) optimization that is not properly enabled.
2 Likes
A fix to reduce the CPU load from the GUI has brought it down to virtually nothing, but the DSP portion still consumes a lot of CPU. On my RPi4 Zynthian thus about 20% CPU when idle, and 50% with 4 voices playing.
Right, so it turns out the instructions in the README.md file in the OB-Xf project were not entirely correct (theyāve been fixed now), so the resulting build did not have all required optimization enabled. Together with a number of speedup fixes, building from HEAD of the main branch, OB-Xf now uses less CPU than OB-Xd when playing; the idle load is still slightly higher (like 3.7% CPU for OB-Xf vs. 2.0% for OB-Xd on an RPi4 Zynthian).
One thing though, more of a Zynthian thing, in Oram-2511.3, although there seem to be a long list of available patches, when loaded into the plugin they all sound like the default patch (one saw osc, open filter, organ envelope). I suppose one should really be using Vangelis with something so bleeding edge?
Not sure how to best bring in OB-Xf; it takes forever (like en hour! - EDIT: Actually, not really but almost: the complete build takes a few minutes short of 45 minutes in actuality) to build on an RPi4, but Iāll leave that to the Powers That Be (@jofemodo ). 
Just thought Iād report on this latest development.
5 Likes
What an amazing debugging work you have done here @ricard! This opens the door to a really viable Zynthian integration of OB-Xf 
2 Likes
That will make all the different engines sit up and jump!
3 Likes
Iāve mostly nagged at the OB-Xf team that itās not behaving as well as I think it should, no real debugging on my part. In fact Iām rather humbled by the attention that this issue has gotten from the team when they just could have ignored it, considering Iāve not really contributed anything to the project.
2 Likes
Our own contribution are frequently the one we most inaccurately gauge.
You have made an enormous contribution within this community and that reflects well on all involved. Except @riban, obviously.
3 Likes
Hi @zynthianers!
Iāve updated the OB-Xf version to 0.9.21, fresh compiled from source with latest improvements in CPU usage, etc.
Itās available in Oram Staging and Vangelis.
Presets are still āunbankedā. Iām thinking the best way to do it.
Enjoy!
9 Likes
Where does the conversion of native format preset files to .ttl files that can be loaded by the Zynthian UI happen? Iāve got OB-Xf running (on oram at the moment), and have upgraded (or rather built from source) to the latest version of it, but even after running
regenerate_lv2_presets.sh urn:org.surge-synth-team.OB-Xf
and/or just
regenerate_lv2_presets.sh
I canāt see any presets in the Zynthian UI, which on the face of it might not be surprising, since Iām not running oram staging or Vangelis, but I canāt seem to make out if there is any specific code that performs the conversion (probably looking in the wrong place) that I can bring in. The plugin itself runs fine, and I can load presets from its native menu.
2 Likes
Are you using the official zynthian versiĆ³n or did your build from sources?
Regads
Build from sources.
If you install the versiĆ³n included en zynthianOS, It already have the LV2 presets.
Regards
You mean this tarball: http://os.zynthian.org:9080/plugins/aarch64/OB-Xf.tar.xz ? It looks like it only only contains the patches in .fxp format?
It contains the LV2 presets too. Look st the manifest.ttl.
Regards
cant seen to find it in oram staging?
OB-Xf 1.0.1 has been released on github.
It seems to add many patches which is what the presets are called.
Update: logged a ticket for this at Update OB-Xf to version 1.0.1 or higher Ā· Issue #1612 Ā· zynthian/zynthian-issue-tracking Ā· GitHub
3 Likes