EigenD 2.2.0 - breaking with the past ! (compatibility)

as many of you know Im working on a new release of EigenD.

primarily this has been instigated by support of apple silicon, however unsurprisingly this is also raising questions about support of ‘older’ technologies.

This is a topic Ive been considering for a while now, and when do we ‘break from the past’

Most of the following can be seen as Mac specific, however, really its not Windows and Linux also are seeing similar questions being raised, and also I do NOT want to start having differences across platforms.

really, Id like some feedback from users, how these changes might affect them

important note
most changes in a new version of EigenD are to support NEW platforms.
the older version of EigenD will still be available for older platforms so you will not be ‘missing much’ :slight_smile:
however… obviously, they will NOT be updated.


1. 64 bit support (vs 32 bit)

EigenD 2.1.7 was available as 32 or 64 bit.
my feeling is that most users are on 64 bit these days.

Im planning on dropping 32 bit support for simple reason it takes me a long time to complile/package and release each platform - so I want to only support the ones that are used by most users and are current.

this will happen for in 2.2.0 for macOS,
but I hope we can also move windows to 64 bit as soon as I sort out the usb driver, so it has a ‘stay of execution’ :wink:

note:
EigenD only support native architecture plugins, there is no bridging.
so 64 bit EigenD implies 64 bit plugins only!

2. OS Versions

for similar reasons to the 32bit/64 issue, and also due to dependancies on the juce sdk,
we need to keep pushing forward on which OS version we ‘support’.

for 2.2.0,
on mac, Ive moved this to mac os 10.13+
on windows, Im not sure we have to specify, but I think people are only running windows 10?
(certainly thats the only machine I have to test on)

3. VST 2 vs. VST 3

Steinberg have now officially dropped VST2 support.
also legally, you need a license to use the VST2 SDK, you cannot just use it on in open source projects.

ideally we should therefore drop VST 2 support , in favour of VST 3.
I suspect a fair majority of 64 bit plugins (see 1.) are also available as VST 3.
(given Steinberg’s move, I guess we will see vst3 support continue to grow)

EDIT: seems some newer plugins are now VST3 only, so VST 2 support will limit available plugins too.
(thanks @keymanpal for pointing this out, see post below)

4. Python 2.7 and 3.x

for 2.2.0 on the Mac, Im switching to use the system python 2.7 , this is 2.7.16

this is all part of the planned change to remove the dependancy on the EigenD-Runtime package, which is unsupportable.

originally eigend used 2.6, from a local build - but the experimental 64 bit build has been using 2.7.10 without issue.

using the supplied python will make for an easier install on macOS, and it is also the latest/last version of 2.x python.

for windows, we could also move to 2.7 and require users to install from python.org - this would give us synergy, as it also move windows users away from the eigenlabs supplied python to an ‘official release’.
(linux users already ensure python is installed from an official source)

my hope is to eventually move python 3.0, at this point windows users will definitely be required to install from python.org.

some of this has been discussed on other threads, but I think its important that I make it 100% clear, since I know changing compatibilty with things will affect users.

obviously the main goal here is to keep EigenD ‘current’ , it needs to move with the times, to ensure it does not become obsolete - and at the same time I need to keep the maintenance/dev effort to a level I can realistically support.

thoughts?

4 Likes

64 bit

OS Versions - 10.13+ is ok!

VST 3

works on both Win and Mac (newer plugins are now released ONLY in VST3, that is, dropping vst2)

2 Likes

you now have some plugins that do not provide VST2 !
(example out of interest? Ive not bought any recently :slight_smile: )

thats really interesting, since it means lack of VST3 support, means incompatiblity with new plugins, thats definitely a good reason to switch to VST3 (instead of VST2)

1 Like

The trend is in motion (drop vst2 for ONLY VST3

Plasmonic
https://rhizomatic.fr

1 Like

Just copying over infos from the EigenD - Apple Silicon - It lives! thread:
Some important companies that still have to update some of their plugins to VST3:

  • Native Instruments
  • Madronalabs

Additional candidates (at least couldn’t find a vst3 plugin option on first sight):

  • Spectrasonics (Omnisphere, Keyscape)

Apparently the VST3 license does not cover compiling VST2 hosts, and VST2 licenses are not provided anymore: Can I create VST 2 support for host application? (VST 3 license) - VST 3 SDK - Steinberg Forums
So VST3 would be the only clean way forward anyways.

1 Like

yeah, thats what i meant about the legal side.
(its been like this for a while now… so i think steinberg are doing this more carrot than stick :wink: )

1 Like

These updates are reasonable and welcome, especially from my Linux perspective.

What are contained in the EigenD-Runtime package besides the Eigenlabs-built Python 2.6?

1 Like

runtime package contained a python install, which included a few python packages (like wxPython)

the vsts, samples etc were all in the separate resouces package
the ‘driver’ for windows is also in a separate install.

for macos and linux, I know these were all optional since Ive personally not installed any of them for a very long time :wink:

note: I should also point out another reason ive not distributed these packages (runtime/resources) is I do not have the source for these packages - and given reasons stated above, its a waste of my time to have to recreate the package source.

windows, has unfortunately always been a bit different … thats why mid term id like to fix it.
unfortunately, I do not have the source code for the windows driver, and that creates some nasty dependancies.
fortunately, its possible that I can move away from that propriatary kernal driver, and move to using libusb - in a similar way to linux … this would break the interdepenancy, and move us to a similar situation to linux. (and also move to 64 bit)

2 Likes

Yay, that would be great! The current Windows driver can be a little - stubborn - at times. When initially installing it one has to find the right sequence of having the instrument plugged/unplugged/driver installed/uninstalled etc. so the driver doesn’t report “couldn’t load”. But once it works it fortunately works reliably - until the next Windows reinstall or so.
But libusb (and an open source driver) would of course be great! Is there a specific feature in libusb that has to be supported or is the existance of libusb for Windows enough? The latter looks good :slight_smile: Apparently there is now also vcpkg support available, so integration with Visual Studio might be easier (in the upper section they only talk about mingw): Windows · libusb/libusb Wiki · GitHub

1 Like

compiling/integrating is not an issue - I’ve had this working before.

the bit that was a bit fiddly, was the stuff surrounding setting up and zadig

I had this working, but it was quite a bit of faffing, and at the end I was a bit unsure which steps I took were necessary, and which were not…
so I knew, that Id have to redo it on a clean image to be sure what steps were required, so I could document and explain to ‘end users’
(which is what I never got around to doing, as reinstalling windows and dev environment is painful :wink: )

also, when I say it ‘worked’ , this was just quick development testing.
I didnt get around to doing things like running it for long periods, rebooting, connects/disconnects.
so its untested how ‘reliable’ it was OR the performance.

that said, Zadig & libusb are mature projects and have a wide userbase.
I think within the constraints it sets itself, its going to be as reliable as any other solution.

and really, we dont have a lot of options, Ive not got the time, nor frankly inclination to write a native windows driver … and we dont have the eigenharp windows driver source code, so no chance to update/recompile that.

but im pretty hopeful :slight_smile:

1 Like

Sounds promising! It seems to be possible to import ini files in Zadig, so the installation description might get shorter. Probably each Eigenharp/Basestation has a unique USB ID though(?), so the user might at least still have to select the right USB device manually.