@caowasteland People may stay on v1 for many reasons, but modules not making the jump seems to me not a great reason. I have as a merely intellectual exercise tried to get every open source module running on v2 and I’ve only been doing small edits and I have most of the available open source modules running Rack v2. The only real limit is the closed source modules, and I can’t see too many developers not making the jump or being willing for their code to be ported by one of the community. Even if it is, I’m guessing it will be a tiny proportion of the available modules. It might be that your one favourite module in v1 from one developer might not be available, but even if that is the case many of the developers of modules are happy to hear suggestions for modules and might be willing to cover the gaps.
Not as a first port of call. I was porting very naively - basically only making things not crash. I may well have introduced bugs. I may have had little clue what I was doing. Andrew has said that if modules aren’t updated by their developer then they will undergo to change the version number and see if that fixes most of them. And in my experience that gets many modules ported. Many more would be fixed by my kind of small updates. There are a few though that I’d much prefer someone who fully knows what they are doing have a look at. There were also a select few where if I really wanted a certain module from a certain collection and I couldn’t get their modules to not crash on building, I removed a module or two that were the cause of the crash and built an incomplete plugin.
Is that yes, or no? I only ask to point out that the ethical issues around submitting them can be tricky.
As I said, my default position is no. If there is something I’ve built that someone really wants, I’ll see what I can do. As to legality, that’s even a longer way off and I will cross that bridge when I come to it.
Ok, cool. But if you ever do want to do that, just remember that the vcv plugin ethics rules are pretty strict. And that’s not a legal issue around licensing as much as it is a term of service around the VCV library.
Yep, I know.
Thank you Xenakios for still trying to get to the bottom of the NaNs. Is this easy to resolve or are we waiting for the eventual ‘cure all’ V2 imposition?
Much appreciated.
but modules not making the jump seems to me not a great reason.
I strongly disagree. My work with VCV Rack lies in making playable keyboard instruments. Preserving the instruments I have created is essential. While I am an old school hacker, hacking and maintaining VCV is a distraction from actually making music. What’s the old Eno pun? “Familiarity breeds content.”
Addendum: I run Linux (Slackware), but I have no interest in distro hopping for exactly the same reason. It’s good to know where the bones are buried, and unless the payoff is significant, why put in the effort?
Oh I agree entirely about familiarity breeding content. However I doubt very many modules will not make the leap. Give me a list of the modules you rely on, I’d suspect most are coming across if they haven’t already.
I suspect it’s not NaNs that are taking stuff out. It’s a misuse of Talea. You have it configured to expect a clock on ext (see the menu), but you’re putting in an analog signal. I suspect it’s more likely to be something like an array overrun.
Addendum: if you set ext to be CV rather than 24 PPQN, the patch does not crash.
Some like the Southpole stuff (has anyone heard from the creator) seem abandoned. There are others, but that came first to mind. Some I’d like to fix for bugginess reasons (Autinn’s DC pass), but there is no source.
Edit to add: Linux may make it slightly trickier for you, but I’d be surprised if someone on the community couldn’t build you a plug-in you are particularly reliant on, and I’d imagine most developers of purchased modules will update their modules eventually.
Southpole should come across, Autinn I asked myself about on Github and the dev sounded happy to update if people were wanting it to.
TLDR:
I’m sympathetic to wanting familiarity to the instrument as a whole that we have come to rely on, my original statement was more a suspicion that most modules will make the transition one way or another, I really do hope it works out that way for you personally.
The Palette 1.0.5 update is now in the library. That only fixes the issue with nans/infinities coming into the CV inputs. Probably won’t fix your patch you posted here, as I suspect the bug is actually in some other module in that.
I do my own builds when source is available; in fact I prefer it that way. Sometimes, the build requires a bit more digging in the source than I’m happy with. I’m OK with minor hacks; major stuff, not so much.