3rd party vst support & implementation with DAWS

• Sep 17, 2019 - 20:28

I think it would be a great selling point for musescore to have 3rd party vst support. It would make it a better competitor with finale and sibelius.

Also it would be nice if musescore was nicer to work with DAWS. Maybe you could work with REAPER or something to find a way to implement musescore as a notation editor within reaper?


MuseScore is not for sale so no selling points needed ;-)

AFAIK all VTSs are propriatary software and the the way to communicate with them is only available by signing some Non Disclosure Agreement with their vendors, this in turn is an absolute no-go for an Open Source software like MuseScore

In reply to by Jojo-Schmitz

Well I know that I just meant like marketing against paid software.

Musescore does support plugins (like an automatic accelerando maker). What if the staff made a simple plugin that could be added to musescore that wasn't open source (but still free) but was separate from musescore itself so that way you could still add vsts via musescore and keep that non-disclosure agreement? Idk something along those lines?

In reply to by Jojo-Schmitz

oh okay, so then there isn't any way for musescore to add in vsts without having to stop being open source then for at least part of its code?

What about if musescore could work as a plugin within a DAW, that way the DAW sent the midi automatically to musescore and visa versa, so that way I could use my plugins and have a notation editor within one project?

In reply to by dmitrio95

Yes, but Steinberg requires "you" (the VST host coder) to release ypur program under GPL V3 (not 2!).
And, since VST works by dynamically linking plugin binaries into the host program you might get in trouble since many of the 'interesting' VSTs are binary only.

In reply to by rmattes

No, the SDK provides an “API surface / boundary” which is sufficient to solve as boundary regarding copyleft scope on the frontier between VST SDK and the plugin binaries.

This doesn’t change the fact that the SDK must be embedded into the host application (MuseScore, which is GPLv2-only) under GPLv3, which is not possible to legally distribute. (In theory, end users could compile it themselves, but given the typical MuseScore end user I doubt this would work considering most people even use prepackaged AppImages.)

Interesting: I warned about this over six months ago, you warned about this in 2019, @dmitrio95 (core developer) knew about this… and they still did it illegally: https://github.com/musescore/MuseScore/issues/7866

I'm just curious about this topic, so I ask.

How can communicating with an external program (i.e. a VST plugin) have any consequences on the license of an host program? Aren't they just TWO INDEPENDENT pieces of software just mutually communicating data and commands via some sort of API? Isn't it just like when I compile an executable that "runs" in a Windows environment? AFAIK, if a program of mine just #include and calls (let's say) CreateWindowEx(), I'm not making any contract with anyone, I suppose. Should MuseScore communicate with a VST plugin, wouldn't it just be the same situation?

Have to admit that I'm rather ignorant as regards this topic. Please, give me some (basic) hints.

In reply to by rmattes

Looks like I'm not able to understand such weird characteristic. Even when I make (just as an example) an API call to GDI+ I'm invoking a dll in the same way. Should I suppose that my programs calling GDI+ API are in some way partly property of Microsoft? I'm not arguing, really I can't get this point.

In reply to by Aldo

I am absolutely not a lawyer, but if my understanding is correct (it may appear to be wrong), then the situation is the following.

The issue we discuss here is not about that your program becomes someone else's property, it is your program after all. But when you or some company distribute a program, some license agreement is made between the persons who receive a copy of the program and who give or sell it. This license may (or may not) restrict usage of the program under some conditions (although this possibility may be limited by law) and your ability to distribute it or its derivative works to other people. The issue with VST is not really in that someone will use VST host with proprietary programs: if I am correct, GNU GPL doesn't limit usage of the program (but imposes some restrictions on how you can distribute it and derivative works), and VST plugins' licenses are unlikely to limit their usage with some specific VST hosts. The real issue is that in order to enable VST support in MuseScore VST SDK must be used in it which seems to make MuseScore a derivative work of that SDK (as well as of many other libraries that are used by it). The license of VST SDK would then require to switch the license of MuseScore to GNU GPL of version 3 (version 2 of this license is used currently, and these licenses are not compatible between each other). While theoretically switching to GPLv3 can be performed (although it would require some work to replace or change the way of usage of some GPLv3-incompatible third-party libraries used by MuseScore), right now licenses of MuseScore and VST SDK don't allow to distribute a program which would use both MuseScore source code and VST SDK. One can create such a program for a personal usage (or some organization's internal usage) provided this program won't be given to anyone else, this sounds highly impractical but should be perfectly legal.

In reply to by dmitrio95

Ah! Many thanks, dmitrio. Now things make some sense to me: looks like the problem doesn't lie in VST's themselves, rather in "embedding" the VST sdk in MuseScore. It is that sdk that requires specific licence and bla, bla, bla (legal jargon not included).

Do you still have an unanswered question? Please log in first to post your question.