EigenD 3.0 - Beta-2

Eigenharp
121

if your fork is available, I will take a look when I do the work on linux.

some observations:
interesting about python 3.14 not being available, I’ll wait for that, Im not going back to 3.12 :laughing: … gotta move forward.

app_commander/app_browser,
my issue as far I remember is some of the dependent libraries weren’t working / available, but that may be a platform specific thing - in particular mac.
but I’ll take a look again…
that said, I do really want to kill all python UI, Im much more comfortable with python being backend only.

other fixes, I’ll look at one by one… Id guess, many have just been exposed by linux, so are present… but perhaps benign, good to have - as long as they dont break other things :wink:

so yeah, overall, if there is a fork - I wont ‘take the changes’, but rather, would cross-reference what I do against them - as some may be ‘platform specific’.

the python 3.14 is a bit surprising… I guess, I though python.org would ensure, there was a build even for older unbuntu versions.
oh, well, usual fun n’ games with linux and various distros :wink:

122

Hi Mark,

Thanks for the feedback

I’ve set up this fork on github

You can browse at your leisure. :grinning:

1 Like
123

One update…

If anyone wants to compile their own, I got VST3 plugin support working on Linux, and fixed a deadlock condition in the scanner UI under ubuntu linux. So you can now successfully scan for plugins and load linux VST3s, or even windows VST3 using Carla.

This is experimental, so I haven’t made a release yet, but you can build from the current code and play with it.

Right now there’s no support for LV2 or CLAP plugins, due to the JUCE version not supporting it. I can put in extensions to support them, but it’s a heavier lift than I expected. When I get them working, I’ll do a new release and post binaries to the github. That may be a while tho. There’s a lot of work to do to make them work. Likely JUCE will support them sooner than I get this done. LOL

VST3 for linux has the most mature support right now, so I’ve limited it to that for now. It’s the devil I know.

Anyway, if you’re running Ubuntu or Debian on x86_64 or amd64, and feel like building from source, VST3 support is now working.

:slight_smile:

2 Likes
124

Just thought I’d update here. I’ve updated the linux build at GitHub - amplogik/EigenD-Ubuntu: A fork of https://github.com/TheTechnobear/EigenD with fixes and changes for Ubuntu Linux 24 or later · GitHub with auto detecting python versions in build, and added LV2 and LADSPA support. There is a release with downloadable deb files. Recommended OS Ubuntu 25 / 26 LTS or current Mint if you use those files, tho likely any current Debian distro will work. Haven’t tested installing those debs tho, so I’d recommend building from source. See the updated README for requirements.

1 Like
125

Cool, now Ubuntu 26 is released, with python 3.14 , I hope to sort this out after Superbooth.

Also I’ve been messing about with the windows build too.

2 Likes
126

Note, no CLAP support yet.

I looked into it, and it’s a pretty heavy lift as there’s no native CLAP support in JUCE yet. I see a path, but I’d basically have to build an entire new subsystem for JUCE that would probably take a few weeks which I don’t really have the time for, and might be wasted effort.

CLAP support is already on the roadmap for JUCE 9, and there’s every reason to think they’ll have it built in before I finish off my extension.

So I think the smart play is to wait for JUCE to officially support CLAP rather than me rolling some hackerware that becomes redundant in a few months anyway. LOL

127

Thanks a lot! My TAU wasn’t working properly, and I thought the problem was the Base Station, but with this new version of EigenD it is working great again.

I mostly use the MIDI setup, which I modified in the Illuminator so I can light up any scale and transposition I want.

3 Likes
128

I found a bug in the usb handling on Linux, where the base station could get wedged across reboots, and power loss, resulting in losing control or tonic lights not coming back.

I just patched it and created a new release, I’d advise updating to it. Should just install over your existing one

3 Likes
129

cool, I’ll bring in this change to main repo
(though, I’ll make it unconditionally, Id like it ‘exercised’, rather than be a workaround)

Importent note:
the libusb implementation has not widely been used, as its only been used on linux platforms - though it will be being used the next windows release.
for me, that largely, been on ‘embedded systems’ (eg. eurorack modules), which obviously have a different (power) lifecycle.

kind of , but not 100%, related…

I’ll also mention, many years back when I was using this on a rPI - it was very sensitive, to the kernel version e.g. every time i upgraded there was a chance it would stop working - variations included :

  • working in all configs
  • only working without usb hub
  • only working with (powered) usb hub
  • not working at all

note: I mainly test this with the pico at the time, so could have been power related as well.

that said, I think this was mainly to do with the rPI SOC and its chipsets, other SOCs tended to be more reliable (well, actually they just worked or did not ;))

I did low level usb debugging, getting traces from kernel, and issues seem to be there, rather than the libusb stack

but just something to be aware of, as it was a linux specific issue - even though, likely more SOC chipset specific that linux/libusb

