ok, I’ve looked into this …
pretty much the short answer is… this is the way it is!
Steinberg have officially stopped vst2 support
from juce :
namespace Vst2
{
// If the following files cannot be found then you are probably trying to build
// a VST2 plug-in or a VST2-compatible VST3 plug-in. To do this you must have a
// VST2 SDK in your header search paths or use the "VST (Legacy) SDK Folder"
// field in the Projucer. The VST2 SDK can be obtained from the
// vstsdk3610_11_06_2018_build_37 (or older) VST3 SDK or JUCE version 5.3.2. You
// also need a VST2 license from Steinberg to distribute VST2 plug-ins.
#include "pluginterfaces/vst2.x/aeffect.h"
#include "pluginterfaces/vst2.x/aeffectx.h"
}
basically this means if you want to provide VST2 support, you have to use an older vstsdk
(its unclear why those older source files are still in the steinberg sdk, but they cannot be used as the c interface files are missing)
VST3 suppport - ok, so this appears to work
BUT - we cannot have both VST2 and VST3 (argghhhhh)
the reason is simple Juce vst3 support is only compatible with the newer VST3 sdk… and you need the older sdk for vst2 support.
Ive just had a quick compile/test of VST3, and they do appear to work.
(I could scan, and instantiate - I didnt actually play them - but I pretty sure that’ll work)
so we are going to have to make a decision… do we move to VST 3 support?
given 2.2.0 is moving to newer tech, Im quite tempted to use this as an opportunity to move to VST3 as well…
now I dont think this is a big issue for mac users , since they also have audio units, but windows users might have issues?
(and I want to keep windows in line with mac, Im not splitting off in different directions!)
yeah, Im a little ‘concerned’ about lack of vst 2 support…
could a few of you look at how may VST plugins you REGULARLY USE would be afffected.
for windows users its simple…
how many 64 bit plugins that are vst 2 only?
for mac user , its a little more subtle
how many 64 bit plugins do NOT have vst3 or AU?
how many 64 bit plugins do NOT have vst3 but do have AU?
the reason I ask is simple… on my quick look.
UVI Falcon is VST2 or AU.
so for mac users, its not an issue - but for windows users the AU support is not going to help much
this is why Im concerned, as UVI is a pretty big developer, so I was quite surprised they are not supplying vst3 - but they are in the minority (for me)
EDIT: hmm just noticed madrona labs are also not vst3 only au
EDIT2 :
Ive created a separate post about ‘compatibility’ here
I know users get (understandably) upset when backwards compatibility is dropped.
so I think its important to make sure the discussion is very clear.
(Im concerned a few might miss it in here, since windows/linux/intel mac users … my thing this topic is irrelevant given the title :))
A poll sounds good.
Just checked for the plugins I usually use: Pianoteq, u-he, Madronalabs, Audiomodelling and Roli/Fxpansion synths all seem to offer VST3 variants by now. But I rarely use Windows for Eigenharps these days and I don’t host plugins in EigenD atm. anyways, so it makes no difference for me.
yeah, I dont host vsts in EigenD much either… so yeah, broader concensus is required.
poll is probably the wrong word … software development really isnt democratic
one day, we will almost certainly have to move to vst3, and as mentioned in other post - legally we already should - but Id still like users to know whats going on and why… and I guess should we just wait n’ see for a little longer.
anyway, its good to know, I can reasonably easy switch us from vst2 to vst3, when the time requires.
BTW: do we have a list of what is required to be installed to compile EigenD on windows 10?
are the details in the EigenD repo up to date?
(Id like to make sure its clear in the repo, if its not already)
Yes, pretty much. Finding Visual Studio 2015 is a few clicks more these days (they insist on trying to convince you that what you really want is VS 2019). And for Wix one has to create a bin folder where the binaries have to be copied in manually (my guess is that a very old Wix version might have been structured like this. Downloaded the current 3.11 and the 3.9 version indicated in the build instructions, both have the binaries in the root folder). And as written above, one needs an old copy of the VST SDK.
Beside that it compiles out of the box.
Could look into upgrading EigenD sources to VS2019 (doesn’t seem to work out of the box). But as long as VS2015 still works with the latest Win10 version (which is the case), this is more nice to have.
however, im 99% sure Madrona Labs are not supplying VST3 either,
so its not just uvi.
yeah, happy to stay with VS2015 if its available.
Id hope the source code is getting more compatible all the time to newer compilers (like VS2019), linux really pushed it forward due to new gcc versions - and apple is following with its clang version.
generally newer compilers just become increasingly strict.
e.g. the latest build failed due to some old code that was updating ‘const’ objects via pointers, so not allowed , but only latest compiler detected it.
Ah, sorry, right, Aalto and Kaivo seem to be VST2 only while Aaltoverb is VST3 only.
Good point regarding NI, Super 8 seems to be their only VST3 plugin atm.(?)
But Kontakt cries for 64 bit with support for more RAM anyways, so I would wonder whether anybody is still hosting this inside EigenD (on Windows)?
Wix 3.11 (latest version) or 3.9 as per eigend
VS2015 community edition w/ update 3 (64 bit?) (im assuming will also compile 32bit)
Direct X jun 10 ( is this still required?, possibly remove if target windows 10?)
nsis 3.0.6.1
steinberg, we have discussed
given all the downloads, I might down last VS community edition while im at it…
important note: I cannot do 64 bit windows build yet… I need to migrate to libusb to do this, and also confirm what the install requirements are - it was a bit messy last time I tried.
but ultimately I would like to do this, so I can drop the windows driver requirement
similarly, I might see if i can move to using python.org 2.7 install for windows, so that I can ditch the run eigend runtime package requirement (like mac/linux)… kills eigencommander/browser, but for now thats life
Wix: used 3.11, 3.9 should also work though
VS2015: Visual Studio Express 2015 for Windows 10 (x86 and x64) - Web Installer (English) (link is behind a login wall: https://my.visualstudio.com/Downloads?q=visual%20studio%202015&wt.mc_id=o~msft~vscom~older-downloads)
Direct X: didn’t install this, installed the Windows 10 SDK instead (which can be installed by selecting the option in the VS2015 installer)
nsis 3.0.6.1: think that is the version I used
Just a hint: Better don’t assume a python.exe on the system path as that is a Python3 interpreter on most machines nowadays.
A good search heuristic might be:
a config file that tells where to look for Python 2.7
get the install path from the the registry: Computer\HKEY_CURRENT_USER\Software\Python\PythonCore\2.7\InstallPath
c:\Python27\python.exe (default)
Or bundling up Python with the EigenD binary might be an option. The full Python 2.7 installation seems to be <70MB and stripped down to the basics (no docu, no test suite, no tcl-tk etc.) it’s about 30 MB uncompressed.
The disconnect - reconnect-issue; I’ve checked and have the same behaviour on 2.1.7, so not really a 2.2.0-thing. Nor does it bother me. Here is as much info as I can think of anyways:
My MBP came with Catalina and I have had issues since then. EigenD version/setups was the same on my 2015 Mojave (iirc) MacBook Air. So I guess it could be either Catalina or the 13" MBP (2020). Or something to do with usb-c adapters, perhaps? (I have the official Apple adapter and a Satechi hub, and they behave slightly differently.)
Small Basestation. USB Device shows up as “PSU-MM” both before disconnect and after reconnecting. After reconnecting, it shows this:
PSU-MM:
Product ID: 0x0105
Vendor ID: 0x2139
Version: 0.01
Speed: Up to 480 Mb/s
Manufacturer: eigenlabs
Location ID: 0x14340000 / 40
Current Available (mA): 500
Current Required (mA): 100
Extra Operating Current (mA): 0
The log is for this:
blank setup → add Alpha Manager->Disconnect and then reconnect USB. The process sample is taken after that.
Perhaps slightly related:
The Pico isn’t working at all on this mac. But again, it doesn’t bother me (I use it on Win10 anyways), so I haven’t investigated. If you want it I can do a similar report on that.
@Kai , no big clues in the logs - I’ll try it with my small basestation and see if i can reproduce.
@NothanUmber , there already is an environment variable (PI_PYTHON) that is ‘half’ used , so I will make work properly when the time comes.
I did spend a while trying to get python27 working on windows.
I can get it most of the way BUT like 64 bit windows, it is now stuck on the library used to connect to the window driver, which has a dependancy to python26.lib
so… python27 is now on hold on windows, until 64 bit windows, where i will need to remove that lib dependancy entirely.
thats not happening for 2.2.0, and it may be by the time I do that, I just go straight to python 3.x
so for now windows stays with the eigend-runtime.
(python.org doesnt not even have binaries for 2.6 anymore)
Python 2.6 can be downloaded from here: Python Release Python 2.6.2 | Python.org
But at least for this version Windows users wouldn’t really win anything (except not having to install the runtime package which most should have installed at this point anyways) and just lose EigenBrowser+EigenCommander+Alchemy, so using the prepackaged Python 2.6 with the extra packages at least until there is an actual advantage (like 64 bit support) sounds plausible.
