EigenD 3.0 - Beta-2

Eigenharp
81

anyways, Ive cleared the backlog - except 3,
but they are things, I’ll leave for when Im feeling in the mood, not really urgent - more ‘tracking’ issues.
still not got access to a windows pc, and thats really the ‘next thing’.
might just let it all settle for a few days now… as Ive been doing improvments / fixes/ debugging virtually every day.
so think I’ll use the opportunity to take a small break.

I could put out a beta-3, but I think that can wait… some important fixes in it, but nothing that breaking anyone, I don’t think - more edge cases.

1 Like
82

Sounds like a good plan!! … and I can catch up/do more playing/testing like I don’t know the instruments ehehe…

2 Likes
83

I’ve played more with the various ‘factory setups’ on all the eigenharps, in last weeks, than I have for years ! I’ve tended to just always use my own Alpha setup.

It’s given me some ideas about how EigenD with these setups could be definitely improved.
try to embrace their flexibility, reduce their complexity a bit.
Theres some cool stuff, that I could definitely enjoying playing with…

in some ways, I think EigenD was a bit advanced for its time…
Macs were not that powerful, it felt slow, its performance was a concern.
these day it just doesn’t feel like thats an issue anymore.

2 Likes
84

Amazing!

Thank you so much for this update! You sir, are a rock star.

FYI, I got a build running beautifully so far on Linux (using ubuntu 24.04). There are a few minor tweaks to the C flags in linux_tools.py, and a few issues with dependencies (had to fight a bit with the LD flags for Juce modules), but nothing too onerous.

If someone wants the deb file for apt, let me know.

As of yet Mark, I haven’t run into any bugs. I’ll start working through some agents, but so far the agents I actually use in my setups have all been stellar. Also I noticed that the load times are about /4 of what they were, and the UI is far, far more responsive.

I use the midi agents mostly these days, and so far, I haven’t encountered any issues in the inputs, outputs or OSSC stuff.

I’ll do some testing over the next couple of weeks when I have time away from work, and send any feedback to github.

Amazing job!

2 Likes
85

great, good to know…

the cflags are to be expected - it’ll be due to C++17 and Juce,
happens pretty much every time I update juce :wink:
I’ll update when I get around to compiling it.

what is your target x86_64?
my plan would be to target both x86_64 and arm64.

btw: before, you probably needed a script to set the LD_LIBRARY_PATH for modules, this should be no longer required, as Ive changed the RPATH. so should pickup as relative to binary app - however, as Ive not built on linux, Ive not tested yet.

load times, yeah, Ive not done any ‘testing’ of this, but generally, I had thought load times on large setups were improved from casual running . Id put this down to being 64 native on Mac, but there are various other small changes which could have helped.

unloading, is where I hope (mid-term) we will see the bigger improvements, as thats obviously bugged (and always has been)
Im hoping once fixed (3.1.x?) this will make switching setups much more practical, which would be really cool.

I guess I should put some effort into getting the GitHub actions working, then I could push the linux builds too.

what is useful about linux as a testing ground is, it uses libusb.
and Win64 will be based around libusb NOT the Eigenharp windows driver. ( * )

my intention is 3.x will be focused 64 bit only.
(I wont remove 32bit support from the eigend repo, but I wont actively support / distribute etc)

( * ) because we dont have source code for this or its client side ‘stub’, so cannot get this to work on 64 bit windows.
SO… win64 will be libusb and (likely) users will use Zadig for the libusb driver.
note: it could be possible we use libusb-win32, I need to do some further testing on this.

86

I built on x86_64.

I started down the arm64 path a few months ago, but ran into some issues getting a python 2 build for arm64 working. armh (32) was fine as there were some prebuilts I could use, but all the arm64 stuff out there was python 3, and even deadsnakes source repos didn’t have the older python source, and the older stuff from python.org just would not build right on arm64, so I put it aside.

Now this is working with python3, this should be pretty straightforward.

I should note I am using C++ 23 in my regular build chains so I used it here.

However -Werror needs to be dropped using 23, as it throws warnings on very silly things, like legit extra braces for readability, which Juce is peppered with.

In the EigenD source there was only one issue, with -Werror, and it was easily fixed. sys_errlist is deprecated, and replaced by strerror, so there are 4 functions that use sys_errlist that I needed to update to use strerror to get by the warnings, but Juce… There’s a lot of legacy code in it that would take ages to update, so I just build with warnings, and then read through the warnings to see if there was anything important. No, it was ALL just petty stupid code format stuff like complaining about optional parenthesis in macros.

