Nysthi you can get from here:
1 Like
I guess it’s confusing to me. If some devs like surge / @baconpaul make plugins that are super high quality and update stuff almost daily, why would someone want to rely on a module from a dev that can’t or won’t do an easy update like this after months or more?
1 Like
Have there been sightings of Aria Salvatrice’s modules arm builds? That’s the collection I miss most (apart from Lindenberg, but those are visible on the horizon)
I’ll give you a pretty simple use case in your favorite style, passive agressive.
Art Installation. You can extrapolate the implications.
Man, you repeat this question every other week, have done so for almost half a decade now.
just say yes to aliasing 
Sounds beautiful, rich and umpredictable!
1 Like
That is more of a Rack v2 issue rather than an ARM issue.
I don’t know whether Aria would consent to someone taking over maintenance of the plugin and upgrading to Rack v2. I don’t know if anyone has asked. If she has been asked and she declined, then there ought to be some database / list where inactive developer wishes can be stored, so as to minimize repeated inquiries.
It is off topic, but I have been thinking there ought to be a way for a developer to plan ahead and consent to someone taking over their plugin if they become inactive in the future. I suppose the trick would be defining what inactive means. But I am sure something reasonable could be defined. I think that is something I would like for my own plugin.
2 Likes
VCV is pretty reasonable about that. I’m sure if you gave consent in advance in email or better yet in the github readme they would do it. I passed on my Squinky Lab modules to @robert.kock, who has been graciously looking after them. I’m pretty sure they were available quite promptly when 2.0 was released. In that case I sent an email at the time saying “I’m giving my permission to this guy to take over “my” plugins, Squiky Labs branding, etc.”
2 Likes
Pgatt and I did the same with mschack yeah
The issue here is of the five open source modules not on arm four are trivial fixes and two of them actually have open prs with the fixes. At some point you just sort of realize a module is a bit abandoned and move on I guess. But I’ll push up the other two prs tomorrow morning anyway and see if the authors click merge and submit!
(Edit: Each of the four open source plugins which don’t build on ARM where the source is still present now has a PR in which makes them build on ARM. So lets see!)
2 Likes
I may be wrong about this but i thought i read that aria was okay with someone updating the modules if the quality/care of work was as high as aria. Aria dodnt want to push bad versions (buggy, etc) and is done with vcv dev due to whatever personal reasons.
I dont remember getting the vibe that aria dodnt want them pushed forward. In fact i think aria is fine with/ wants someone to come forward.
Here is the last post I know of where Aria expressed their preferences.
Okay thats the post i was thinking of, but i had misinterpreted. Nvm.
And now from the library!
1 Like
do we know when perhaps a stoermelder arm update will happen? i’m using one from github, would love to see in library
About time to cop a mac m3 i see.
I’m still pretty happy with my M1.
1 Like
I got a 22” pro shortly before the m chips and it was somewhat of an investment. Wasnt even interested in m chip mac until vcv was sorted.dodnt think it would happen so soon. (Not that im even in the market yet)
I only use my M1 for work, do VCV on my own windows machine. Everyone at work hated those Intel Macs that always sound like a jet plane, so we got new machines when we could.