You could easily make that more obvious with a different library design. At the moment everything is looking similar. Just change the design to a more dev-oriented design, where each “Brand” has it’s own CI and a short introduction to the story behind the dev. You could still do a search for keywords and Types or Plug-Ins, but to subscribe, the user has to go to the dedicated library page for the dev with additional information.
1 Like
for 3 years ive dealt with being a beta tester. there have been several instances where i lost time and projects due to plugin updates. it was very frustrating as this is what i do professionally but i could never truly complain because this was at the time a non commercial product, with an attitude that the developers were doing all this out of good will and community spirit.
now im a paying customer of a commercial product and my expectations as the end user are different and justifiably so. this week i already lost a day of production to a bug that made a saved project crash upon launch and impossible to open. given this is week one im willing to let it slide but this will not be the case for long. i guarantee you i am in the minority as most users wont have 3 years of tempered expectations; they paid for a product that is costing them time and money and frankly thats not gonna fly.
vcv is very much at risk at becoming the no mans sky of vsts.
2 Likes
No but at package level, rather than library, it’s often possible to downgrade. How easy this is is another story but if the package manager allows it then usually it is ok. The subject gets murkier when you have people providing packages (I’m thinking mainly PPAs or .deb) because there’s no knowing what the systems libs are. I’m not here to promote Arch and I’ve actually always been against it until I installed it recently, linux audio is in a weird place where if you want updates on audio packages the options are limited with kxstudio not really providing updates any more.
1 Like
It seems like a win win situation/proposal to me, willing testers can do their thing, it costs VCV nothing and the users get a more stable experience.
1 Like
I know this is not possible in VCV because of the spirit of VCV and the work all the devs are putting into this. But: From a “new user perspective” (please don’t call them noobs, that is so disrespectful) I would like to see a rating. Yes, I said it, a rating… sorry… but please, just for a moment, take a look through a new users eyes:
Stability: 4/5
Performance: 3/5
Usability: 5/5
Sound / Functionality: 4/5
Support (for paid modules): 5/5
Manual: 4/5
After using the stable version of a module for - let’s just say 10 hours - you get a prompt in VCV to give a review. Why not give the Dev’s a Feedback for their work? At the moment you need to work with a module library for a loooong time to decide if it goes into your favorite selection. Every buggy library you have to find out for yourself. If you want performace-optimized modules you have to test each for yourself. That is very time consuming…
As an addition: Let users select the favorites of another user. Or a curated selection of another user. “Hey, I subscribed to Omri’s new ‘Production in Ableton’-selection of modules last week, and never had a crash since then”
I think there is a lot to do outside VCV in addition to just introduce a stable/beta feature.
1 Like
At least a ‘users who downloaded this module also downloaded this’ would be quite cool but I suspect most of us are still ingrained in the ‘subscribe to plugin rather than module’ mentality.
I probably was not clear, but the people i was calling “noob” are developers who have never programmed before. Noob might be disrespectful in this case, but it’s at least fairly accurate.
I would never intentionally mock a user because they didn’t know something about programming, after all, they never claimed they do, and they shouldn’t have to.
1 Like
Might add that even developers who are new should be encouraged, everyone has to start somewhere. Having said that @Squinky does have a track record of helping other devs (when he’s not comparing aliasing at least - jokes) and writing a demo plugin to help new people explore the world of VCV plugin development.
1 Like
Oh, for sure. and usually questions here are answered cheerfully. As the forum “rules” indicate, sometimes it can be tricky to ask “the right question” (see forum info for more on that).
Yes, I think my n00b repo can be useful, although the code is mostly about oscillators it’s still a decent example of a tinny module that works. There are also a lot of EXCELLENT (joke, but people do like some of them) papers there: GitHub - squinkylabs/Demo: A collection of code and articles of interest to VCV users and developers.
The VCV manual also has a lot of good stuff about programming and DSP. And never forget that the SDK itself had an ever-widening library of good code in it.
and I appreciate the joke, too, @pgatt .
1 Like
My initial thoughts:
It strikes me that there are a couple of prioritized objectives:
- It would be nice if updated 3rd party modules would not introduce crashes in Rack.
- It would also be nice if updated 3rd party modules would not introduce new (non-crashing) bugs.
I think #1 is the overwhelming priority. I also think that, as long as the architecture of Rack permits a plugin to crash Rack, it can only really be mitigated by automatic testing of new releases. A test harness that runs at the library end, automatically testing whether the plugin crashes the browser, and whether inserting and deleting each module in a test patch crashes Rack. This would eliminate most of the bad headaches reaching users. It would be a big bonus if this testing harness would be available to developers to run on their own machines before even submitting the update.
I think #2 is a nice thought but all software has bugs. People like Squinky Labs have done some very nice work towards developers on the educational side, but it would be really nice to supplement this with automated tools. Think “a Rack plugin linter” for example, I think this is much needed and would be a nice project for an enterprising developer to sink their teeth into.
To supplement that I think the idea of a “testing ring/channel” is a nice idea, as long as a person can switch between the two. There’s plenty of good community members that wouldn’t mind doing some plugin update testing on a regular basis. The big question will be whether to delay all updates to plugins because of a testing quarantine, or whether to make it an opt-in for developers for their particular plugin.
I think something like a mandatory 2-day delay in a testing ring might not be so bad and it’s plenty of time for experienced rackers to find the most obvious bugs, if you know what modules are updated. I do think however that it depends on objective #1 being solved first, because as long as you have crashing updates, fixes to that needs to be able to reach users very quickly.
3 Likes
Forgive me if I sound like I don’t know anything, because this is mostly true. From a user’s point of view, I don’t expect any module to crash Rack. I don’t blame any dev for this because this stuff is complicated, I get that.
There needs to be an intermediate step in the procedure before modules are released into the wild. How about devs submit new/updated modules to VCV for testing and only they can add it to the library for us to use? If it slows down a release that’s a small price to pay in my book.
We all have an interest in seeing VCV succeed, because we love it so much, but new users in the VST world may well be less forgiving.
Any number of ‘it’s more stable now’ announcements will not help a bad initial impression and may put off anyone thinking of trying VCV Rack for the first time.
5 Likes