EigenD 3.0 - Beta-2

Eigenharp
101

Well, I was right. The issue turned out to be an odd interaction between lib_juce/juce_opengl and the AMD driver GL library.

I noticed that 2.1.7 community 32 bit still showed fonts, and started doing a diff to see what might be happening. Found the hand off, and it told me where to look in the headers for libglx-mesa0 and… the interface changed. Old entrypoints were still in there, but they changed a bunch of later functions, and appear to have left in stubs that don’t do anything.

So juce was handing off render objects that required GL (fonts, and some UX elements), which GL was dropping on the floor and returning null objects.

If I step all the way back to JUCE 6.0.8, all the fonts are back.

6.0.8 uses a legacy GL api that is still supported in the AMD drivers.

This weirdness in in the commercial AMD supplied drivers AND the open source ones. So I kinda get the feeling that AMD is plundering the open source xdna-driver git repo. LOL.

Anyway, I hope this prevents anyone else from going spare.

Roll back the JUCE in lib_juce to 6.0.8 and make sure you have amdgpu-core 1:7:2 or earlier (max version tested, might work on later)

1 Like
102

cool, but odd thats is such a low level issue - not common, as it’d usually affect a lot of apps.

hmm, so basically the new drivers dont support the legacy gl api, but juce has not been updated to the newer api.

rolling back is really only temp workaround, as I cant promise that later versions of juce will still be compatible with 6.0.8. i.e. we have to make breaking changes to support 8.x
might be ok for a while, as eigend doesn’t really use a lot of the juce of the api. but just so you know.

1 Like
103

That’s a good point.

I’ve a feeling that it might be something that the AMD/ROCm drivers will fix tho, as there are a lot of games that still use GL, and not Vulcan, and proton doesn’t work with everything. So I imagine that there’s gonna be pressure on AMD to fix the interface issue, and there are more than a few issues open on the xdna driver repo that appear to be related.

So, I think that this is likely to be fixed on the AMD driver side before JUCE updates come down the pipe. fingers crossed

Besides, you’re absolutely right. It’s a bit of a niche case. There aren’t that many folk that need the ROCm enabled drivers, as those are used almost exclusively for ML or data visualization tasks where you have multi GPU setups. Not a whole lotta users out there buying high end workstation or server machines to run their audio apps, and if they do,they’ll likely be on a mac studio.

So, maybe it’s not gonna be a big problem. I just happen to be in an edge case scenario.

But it was an interesting lesson for me about how the rendering pipeline works in JUCE and got me to really get deep into how EigenD does things, and gave me a kick in the butt to learn SCons a lot better. LOL.

Thanks for all your help and insight. You got me pointed in the right direction. I’d never have got there without your help!

1 Like
104

New laptop arrives tomorrow. Looking forward to installing this. Are there any pieces that particularly need testing at this point?

2 Likes
105

@thetechnobear I’m curious as to why does installing the beta require Rosetta to be installed?

106

hmm, interesting , it should not !

is it when you run the installer… Im wondering if for some reason that has been built as x86_64…

I’ve probably got rosetta installed on all my macs so didn’t notice… and, whilst I checked the EigenD process was running Arm, likely didn’t check installer.

107

hmm, weird, so when I run the installer, its all native.

until it runs the scanner, then its seems to run bash as Intel, not some unknown reason… as all scanner components are all arm

the only thing, I can think of on my machine is it might use the 2.2.1 install I have, i.e. a path issue? but Id assume you dont have 2.2.1 installed, so that would not be the case for you.

edit:
yeah, I cannot find an obvious reason…
do you get the prompt before it starts the installed (i.e. dialog comes up), or at a specific stage during the install process?

unfortunately, doesn’t look like I can uninstall Rosetta, so its very difficult for me to see whats going on.

108

Yes, it’s coming up as soon as I launch the installer. What might be relevant is that I used the Migration Assistant to pull everything from my old x86 MacBook when setting up the new one. (so yes, I probably do have 2.2.1 installed here!)