Yeah, I had to append a couple things to LD_LIBRARY_PATH, but that’s gonna happen on any platform depending on where stuff is kept anyway.

Oh, one thing about juce, is that it is really sensitive to load order of the libraries for some reason. It HAS to be -lcurl -lharfbuzz -lfreetype -llibfontconfig in that order or juce throws a temper tantrum when it comes time for LD to do it’s work.

Frankly, I have no clue why. LOL

2 Likes
87

arm64 is python 3 only, like macOS.
python 2 was eol’d a while back so was never going to modern platform support.

thats why it was so important to move EigenD, so that the whole toolchain could move forward…
also this time around, we’ll only be depending on core python, no python libs, and thats just use for the plugin interfacing etc.
unfortunately, its impractical to rip python out completely, theres 1000s of lines of python code, and some of it is very specific.
… so im just trying to reduce the dependency.

yeah, I’ll likely to keep it for at c++17 for now
(the standard not the compiler, I use the latest gcc compiler)

really, I just follow juce, because as you say, its got a lot of older code, but they are tidying it up slowly… c++17 I think was new for juce 7 or 8.
whilst Id like c++23, no code (obviously) uses it, and if your just going to turn off/ignore warnings… then you don’t gain anything really.

yeah. load order is a pretty common issue on linux for linking, just another thing I sort out, when I get to it :slight_smile:

I’ll check out the ld_library_path when I get to it,
for eigend itself it should be fine, but yeah, some system libs might need to be setup depending on your dist etc.

but yeah, linux will always need a bit of tinkering … its just its nature, but fortunately, most using linux have experience in such things.

88

Mark, can’t thank you enough! Works really well after me remembering how to do a new setup. Playing Omnisphere 3 via the Tau and it is amazing! All the start up glitches and shut down problems seem to be gone!

3 Likes
89

that’s really good to hear…

I need to get back to this to sort out the Windows build, but overall Im happy with the stability of the beta so far :slight_smile:

3 Likes
90

Thank you so much for keeping this active.

Have to admit I’m an out-of-scoper in the sense I have a Pico together with many Linux & RPi platforms (I maintain RPi ARM images for Devuan Linux), but no modern Apple silicon hardware to play with.

Cloned repo and just starting to familiarise myself with the code & look at the state of compilation for Linux …

If anyone else is interested in advancing this, please get in touch!

Best Wishes for the new year!

91

as someone mention above it should compile with minor changes.

prior to 3.0 I had it compiling on linux, and generally during this beta I updated Scon files for linux too, so its just ‘not tested’.

after holidays, I’ll try to find time to update any issues I find, likely on ubuntu/debian (64 bit), also I wanted to double check the arm support for 64bit.

ofc, for other distros you may still need to make adjustments, as is the nature with linux.

also, I should note, that Im only going to be targeting 64 bit platforms now… I won’t remove the 32bit build support, but wont be targeting / testing / distributing it.

as mention in the OP here, the main priority is to keep EigenD moving forwards, so we can use with todays tech.

1 Like
92

Hi Mark,

Thanks for the updates. I have encountered a weird glitch.

After an update to libharfbuzz needed by libre office, suddenly all fonts in the display area of the eigenD UI no longer appeared. Now, that’s the first time I noticed this, but it’s possible it was something else and I just didn’t realize, as I generally have EigenD running the background, so I hadn’t reloaded the UI in a long time.

Fonts are all displaying in all other apps that have harfbuzz deps, including python tk and Qt windows, and a handful of JUCE test apps. So I figured that maybe there was something weird happening in the bundled version of harfbuzz in the included JUCE version.

So I rebuilt both harfbuzz on the system level, including dev libs, and updated the stuff in the included EigenD/lib_juce/juce/modules/juce_graphics/fonts/harfbuzz directory too

EigenD happily builds with no warnings or errors

Uninstalled/purged EigenD, installed the new build, and… exactly the same odd pattern.

Everything runs, and I can use my Tau, but… workbench, the main UI, menus… all fonts are missing.

MEC vst is fine… It’s just EigenD that’s decided “no” on displaying fonts or menus.

So… I decided to try rolling back to build 60830 of harfbuzz (last build), But… same thing.

Nothing in the logs regarding fonts or graphics display warnings or issues either.

So I am a bit mystified.

Is there maybe some weird interaction with wayland or something that maybe I haven’t thought of? I mean, it was happy for months, so I dunno why that would have changed, but… I’m just guessing at this poin.

