3rd party vst support & implementation with DAWS
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 MuseScore is not for sale ;-) 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 Well I know that I just… by mnmwert
In reply to Plugins are plain text files… 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 oh okay, so then there isn't… by mnmwert
Seems like if your favorite allows one to write plugins that call external programs, you can do this already. That is, you could write a plugin for the DAW< or hire someone to do that. MuseScore can already do the communication from its end (sending MIDI data via JACK, etc).
In reply to MuseScore is not for sale ;-) by Jojo-Schmitz
VST SDK itself can be used in an open source software but the licensing issue still seems to exist: VST 3 SDK is licensed either under a proprietary or GPLv3 license neither of which is compatible with GPLv2 currently used by MuseScore, see the topic about VST SDK licensing.
In reply to VST itself is an open… 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 Yes, but Steinberg requires … 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
In reply to No, the SDK provides an “API… by mirabilos
Interestingly enough, Musescore 4 is planning to be a hybrid DAW, and claims that it will support vsts :p
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 I'm just curious about this… by Aldo
"How can communicating with an external program (i.e. a VST plugin) ..."
VST plugins are not external programs, they are (dynamically) linked into the host application.
In reply to How can communicating with… 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 Looks like I'm not able 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 If my understanding is… 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).
In reply to Ah! Many thanks, dmitrio… by Aldo
Exactly, I just tried to explain some details of why this happens (if I understand those details correctly, at least). But the key point is correct.