The future of VST2 support in JUCE


#11

Thanks guys, I’ll try the changes soon.

However, I think having VST2 now called “VST (legacy)” in the Projucer might not be the best choice, since Ableton Live 10 on Windows is today only compatible with that “legacy” format :innocent:


#12

This is a good step forward! I take it this means users will no longer be required to download, install, and set paths for any plugin SDKs except AAX?

When I’m trying to teach new users about plugin development with JUCE (such as when I was assisting with a live workshop at University) setting up the VST SDK + Projucer paths always threw a wrench in things.


#13

Interesting update and I’d love to be targeting VST3 as standard, but the lack of support for dynamic parameters is blocking me for now (see updateHostDisplay() VST3). Do you think that’s something that might be looked at between now and October? Any insights into how well supported the kParamValuesChanged call is in DAWs?

Having said all of that, I guess I’m probably going to need to support VST2 for as long as Ableton doesn’t make the move to support VST3.


#14

It’s a pain supporting multiple formats. Perhaps it’s time to “deprecate” Ableton Live :wink:


#15

VST2 is fully functional simple format being removed due to bureaucratic decision.
I think it would be a good time for RTAS removal deadline.

  • RTAS unlike VST is only 32-bit
  • RTAS requires compiled library that’s becoming trickier and trickier to build under Mac each release.
  • RTAS unlike VST isn’t maintained by any active host as an exclusive format (versus VST/Ableton).
  • It’s worth JUCE devs would put their resources on adding newer useful formats and extensions than maintaining 32-bit deprecated format.

#16

Just seen this post. Could VST errors after latest pull be related? thx


#17

It is going to get even more tricky to build RTAS soon, see this note on building 32-bit targets in XCode 10 (public reference), I don’t suppose discussing this in any great detail is allowed during the beta as it’s under NDA.


#18

They have made some public statements about the future of 32-bit apps…

Rail


#19

If you guys want to talk about RTAS that’s fine, but please don’t hijack this VST thread!


#20

Is this compatible with Steinberg license? Providing the VST2 headers is currently the subject of DMCA takedown notices on github (yes, they provided a list of all repos on github that provided the headers and they CANNOT stay there…)


#21

Roli and Steinberg have obviously done some kind of an agreement about Roli being allowed to temporarily distribute the VST2 headers.


#22

I don’t think there is such an agreement. Or I’d like to know how they managed that when Steinberg is clearly heavily bent towards killing VST2 (as if it works that way): https://github.com/zeromus/openvi/issues/1


#23

This is the Steinberg license (emphasis is mine):

LICENSE
© 2015, Steinberg Media Technologies GmbH, All Rights Reserved

This Software Development Kit may not be distributed in parts or its entirety
without prior written agreement by Steinberg Media Technologies GmbH.
This SDK must not be used to re-engineer or manipulate any technology used
in any Steinberg or Third-party application or software module,
unless permitted by law.
Neither the name of the Steinberg Media Technologies nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.

If ROLI and Steinberg have a written agreement, ROLI can do whatever they want.


#24

Oh yes, I agree, but I don’t think there is one. There is no reason why Steinberg would do this given their current behavior.


#25

The VST2 headers are under the following license:

// LICENSE
// (c) 2018, Steinberg Media Technologies GmbH, All Rights Reserved
//-----------------------------------------------------------------------------
// This Software Development Kit may not be distributed in parts or its entirety  
// without prior written agreement by Steinberg Media Technologies GmbH. 
// This SDK must not be used to re-engineer or manipulate any technology used  
// in any Steinberg or Third-party application or software module, 
// unless permitted by law.
// Neither the name of the Steinberg Media Technologies nor the names of its
// contributors may be used to endorse or promote products derived from this 
// software without specific prior written permission.

Thus, they cannot be redistributed under GPLv3. This means that JUCE’s develop branch is no longer GPLv3.


#26

There is no way ROLI would be so stupid as to do something like this without a prior written agreement. Anyone who has seriously developed audio software is aware of the license stipulations of Steinberg SDKs.

Don’t forget that JUCE has been around for a long time now and has had a massive impact on the audio software industry. I guarantee engineers at ROLI know engineers at Steinberg and they both agreed it made sense before they made this move. Then they had their lawyers go into a room and do whatever it is lawyers do and here we are.

That said, if someone from ROLI could confirm this, then we could all stop debating :wink:


#27

Yes, we’ve discussed this in depth with Steinberg and they’re happy for us to distribute these files as part of the JUCE repo.

But just for clarity: we’re only delivering these files to you - obviously we don’t own the copyright of their content and we’re not in any way claiming to offer any kind of special licensing arrangement for them just because they’re in our repo. Anyone who has worries about how the VST SDK license interacts with their own legal situation would need to discuss that with Steinberg directly.


#28

ROLI cannot claim that JUCE is GPLv3 on one hand, and then ask us to discuss legal matters with Steinberg on the other hand. That doesn’t make any sense.

When someone makes a fork of JUCE on GitHub, they cannot selectively exclude the VST2 headers. This means that anybody who presses the “Fork” button on https://github.com/WeAreROLI/JUCE is infringing Steinberg’s license. Or do you expect them to contact Steinberg before pressing the “Fork” button?


#29

Sorry, but I can’t really see any other option - it’d be highly inappropriate for us to comment on what Steinberg’s license permits you to do with their code!

Nobody ever claimed that ALL the files in the JUCE repo are GPLv3. Yes, our bits are GPL, but the repo has always contained other 3rd party libraries which are not our copyright, and which use other licenses (generally more permissive).

The JUCE repo is a handy way to download a collection of code that you need to build JUCE apps. But doing due diligence on all the content that you’re using is your responsibility, and we can only realistically help you with questions relating to the bits of it that we actually own!


#30

It seems like someone has been scanning Github for VST headers lately and issuing DMCA requests. Does this mean that any Juce based project could potentially be flagged? Having to manually remove the files would be a huge pain.