My best guess is that internally it’s started to look for a path to font that doesn’t exist anymore, but nothing is logging.

I thought you might have encountered something like this in your travels, and could suggest a workaround?

It’s very strange.

93

I assume with ref to wayland and your previous posts , we are talking linux.
I’ve still not got around to testing on linux, so not sure whats going on.

Not sure where to look…
I assume you have checked libharfbuzz GitHub? apart from that Id look to juce and the juce forum.

generally, what happens with juce, is 3rd party updates will break it - they’ll get reports and fix it - so often an update of juce (release or dev) will fix it.
BUT… linux is not used that much, so that may take a while - as devs/users don’t notice it, or might only happen with certain combinations / distributions.

yeah, given you have said the issues started when updating libreoffice, Id say this has updated a subcomponent that is used by libharfbuzz.
given its not just eigend thats affected id say its more a general issue with libharfbuzz, possibly regardless of libharfbuzz version. as you say, could be wayland related.

the ‘logical’ but not easy step is to look at what libreoffice updated, possibly try to rollback that update… see if it goes back to working.

unfortunately, one issue with linux is this cross-dependancy, so Im not entirely surprised when these things happen. l
inux’s ability to be customised, and have what you want install, different distros is its strengths, but also a weakness in dependancy hell.

94

Thanks for the response.

Yeah, it’s got me stumped. LOL.

Stepped through all the dependencies and that’s the only thing that updated, and even tried stepping through program execution with debugger (gdb) to watch calls and try and figure out what’s going on. No errors or warnings thrown, and eigend steps along happily, and debugging shows me that it does appear to be reading the system fonts and can enumerate them.

Near as I can figure, it’s a breakdown between harfbuzz and juce somewhere, but only in the eigend context.

I can even get the Juce demo apps using harfbuzz to load and draw the label boxes and fonts and as I said, other apps, including MEC vst are happy with the stack, it’s just something in the context of EigenD. It may have happened before the Harfbuzz update and I just never noticed.

It occurred to me this morning there is something else I could check. EigenD is different than the other apps I tried in that it also uses python in the mix. Some of the way the UX stuff hangs together in EigenD I find rather confusing, but I suspect it’s possible that some python security update might have broken it’s bindings to harfbuzz, so at least it’s something I can try to look into.

I could also try just actually embedding a font or two and using that, and see if it’s just that it was struggling with loading system fonts, or if the issue is in drawing the container.

Anyway, thanks for responding.

It’s a strange one. I’d have expected at least something showing up in gdb, but as I said… program execution seems happy and normal. It’s just that at runtime in the rendered UX, the fonts/labels have vanished.

If I figure it out, I’ll share in case it helps anyone else.

If not, well, maybe you’ll bump into something similar on macOS and figure it out there and might get some insight you’ll hopefully share. The stack is almost identical on macOS being a flavor of BSD, so maybe something will come up.

I’m going to try a few other versions of older harfbuzz builds, and experiment with the python bindings. Something tickle in the back of my mind makes me think I should investigate if maybe the issue is in a python binding, not juce or harfbuzz, as they seem to play nice on other programs, and it’s something I haven’t looked into yet.

You gotta know, that it’s probably gonna be something simple like that, some python security update dropping the ability to load local filesystem paths in some module or other. LOL

Anyway, thanks for the feedback.

Have a great week!

95

its unlikely to be python… eigenD and workbench do not use python for the UI, they are pure C++ / juce. python is only used to bind to agents.

if the menu is not even showing then its something pretty low level with fonts etc.

Ive a suspicion, we’d not see this on Mac/Windows as they use completely different graphics apis. (CoreGraphics/ D2D), they are have thier own ttf. so different implementations = different behaviours.

IF its just fonts not displaying correctly - then Id hazard a guess its something to do with freetype, perhaps fonts missing or somehow configured differently.
perhaps, EigenD/Workbench are using different font options?

its also worth bearing in mind, EigenD does not use harfbuzz directly, its using pretty simple juce code in this area which use harfbuzz in the same / similar way as the juce demo code does.
so Id look for difference there, or I guess something in the linkage (though if it compiles/links that seems odd), another issue might be some oddity in initialisation timing, but again seems a bit unlikely.

96

Yeah, after a day of testing and using the debugger, it’s pretty much some weirdness going on in the version of JUCE in use.

It doesn’t like to play nice with more recent versions of harfbuzz or freetype2.