109

hmm, so if no dialog comes up, then that means the nothing has been run yet.
I only saw these 2 intel bash processes start when it got to running the scanner.

however, apparently, macOS will look at a package and if it sees a intel binary then you get this warning. so Im assuming thats what’s going on.

However, I just checked all the binaries that are exported to the package, and all binaries are arm64.

I wondered if some how the package manifest would tell macOS what ‘type’ it was, and if that was the issue, but I can’t find anything that says that is the case.

hmm, also just unpacked the package, and again, as above, no intel binaries.
so Ive no idea why it thinks it needs rosetta !

will have to muse on it a while, as Im out of ideas at the moment.

110

Installed Rosetta and the beta. Had a very quick play with a Pico over lunch, and noticed that with the cello rig, bowing via the strip only works in one direction (bottom to top).

111

has this changed? did it work previously?

so strip is -1,1, but thats it position, not its direction.
so there, shouldn’t be any difference (in direction of travel) as far as the hardware and input side to the cello is concerned.

looking at the cello code, the bow velocity is calculated as a change in position, and it actually is happy for that to go negative/positive. no changes in the code in this area of STK (which is how the cello is implemented)

so, I cannot see an obvious issue, or anything that has changed.

it’d need more testing for some more data points…

  • Id have to test on previous versions to check to see if this is new to 3.0 or an issue thats started at some previous time.

  • Id like to test it on an alpha/tau to test to see if its related to the pico.

  • perhaps Id test the strip against something else, eg. midi output? to see if the strip behaviour is as expected.

112

Perhaps the same bug as this one?
EigenLite pull request

2 Likes
113

good catch, indeed although the above was for my code - the same issue was in the original eigend source code.

it would have been a long standing issue…
(thats why Im keen to know if things are 3.0 or previous)

whats amusing, is I decided to check alpha / tau ‘just in case’, and I can see there the casting was obviously fixed (untidily!) at some point

./plg_keyboard/src/kbd_bundle2.cpp:            if(std::abs(((long)p)-first_)<=10)
./plg_keyboard/src/kbd_bundle2.cpp:        if(std::abs((long)p-(long)last_)<2)

anyway committed fix (thanks), untested for now…
also had a quick check to see if the other uses of std::abs had similar pattern, but none found,

issue tracked : [BUG] pico strip not working bi-direction on cello · Issue #31 · TheTechnobear/EigenD · GitHub

2 Likes
114

Hi all.

