It may be, but why do you say that? It’s not obvious to me why this is.
Patches made in the free version might not be able to be opened in the VST version because the modules are either not available at all, or you need to pay to use them. And because it would take up double the disk space.
And it might also then open the door to the opposite scenario - some developers arguing that they only want their plugins to be used in the paid version - perhaps to make them more exclusive or whatever.
And it would almost certainly lead to more ‘freemium’ modules - so there would be a free version and a paid one with more features - not that there’s anything necessarily wrong with that - it’s exactly what we do with ShapeMaster. But ShapeMaster was always intended to be commercial, and the free version is like a (slightly) feature-limited, never ending demo that is also very capable in it’s own right. But you might find devs removing features from existing modules in the free version that were already not that feature rich to start with.
1 Like
Would it be a good idea to start thinking about having multiple ‘rings’ for plugin releases and updates?
For instance, Hora 2.0.0 was just released and broke Rack. A scenario like that, when you have a bigger DAW-centric userbase (who, let’s be honest, are on the whole less likely to be engaged with the VCV community) could cause an avalanche of support issues, not just for VCV but the plugin devs themselves, making it more likely that those off-colour complaints occur.
Have the default ring push updates a few days later than ‘brave and fearless’ and it gives time for the community to identify and devs to fix whatever the problem is.
4 Likes
I’d say so yes. In fact I’m really surprised this didn’t happen before the release of Rack 2. I’m sure there would be plenty of volunteers from within the Rack community who would be willing to act as a first line of defence. They would expect things to perhaps be a bit buggy and would just report back with issues rather than kick up a stink. I reckon it would be good to have maybe 100 or more of them, with a good spread of Platforms, OSs and DAWs etc, who got new releases a few days before the user base at large.
One of the problems Rack faces right now is getting the blame for problems with 3rd party developers code (like the Hora example you mentioned). Users just see Rack crash, they don’t know it was a particular plugin that caused it. And when you have so many different developers submitting code to the library there should be some kind of check/process in place to prevent code that causes Rack and DAWS to crash from reaching the main user base, both to ensure a better user experience and protect VCVs reputation. Users are a lot less forgiving about this kind of thing when they have paid good money.
3 Likes
It might be worth splitting this part of the discussion about release rings, into a separate thread. As a dev, I think a beta test ring might be a good idea. I try to make sure my code is stable before I release, I’m sure we all do, but I don’t always get it right, and I can’t test on a Mac, and I don’t have a saw daw, so I can’t easily test in the vst. Having a semi formal test community would be helpful
2 Likes
You have more confidence in this than I do. I’m always really interested in new modules and have beta tested quite a few for people, but I wouldn’t want to just be beta-testing en mass- when I’m sitting down for what’s not exclusively a development/testing session with Rack it’s because I want to make music. Things crashing would be really, really annoying. Sure, some people may turn on the dev ring/channel at first, but I don’t think it would get much use long term.
1 Like
Every dev needs a saw, 
and a hammer!
2 Likes
Submarine Audio Workstation?
3 Likes
Agreed, we have definitely strayed off topic.
1 Like
It might not be public but there often is a “first line of defence” - many devs send to a small group of testers before they push to the library.
1 Like
I should probably open a new topic in that case 
2 Likes
Hopefully long-term, VCV would have the funds to pay people to do this job. But somethings got to happen in this regard otherwise EVERYONE is permanently in the dev ring…
1 Like
some interesting points being raised here…
I completely sympathise with @synthi point that ‘pro’ users were being offered ‘profession support’, and somehow believe this included 3rd party modules.
generally paying for software will result in that ‘entitlement’ as well, … and I think that effect, has perhaps been underestimated / miscommunicated.
the issue here is, new users (*) may not understand the dividing line (as long term users) between 3rd parties and vcv,. theoretically this is a non-issue, if I go complain to Ableton about a VST, they are going to clear that up pretty fast - hosts are not held responsible for plugin, nor vice versa. (and yeah, I know there are grey areas at time… but generally users understand there are two parties at play)
this is well understood by electronic musicians, but if we look at the number of posts we have on this forum (e.g. modules not working from v1->v2) it shows that message is not clearly understood. … perhaps new users do not see modules quite like plugins - if not , why not?
however, I completely disagree that module developers should somehow decide, what hosts (vst/standalone) , should or should not exist… it should be a free ‘standard’ (even free of vcv !) the reason VCV has been so successful (over other virtual modulars) is the lack of barriers, and openness… suddenly now changing that ethos, I suspect would be detrimental to the whole ecosystem.
(*) lets remember, many new users may have never previously visited this forum, in fact, many possibly never will… so see none of the discussions, many of us take for granted, as ‘truth’ I was reminded the other day, generally, how low forum participation is on any product (hardware or software)
2 Likes
I am always warry when someone says “should”. Is there a way to express that you are thinking more tangibly?
VST plugins are accessible through many different Hosts/DAWs. Rack plugins are only accessible through Rack. The relationship therefore appears much closer.
Also you don’t see really Ableton primarily marketing their platform on the fact you can access thousands of VST plugins.
1 Like
Yes - but I think it’s become clear that is not enough to prevent issues now. There are just so many different permutations of Platforms, DAWs, OSs etc.
Of course ultimately devs “vote with their feet”. But that doesn’t mean the present business model is perfect. Maybe it could be made better? I think that is the “meta topic” of this thread.
Are you saying that the present business model is perfect? Or are you saying that it is bad for people to speculate about improving it?
Ableton, not particularly… but thats kind of my point.
if you create a free/open source VST, you then don’t turn around and say “I don’t want it to run in any commercial daw” … the VST standard is (now ;)) an open standard!
the vst api has benefited the industry as a whole, not just Steinberg (who created it) , opened up more choice for musicians… we can chose our host… not just use Cubase 
this is kind of where I see the vcv module api ideally being situated , virtual/digital modular is becoming an important new ‘tool’, and we need an api that enables that openness / interoperability.
so I think, the more choices we have in hosts, commercial or free, the better. not only for users, but also for module developers.
edit: I recognise the above is a bit ‘idealistic’ (or wishful thinking) since at present we only have one host (or two if you consider the vst as a second ‘commercial host’), but its theoretically possible to create alternative hosts… could someone create an open source vst host, I think so ? no?
1 Like
This is a test comment to see if the one I have sitting on “Awaiting Approval” is because of some word list
edit: oh my god it is. I’m beyond annoyed now.