Ubuntu finally updated to 8.3 (current is 12.2), but it seems that harfbuzz broke something important to older apps.

It will build, and it doesn’t error at runtime, and I can even see a list of system fonts that JUCE sees, but they just won’t render. I can create textboxes, buttons, etc… all render, but… fonts won’t. They don’t even error. LOL.

I tried moving to native rendering by disabling harfbuzz, but the bundled version of JUCE is… odd. Header files say it’s version 8, but native rendering methods in 7 and later aren’t present, and I ran into what appear to be some custom extensions that were tripping me up when trying to put them back in. It looks like some custom work went into that bundled JUCE at some point, and updating it isn’t so straightforward if you’re not really familiar with the code and all the changes JUCE made over the last few years.

I’ll just need to run it on an older Ubuntu for now.

When I have more time, I’ll try to bring the JUCE stuff forward, or bundle an older version of freetype and harbuzz into the build instead of linking to system libs.

Interestingly, current JUCE downloads all work, and the demo apps build and everything renders right, but… yeah, same issue with the leftover demo/example code in the lib_juce dir. If I build those, I get the fonts issue with them too.

I am very curious what they broke. You’d think that JUCE would throw exceptions, or something would show in gdb.

Oh well, I can still use the command line anyway, and my setups haven’t changed in a year. Everything works, except font display. LOL

Thanks for letting me bounce this off you.

I enjoy a good mystery, but I think this one is a bit too tricky for me right now. Putting it aside until I have more time.

LOL.

97

not sure what you mean !?
lib_juce has no left over code …

lib_juce/juce is a submodule of the main juce repo. its not a fork/copy of the code.
the stuff in lib_juce is just how eigend interface to and build with juce.

the main ‘difference’ with eigend and other juce project is the build system!
juce projects usually use either Jucer to generate make files.
or, (more recently) CMake, which leverage juce’s own cmake templates files.

This is not possible for EigenD as it’s deeply locked into the Scons build system, for a number of technical reasons (e.g. pip generation) - Id love to move it to Cmake but its a massive undertaking, for little benefit.

anyways…this means things like juce.h/AppConfig.h (SConscript) and all the build / link flags are ‘handcrafted’, which can cause a few issues when upgrading.
basically, each (major) release I have to compare what the juce builds do, and bring Scons into line with it

note: the jucer files you see in the eigend project have not been used for a very long time, I should delete them :wink:

so…

if the demo/example code in lib_juce/juce/examples does not work, then that is a juce thing with the build used.
ofc, juce updates regularly, and git submodules are ‘frozen’ in a moment of time… to get the latest version you just need to do a checkout.

so if you do a fresh checkout, of juce in a different directory and it works, then perhaps they have fixed something…
note: its pretty common for them to also break /change things between releases,

anyways… all cool,
its been useful either way, as its quite possible when I compile the linux version I might see this…
that said, I mostly use linux for dev, so I dont update my distros often (if it works, dont fix it ;)) … so perhaps I wont !?

98

Ah!

Yeah, the “leftover code” I was talking about was the juce/examples in lib_juce. They run, but no fonts in the FontsDemo or others. Same behavior as EigenD.

But if I download 8.0.12 release of JUCE and run FontsDemo in the examples dir, then it works.

The bundled JUCE throws an error on build for juce::LookAndFeel::getDefaultLookAndFeel().setUsingNativeTextLayout(true);

[error: ‘class juce::LookAndFeel’ has no member named ‘setUsingNativeTextLayout’]

Which is odd, because that was introduced in 7, but if I download 8 from releases, the member is present.

So that’s what I mean by “odd”. It’s like it’s version 8, but also not version 8.

Your explanation totally makes sense now. It’s something in that checkout that likely got updated or fixed. The harfbuzz update was in response to a security vulnerability found in chrome, so it got pushed back in september and only managed to make it down to Ubuntu 24 and Mint about a week or so back.

So I suspect that JUCE 8 got updated to deal with whatever harfbuzz broke. And I suspect it’s something that got changed in the GL render libs. No direct evidence of this yet, but I’ve seen something similar years ago with Qt components when render acceleration was used. I’m guessing harfbuzz updated the interface to newer method calls, or similar. So harfbuzz gets a call to render a font from JUCE and is just dropping it on the floor. So the bundled JUCE gets back nicely rendered empty strings or something silly, and dutifully sends the result out to the UI. No errors, no exceptions. It got exactly what it asked for, but harfbuzz threw a temper tantrum. LOL.

