Separate the libraries maybe?

Hey, let’s all try to be calm and respectful here, ok? I think most everyone here are doing that, yes?

1 Like

I bought Rack2 paid as much to support ongoing platform development; I will use it in Live, but not the way I use it standalone.

The 2 years it took for Rack as VST to be finished were good for me creatively, because I found a workflow in Rack Standalone whereby I could make complete tracks in Rack. Some of my released music is completely unedited first take recordings.

Going back to Live to construct a piece can feel less inspiring somehow. I don’t hate it in the DAW but it isn’t where I use it mostly.

4 Likes

It appears to me that this thread seems to be designed to stir up some controversy. The OP has posted it both on FB and now here whilst not being a developer themselves. I would be more comfortable if such a thread had actually been started by a developer.

Having said that, some interesting issues have been raised. Splitting the library is a terrible idea from a user standpoint. I think @vega made some good points though. if Rack Pro is advertising the size of the free library as a selling point, then I hadn’t really considered that before. If we only developed free modules then that might bother me more than it does. But as we also develop a commercial module, then the more users Rack can get, the more we will be likely to sell. In general I can see Rack development becoming more commercial over time I think, as it becomes potentially more viable due to the larger audience.

I have to say I LOVE using the VST, it’s an absolute game changer. I think Andrew was very wise to give every developer a free copy - there would have probably been a shit-storm of biblical proportions if devs had been expected to pay for the privilege of using their own free software in the VST!

I really felt for @synthi when he was getting moaned at by newbies “because they’d paid $99 for this!” - no they damn well hadn’t - and this is perhaps the thing I feel strongest about. I think VCV needs to make it as clear as they possibly can about what people are paying for, and what they are not. And this comes back to the advertising of ‘over 2000’ modules thing. If people think they are paying for a library of over 2000 modules, then if there’s a problem with one of those plugins, they feel they have a right to complain about it. So the developer gets these entitled complaints from people because there are some issues on day 1 with the 150 modules they code, maintain and offer up for FREE. And which they had to spend days working on solely to support the VST, from which they receive no benefit at all. There definitely IS something wrong with that.

Over the last few years there has been a great culture of respect, patience and gratitude between the users of VCV and the developers of FOSS plugins. That needs to be carefully nurtured and protected and VCV should consider how best to inform and educate these new VST users about the way things work round here. Otherwise I think there is a very good chance some developers will just throw in the towel because they simply don’t need this kind of grief from entitled people, who feel they have paid for the right to complain, when there is no benefit in it at all for them.

14 Likes

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, :slight_smile:

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 :grin:

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?