3 Likes
130

I’ve added to main build commit

note: I did not cherry pick your commit, as I did want the env var check, nor so much commentary. so its just a copy paste of the main change.

a few notes, whilst I reviewed this
a) I will be renaming this file to (probably) pic_usb_libusb.cpp , when it starts being used for other platforms.

b) check of if(status != LIBUSB_SUCCESS) , seems a bit undefined if continuing is the correct action.
I’d have assumed this is a failure condition, and so, essentially open is failing (i.e return, not continue)
however libusb documentation is unclear, so for now, its ‘ok’, its (hopefully) the same flow as if reset was never called? (but thats a big assumptions ;))

c) libusb_reset_device behaviour appears to be platform specific.
its not implemented on windows (hence rc is important there?), also some macOS versions have had it as a no-op.
I think, I might (mid-term) make it so EigenD can optionally use libusb on all platforms (mac,windows, linux), this would enable me to ‘exercise’ it more, and so get more stability/confidence.

d) I need to review this initialisation more generally.
libusb has some other related init functions, linked to usb ‘set configuration’ and also you can use ‘check connection’ to see if this is necessary.
so, I’m not sure if ‘libusb_reset_device’ is a bit of a ‘sledge hammer no harm approach’, and there may be more appropriate initialisations (esp) for other platforms , see (c).
but I need to get this running on multiple platforms to check this out, again as per (c)

anyways, thanks for the heads up… anything we can do to solidify libusb is going to be huge for the future as we become more dependent on it.

very important note
macOS has, yet again, broken my EigenD build, due new version of clang - so this has not been tested, released. Im going to fix eigend build - unfortunately, thats a bit of ‘effort’ as its also affecting juce etc, whilst not ‘difficult’ its also not 100% trivial, as could have unwanted side effects

1 Like
131

As far as I can tell, libusb_reset_device doesn’t really need to be called on windows or mac as the native usb driver effectively does that by default when starting EigenD. So it does appear platform specific.

I have had the issue on rPI 3, 4 and 5 running Raspbian, but because it wedged silently, I didn’t realize what it was. I was convinced that it was cable or hardware related.

So it does seem to be a linux specific bug, but even on SoC platforms like the rPI. It was just less frequent on the SoC setups, likely for the kernel reasons you mention.

I don’t have a pico, so I’ve never tested with that BTW.

And yeah, reset device is probably a blunt insturment, but for me it was the only path that worked to recover the correct behavior on the base station, other than moving to my mac, staring EigenD there, having it come up properly, then moving back.

Thanks so much for looking at this!

:slight_smile:

1 Like
132

yes, but I’ll be moving windows over to libusb, so it does matter (mid-term)
( I won’t ‘move’ macOS to it, no advantage, but id like the option to run it, as its easier, for me, to debug etc on mac)

I need to do this as we do not have the source code for the windows driver (it was not open sourced, as was developed by 3rd party not eigenlabs). so to move to 64 bit and arm - a new solution is required :wink:

btw: for this reason we don’t know what windows does (only mac).
the ‘driver’ you see in the EigenD source code, is actually not usb at all, it just wrapper, that talks (via shared memory, iirc) to the custom kernel driver that does the usb protocol.
iirc, this is because, at the time this was done, windows didn’t offer ‘user land’ drivers, so you had to create signed kernel drivers.

as for the rPI, its not the same issue, as the pico is bus powered, so could not hold state, and would fail on very first attempt…
its been a while since I looked at details, but basically it was to do with malformed isopackets, we’d start getting zero byte packets back, rather than actual data… I briefly look at the kernel source, and it appeared as some point the data was coming in, but for some reason not getting copied.

given it would work perfectly on some versions of the kernel, then next version would break it (without obvious changes) - I suspect it was a timing issue.
ofc, a low powered processor, is more susceptible to this.

1 Like
133

That makes sense. Be interesting to poke at libusb on windows over the weekend and see hiw it actually behaves on windows.

Day job involves USB hardware commonly, but we wrote our own custom drivers, so I’ve really no experience of libusb on windows.

Given what you outlined, it’s likely that some version of restarting may be needed in somw conditions if not natively handled in the OS. Or, at least important to investigate.

appreciate the feedback and deep knowledge.

Cheers!

134

I’ve had EigenD w/ libusb working under windows already, but it was done on ‘test’ branch - just as a proof of concept. - its just a few lines of code and a bit of Scons.
the main issue is libusb is not natively supported under windows, so you have to use one of the 3rd party drivers - iirc, I used libusbk
it was ‘fine’ but its not really an ‘end user’ experience to install, Id either need to do work on a custom installer, and/or dome detailed documentation.

but windows, generally needs a tidy up in the dev setup, so I put it on the backburner.

but yeah, it works under windows, that much Ive already proven :slight_smile:

2 Likes