Request: MTS-ESP
Andreya-Autumn opened this issue · 21 comments
MTS-ESP is a new method of re-tuning software instruments. It has two advantages over older workflows.
1: All (compatible) software instruments are retuned simultaneously by one master plugin. This saves a lot of repetitive work loading scale files into each instance.
2: Tuning can change dynamically during playback. This is truly wonderful for working in Just Intonation especially, where we oftentimes want to subtly tune individual notes up or down depending on the chord being played. It also enables many other cool things, like gradually gliding from one tuning to another.
It is my perception that the microtuning-community nowadays feels that fully adequate tuning support means enabling both of the methods, scl/kbm files, and MTS-ESP. The latter is superior in the aforementioned ways, but many folks have years of experience with the former. Hence the request for both.
I understand there are some challenges to implementing this in a sampler. They would be the same ones as mentioned in issue #329, where I also just commented. If the issues of key ranges can be resolved, then it'd be wonderful to have MTS-ESP support as well. :)
Implementation is very similar to the Surge Tuning Library, instructions are found here: https://github.com/ODDSound/MTS-ESP
All the best!
Please note the core lib for MTS-ESP is not opensource.
This is an issue when building things together with GPL components.
Hi!
You keep saying that and as you know I am sure you are wrong. But that's a tedious argument.
So rather than argue that you are wrong, I decided to just make your statement false.
https://github.com/baconpaul/mts-dylib-reference
there is a fully open source implementation of the MTS intermediating dynamic library. Using it, I was able to make Surge XT tune using MTS ESP when using
https://github.com/baconpaul/simple-mts-main
which is a fully open source implementation of the MTS "Master" (namely a tuning provider).
Best
Well that is a new development that you made.
According to MTS authors in ODDSound/MTS-ESP#6 the official library is closed-source.
Yeah but that is dynamically loaded and can be subbed out with another. So after chatting with them I just made an open reference implementation.
it’s not as good as the closed source one, but surge isn’t as good as diva and we load diva in open source vst hosts.
I think practically most folks will use the closed source one but nothing stopping an enterprising developer competing around the open api if they want to improve it!
best
But most importantly it is now entirely possible to get a retuned synth using MTS esp with only GPL or mit software in both your compiled and dynamically loaded path. That’s really the point.
That is a grey are still at best. making a dummy/stub DLL and linking a GPL program to it, then replacing the DLL with a proprietary one.
In Germany we would say this goes "against the spirit of the law", as to say it is clearly made as a way to avoid what GPL requires, basically a loophole.
It isn't pretty and not everyone agrees this is a good approach.
That is a grey are still at best. making a dummy/stub DLL and linking a GPL program to it, then replacing the DLL with a proprietary one.
In Germany we would say this goes "against the spirit of the law", as to say it is clearly made as a way to avoid what GPL requires, basically a loophole.
It isn't pretty and not everyone agrees this is a good approach.
So if I load diva into Carla is that a GPL problem?
if you create a copycat of Diva that does no sound, integrate it in carla as official feature, and then replace the early dummy copycat with a proprietary version - yes.
Anyway the argument is tedious. You can get an entire MTS esp experience with fully open source software today and the software is all linked here. If you don’t like it that’s fine, but if you think it is false then you are just not reading the code in front of your face!
if you create a copycat of Diva that does no sound, integrate it in carla as official feature, and then replace the early dummy copycat with a proprietary version - yes.
I mean you are just making up stuff now. Which section of the license says that?
I dont see any implementation details in https://github.com/baconpaul/mts-dylib-reference/blob/main/src/mts-dylib-reference.cpp, it is all stubs.
am I missing something?
It’s not all stubs. It implements tuning!
MTS just shares a bool, an int and either one or 16 128 double arrays between plugins. That’s it.
I see, so that part is nice. Still won't work in bitwig and a few other scenarios because of plugin bridging.
IPC is not particularly hard, but it is tedious, synchronization is the tricky bit..
if you create a copycat of Diva that does no sound, integrate it in carla as official feature, and then replace the early dummy copycat with a proprietary version - yes.
I mean you are just making up stuff now. Which section of the license says that?
I mean if we just mimic proprietary APIs as open with the intention of replacing such bits again with proprietary things... that is running circles around the GPL no? It is all just a dance to not have to deal with opensourcing a little bit of code.
As I said, not everyone agrees this is a good approach. It is clearly made as a way to get around GPL, is it not?
The MTS stuff should have been open in the first place.
We cant package it on Linux distributions at the moment, for those running mostly opensource software it makes such integrations unwanted until the situation improves.
It’s an open api. The client and master api are fully open source which is why I could implement a client a master and an intermediate.
Should isn’t that useful a comment I don’t think here. Although I think I would probably have Mae the intermediate lib open also if I was running the project, which I wasn’t. I was just trying to once and for all close the salient question about whether you have a GPL problem when you can get a fully functioning system with all the code available under a GPL or more permissive license. And gave a worked solution of that to put that particular matter to rest
It’s an open api.
APIs are not copyrightable, we can reimplement them, so calling it "open api" is meaningless.
The client and master api are fully open source which is why I could implement a client a master and an intermediate.
this is a bit misleading. the end points that connect to the middleware are "open" yes, but the middleware (was) not.
Should isn’t that useful a comment I don’t think here. Although I think I would probably have Mae the intermediate lib open also if I was running the project, which I wasn’t. I was just trying to once and for all close the salient question about whether you have a GPL problem when you can get a fully functioning system with all the code available under a GPL or more permissive license. And gave a worked solution of that to put that particular matter to rest
your efforts are appreciated of course.
sorry for being harsh here, but it really pains me seeing opensource projects trying to quickly jump into integrations for things that were not as clearly opensource. there is a question of ethics here.
sfizz being an opensource project should target the opensource variant (you made) for MTS, disregarding the proprietary one. though of course it is not my call to make.
For sfizz there is zero difference. The plugins don’t compile in the library.
MTS-ESP uses a BSD Zero Clause License
I asked ChatGPT "are GPL licenses compatible with a BSD Zero Clause License"
The answer:
Yes, the GPL licenses and the BSD Zero Clause License are generally considered compatible.
The BSD Zero Clause License (also known as the "0BSD" or "FreeBSD License") is a very permissive open-source license that allows for free use, modification, and redistribution of the software without any restriction. The license essentially puts the software in the public domain.
The GPL licenses, on the other hand, are a family of copyleft licenses that require derivative works to be licensed under the same terms as the original work. This means that if you use or modify software that is licensed under the GPL, you must also license your derivative work under the GPL.
Because the BSD Zero Clause License is so permissive, it does not impose any additional restrictions on the software, which means it is compatible with the GPL licenses. This means that you can include BSD Zero Clause licensed code in a larger project that is licensed under the GPL, without violating either license. However, it's important to note that if you modify the BSD Zero Clause licensed code, you must still comply with the GPL requirements for any derivative works you create.
err since when is ChatGPT a lawyer or expert on any specific field? ChatGPT tends to give quite some B-tier replies, if not worse sometimes
AI apparently doesn't use logical fallacies
your response however contains an Appeal to Authority and an Ad Hominem
is the reply to the question asked of ChatGPT accurate or not?
Recentering the thread a bit: thanks for the info, I remember we talked about this before and I'll look into it if I find some time! I'll evaluate the licensing situation since I definitely don't want to taint the library, but I haven't looked deeply into it yet.
Thanks all for your arguments!