I’m both amazed and thankful that people are still keeping the Eigenharp alive. I’ve had a Tau sitting in a case for many years which I’ve always held off from selling. I’ve been thinking about trying to incorporate it into my frankenconsole, which I use to improvise a small orchestra in real-time (example of most recent impro - https://youtu.be/s8NnNbEHMWU )

What I’d need my Tau do is have each row spaced a fifth apart, and for each row to be on a unique channel. I use my Linnstrument mostly in channel per row mode rather than full MPE too. And I’d need the percussion buttons to go on a 5th midi channel. I do all of the routing in Ableton Live using a Windows 11 mini PC.

Is 3.0 easy and stable enough to incorporate the Tau into my current Win11 setup? Up until I found this post, I was planning to purchase an old cheap Win7 machine and connect via 9-pin midi, and I came here to see if there were more recent versions of EigenD software. I had no idea there was, and this recent! :slightly_smiling_face:

I have chronic CFS/ME and the associated brain fog makes it difficult to process words, but I’ll spend tomorrow digesting the 100+ odd posts in this thread and catch up!

115

Hello! A very short summary of the current state of things:

  • The official EigenD software is very old. There is no reason to install that anymore.
  • The community 2.1.7 version runs on windows and is better in every way. And yes, it is stable. This is the one you want.
  • The EigenD 3.0 Beta discussed in this thread is a MAJOR improvement from 2.1.7, but is mac only for now.
  • Some people find what to install and how a bit confusing - you’ll find info here.
  • You can configure your Tau the way you describe and then route midi out of EigenD into Live. Learning how to create a setup like that is a bit of a learning curve if you are new to EigenD, but it is worth the effort.
  • There are alternatives to EigenD around these days, but none of them run in Windows.

If you need help with anything just ask here in the forum. There are lots of friendly experts around. :slight_smile:

2 Likes
116

Thank you so much for your very helpful reply! I did dive into EigenD and Workbench a few times, so it’s not going to be completely new territory, but I will no doubt be needing help to get it all up and running.

I’ll try to dig out the Tau over the next day or two and dive straight in. Thanks again. Much appreciated!

1 Like
117

so, from my own testing, and others, Id say this beta is at least as stable as 2.x, probably more so,

yeah, unfortunately, Ive not got around to sorting out windows… (or packaging up linux)
I really do need to do this :laughing:

windows is a bit of a pain,
I need to move it over to libusb (as used by linux) as we cannot use the old eigenlab windows driver as its 32bit only.
I have tested/prototypes this ‘experimentally’ in the past, and it seemed to work.

I also ‘messed’ with the build system for windows, which means that needs work, which Im kind of regretting now… I might roll some of that back, at least for testing.

yeah, 2.1.7 was a bit confusing… though I think the instructions are as good as I can make them - suggestions welcome :wink:

hopefully, 3.0 is simpler as its points you to the python required, and we dont required runtime - but the resource package, whilst not require, is something I perhaps should include a note about?

Its a tricky one…
I don’t want to include 3rd party software or media (samples), as it makes the download massive, but the (standard) installer we use is pretty limited feature-wise, so its hard to make it more ‘friendly’ (and I really dont want to move to using a different installer, or write my own)
anyway… for now, its a lower priority task.

but yeah, for now @Orchestu , you’ll want 2,1.7, and basically you’ll need to remember to installed the Eigenlabs driver, and the resources package (if you want to use factory setups).

for me, need to get off my a**** and sort out windows lol

1 Like
118

Wonderful. Thanks so much :slight_smile:

While I’m plagued with CFS/ME brain fog, I have an ancient background in IT and a blind confidence that I can get everything eventually installed. I’ll probably need a fair bit of help setting up the workbench template though. I had a lot of issues understanding that back in the day.

All of the sounds that I use are hosted on Ableton Live, so I’ll only need the Eigenharp to act as a dumb midi controller. There won’t be any menus or different scenes (is that the right word) within the actual Eigenharp itself.

It’ll take me a day or few to dig out the Eigenharp, but I’m really excited.

Thank you!

119

A post was split to a new topic: EigenD - windows install issue 2.1.7

120

Hello everyone, especially you linux users out there.

I made a working build for Ubuntu 24+

I’ve put it up on my dropbox

https://www.dropbox.com/scl/fi/f1ri4fotzokgi3a8vlpjn/pi-eigend_3.0.0-beta-3.deb?rlkey=xu02agiiqtt9jg9bujqzl0s30&st=m5ejz09y&dl=0

my build comments, what has changed, etc…
https://www.dropbox.com/scl/fi/tzq8v9oumvl1aa3kp2axp/UBUNTU_FIXES.md?rlkey=2p3qevzioyi3n3ie0q21xdmi2&st=nxz6sqql&dl=0

I’ve been working on this with my spare time over the last couple of months, and everything passes my tests with the exception of the plugin scanner. That’s probably because I’m using jBridge and a wine env to load win64 VSTs. But most linux users are using LV2, LADSPA, or LSP plugins anyway, so you can still try it from the command line, but on linux, the error window on launch is suppressed for now.

Added in a menu installer into the deb file, and got browser and commander working as expected.

You can look at the markdown file for more info if you are interested in the gory details. :slight_smile:

Anyway, I hope this saves some folk a bit of hair pulling or frustration.

So far I am pretty happy with the outcome.

I’ll look more into the plugin things over the next few months.

@thetechnobear - if this is of any interest to you, I can share the code / changes in a new branch, or push my version up to github if you’re at all interested.

3 Likes