and yeah… maybe don’t update, or flag harfbuzz as locked so your linux doesn’t update it.

When I have a bit more time, I’ll try to move the JUCE forward and see what needs updated. I may have a lot of questions about the SCons setup tho once I tackle it. Outside of EigenD, I’d never used it before, and I’ve come to calling it SCons-fusing. LOL.

I bet that this is going to turn out to be something minor too. Something like small change to a harfbuzz interface that is easy to fix once you know where it breaks down, and that JUCE already did it, so… if I can wrap my head around the SCons build chain, it’s probably just a simple git pull for a later version of JUCE.

But, the good news is that the built deb packages work fine on an older Ubuntu 22 I have on a laptop, no fonts issues, and that’s locked down to harfbuzz 7 something and it’s a slightly older freetype2 as well, but looks like just a minor version change. So it’s definitely something about the version of harfbuzz with the bundled version of JUCE. Harfbuzz 8 or later isn’t playing nice with it.

Also, I was wondering what was up with the jucer files. I couldn’t figure out why changes there didn’t do anything. Hahahah. I’d assumed SCons was farming out some of the work to Jucer, but it wasn’t working. I really need to sit down and do some proper study of SCons.

So, yeah, don’t update! LOL

Thanks again. That was very illuminating, and gives me a path forward to experimenting with JUCE updates that will probably lead to a solution when I have a few more hours to spend on this.

Cheers!

99

I’d have a look at ejuce_laf.cpp in lib_juce (and app_workbench for workbench).
this overrides the look and feel, to set colours and also the default font.

I notice that for Linux it uses the default sans serif font, whereas Mac/windows have it overridden - this should be ok, just a style choice - but worth checking.

what I also notice is workbench derives this from juce::LookAndFeel, whereas eigend uses juce::LookAndFeel_V2 .
there are now up to juce::LookAndFeel_V4 (yeah, wierd way of doing this ;)).

in theory this is just a style thing, moving with modern ui ‘taste’, and no doubt examples will use tha.
but it could be that there some oddities in the juce::LookAndFeel_V4 that make it work, -, and break older juce::LookAndFeel
though looking at the juce code, doesn’t look that likely.

note: Id be careful changing to juce::LookAndFeel_V4, it could introduce all sorts of other graphical oddities.

ALSO, it doesn’t explain why lib_juce/juce/examples do not work - we use 8.0.10.

the obvious thing to do is to check change log/breaking changes for 8.0.11, and 8.0.12 if you are finding 8.0.12 works for you.

main changes listed are :

Version 8.0.12

Made Visual Studio 2026 the default in the Projucer
Fixed a compilation error in Android In-App Purchases
Fixed some MIDI device names
Version 8.0.11

Added a new MIDI 2.0 Universal MIDI Packet demo
Added a Visual Studio 2026 exporter
Improved support for macOS/iOS 26
Updated the VST3 SDK to 3.8.0 (MIT license)
Updated the AAX SDK to 2.9.0
Included the ASIO SDK source files directly (GPLv3 license)
Updated Sheen Bidi to 2.9.0
Improved rendering performance with a font and glyph cache
Added a new juce_audio_processors_headless module

given your issue is with fonts… perhaps Improved rendering performance with a font and glyph cache also fixed something? (though seems a stretch)

all that said, I had a quick look at the graphics commits in juce , harbuzz hasn’t changed in over 2 years, and nothing else recently,.

anyways… only suggestion I can make is update eigend to 8.0.12 and see if this fixes it - no breaking changes, so should just ‘work’.
honestly, Id be (pleasantly) surprised if it does fix it, as I don’t see any obvious changes.

if not, then I’ll see if I can make some time at the weekend…
but as I said, Ive a nasty feeling, that it might work on my linux machines.

I see your using 24.04, Im on 22.04 -
honestly, Im a bit reticent to upgrade, as I have a lot of dev stuff on it, which I dont want to break/lose - if I did, I go straight to mainline release, so 25.10.
but yeah, its another thing, that’ll no doubt take a few hours to get setup as I need it to :frowning:

all this is partly, why I put linux on the back burner of now… but perhaps its time.

100

We must have been thinking much the same thing.

I spent another night on it last night after work because I was sure that I could lick this with some similar ideas.

I tried building against literallly every harfbuzz from 8.1.1 to 12.3,2 and each major release of freetype2 from 2020 until now, including the bundled harfbuzz in JUCE 8.0.12. Nothing, no change.

