I’ve noticed there seems to be extra testing and support to make your modules work all the time in the VCV VST. And others sound at least conflicted with making free software for run in a paid platform.
So - wondering if anyone has done this? Make their plugin not load in VST, or made a paid version whose only “premium” feature is running inside the VST?
It’s an interesting question. There does seem to be a resistance, perhaps understandably, but from what I’ve seen the resistance is only from closed sourced developers, every time I have approached an open source dev they are happy to explore the problem. I know there is someone who isn’t very interested in solving VST problems even though they apparently have free access to the VST but they are making non-free modules.
I would be interested in answers to the last sentence, it seems that could be an interesting and attractive way to market plugins but I don’t know of any who have gone that route (the only one I’m thinking of in Stoermelder which appears to be the opposite in that some don’t work with the VST).
Yeah, I agree that there isn’t much chatter about this, so perhaps little interest. Of course we know a lot of “old timers” have left VCV entirely, but I don’t know the reasons.
All open source plugins distributed via the plugin manager must run in the VST. If they don’t (for whatever reason), it must get fixed.
Is that really true? I don’t see it written anywhere (for sure I could be missing it). So if one wants a business model like VCV’s own model, what are the options for plugin manager distribution of plugins that intentionally don’t run in a VST wrapper?
My 2 cents: if you understand the API and use it correctly, working in the VST/Paid version comes automatically. I don’t even know if there’s a way to make them NOT work in the VST/Paid version without ‘not working’ == ‘crashing.’ Is there even a way to for a plugin to detect that it’s working in the VST or not? I’m not a Rack Developer, so I haven’t delved into the API.
Taking a patch back and forth between the standalone and VST version seems like a pretty common use case, and breaking it deliberately seems user-hostile. It will cause unhappy users and more support work for the Rack team.
Does anyone really want this? Should anyone actually want this? It sounds like the kind of f*ckery a crank like Richard Stallman might come up with. Even he (or rather, the FSF, which has cut him loose based on him being a misogynist creep) hasn’t made it difficult for GPL software to work with closed source software.
Wow, how were we open source developers supposed to know this? When I was determining whether to port Purr Software Meander to V2, I was very concerned about what it would take to make sure it worked in the VST. I went as far as upgrading my Ableton Suite to V11 and verified that Meander did load and seemingly function in the VST. But I had no idea what I would do if it did not or if users started having problems with it and I had no idea how to even address such issues. I was told by one of the moderators “Don’t worry about the VST”. So, I have not!
How do developers know if their plugin fails to execute in the VST? Does VCV provide some specifics and recommendations in such a case? Is this what happened with my still pending Purr Software plugin update to V2.0.15 ? All the Github issue said was that the panel image appeared not to load on Linux. At the time I wondered if that meant the patch SVG or PNG load and if it was for the browser or the patch or perhaps for the build library panel image capture, or if it was VST related. I still do not have a clue.
Do you mean that the panel doesn’t load at all on Linux, or specifically that it doesn’t load in the VST on Linux? Or is that part of the clarification you’re looking for?
Yes, that is the clarification I was looking for. Not part of it, but all of it.
By the way, I made a slight change to the code and cschol said several days ago that it loads on Linux now. But, it has been sitting in the build queue for 5 days and I don’t understand why.
VCV Rack plugins need to run in VCV Rack. All of VCV Rack incl. the VST.
Whoever told you that should not have told you that, because it is nonsense (in my opinion). There are specific cases, like font reference caching, that will break the VST (as specified in the migration manual). Everyone should test with the VST.
You test with the VST. This is why plugin developers are provided with a VCV Rack Pro license. Also, the migration manual explicitly specifies the conditions to look out for. As we find new conditions, we can add those to the migration manual.
Your plugin has passed all of the integration tests and has been integrated. However, it has not been built for distribution, much like the other 6 plugins waiting in the queue. They will be built when the build managers get to it, usually once per week.
If you have any questions, please reach out.
Until @Vortico tells me otherwise, I am assuming this to be really true.
Email support@vcvrack.com to talk about business models.
I realize you are trying to help here, but that was not an answer to his question. He asked “how were we to know this”, and you restated your belief about this policy. But if the policy is not written down, and today was the first time it was ever verbalized, it’s natural to ask “how would we have known this”.
i.e. he was not asking “what is the policy”, but instead “how would I have known that is the policy”.
I just followed VCV Manual - Migrating v1 Plugins to v2
I did the font changes, etc. But, VST is not mentioned.
I am indeed trying to help. There has been no need for a policy since noone (to my knowledge) ever wanted to not have their open source plugins run in the VST. That was, of course, before you put this idea out there. So, until further notice from Andrew, I will do what I have always done and that is make sure the plugins run in the VST.
No, but it mentions this:
The DAW plugin version of Rack uses a different OpenGL context each time the plugin editor window is closed and reopened.
DAW plugin version = VST
I understand now and I know you are trying to help. I’m just saying that nothing anywhere seemed to say that we must test under the VST. Is there some document that explains how to check within the VST?
No. The main issue we know about is the font referencing.
To test:
I probably took the moderator too literally.
“My pleasure Ken. I wouldn’t worry too terribly much about the VST. Every single developer other than Andrew is going to have maximum a few weeks experience of what will break and how. And users will be at least a bit understanding because of that I feel.”
Yep, that is what I did back in November or December. I paid $186 to upgrade my Ableton Live Suite from V10 to V11, without knowing at the time if that would work as a DAW host for the VST. So, it is not as if I was trying to not do anything. I was trying to do the right thing, but could find nothing that told me what the right thing was, other than the migration document which I faithfully adhered to.
All I’m saying is that communication is important. There is room for improvement on communication from every perspective. Thank you for explaining.