I tried build against various versions of JUCE from 7.0.12 (Apr '24) to now, and modifying the SCons config to deal with changes, and everything mostly built, with the exception of moving past 8.0.10, which caused a lot of problems. There are a bunch of breaking changes in weird, places, like lib_mid, juce::MidiInput::getDevices() isn’t a member function anymore, and you have to use juce::MidiInput::getAvailableDevices() which returns names, and not indexes, so you have to adjust code, and juce::MidiMessage mm((const unsigned char *)d.as_blob(),d.as_bloblen()) doesn’t work as it chokes on as_bloblen not being a declared function, but it is in the data_nb_t, so I gave up on x.11 and x.12, but went through knocking off configs and rebuilds semi automated as I binge watched some series in the background. Run build, watch a few mins of show while I wait, test, update, rebuild, go back to show, rinse repeat. LOL

No combo worked, even ones that worked before, yet they all worked on the 22.04 box.

Yet if I built the juce examples directly using jucer, all fonts present.

Bewildered, I eventually just added iostream to everthing, peppered everywhere liberally with std::out statements to watch each step in the paint process, from getting and loading fonts, to output.

Literally, the glyph string coming back from juce feeding text / fonts to harfbuzz was sending back empty glyphs, but ONLY in the EigenD context. This seems to be happening somewhere in an interaction between harfbuzz and libGL, but that still gets called in the EigenD context even if you force software rendering. Doesn’t if I build JUCE examples directly from the same JUCE version.

Yet, these all work fine on 22.0.4.

I am next to certain, that this is a mesa/GL bug of some kind at this point. Update logs show that a few weeks back, the AMD drivers were updated and that might be around the time the issue started AFAIK. As I mentioned, I only noticed it after the harfbuzz update, but it might have happened earlier.

Why that’s an issue only in EigenD, I honestly couldn’t say, but… brute forcing var dumps each step of the way in everything… harfbuzz is returning empty strings, and both native rendering (which I finally got working in a build) and harfbuzz call libGL/mesa under the hood, and it doesn’t appear either get anything back when I raw dump using std::out.

So, I setup a VM running the same version of ubuntu, but with no hardware passthrough to the GPU, so no amd drivers or GPU optimizations, but same OS, same basic Ubuntu 24.04 setup… and wouldn’t you know it, no fonts issues on EigenD.

So I am next to certain that there is something going on when running EigenD on my main rig, that somehow is interacting really oddly with mesa/GL. Something about how it builds seems to trigger a bug in mesa when rendering fonts.

A bit of research turned up that some other tools using JUCE were having the same issue on Arch linux, including Reaper and Bitwig VST hosts.

I think that this isn’t an EigenD issue per se, rather a bug in mesa/GL that somehow can be triggered when things are built a certain way.

As I said, if I pull the same 8.0.10 that’s in EigenD, and use Jucer or CMake, the fonts are fine, and if I run that same EigenD binary on another 24.04 Ubuntu that doesn’t have the AMD/Roc mesa, it runs fine, fonts all display.

When I enable GPU passthrough on my VM, and install old open source AMD drivers, and use vanilla mesa, it works there too. Just on the raw hardware with AMD ROc mesa… text all vanishes.

So, this weekend, I am going to see if I can roll back the mesa stuff on the rig safely and see what happens. It’s a bit tricky, as my main rig is also a multi-gpu setup for ML applications for work. But I know for sure that EigenD had no issues with font rendering a month back, and the binary didn’t change, but harfbuzz did, as did mesa/GL. I think something about EigenD just happens to trigger a bug in newer AMD / ROc drivers.

I also downloaded Reaper (don’t really like it, I’m a bitwig user mostly), and there are some serious weird font issues in the UI on this rig, not on other ubuntu machines. Only major difference… GPU and mesa/GL versions.

For the life of me tho… I can’t see why this would be different between building the examples in JUCE with jucer, vs an SCons build, or CMake build. Something too subtle for my dumb brain.

Anyway, that’s where I am at. I don’t think that this is really an EigenD issue at all. I think it has something to do with mesa/GL based on the std:out output and running under GDB. The EigenD build (and apparently reaper build) have trouble getting anything back that renders fonts in a graphics context if using AMD mesa extensions.

So, I am gonna try rolling back those drivers and dependent programs, and see if it fixes it. In the meantime, it works absolutely fine on my other Ubuntu boxes that DON’T have AMD GPUs or mesa.

Figured I’d update you. I’ve come to the conclusion that the issue lay outside of EigenD and it’s a JUCE / mesa/GL issue.

1 Like