Well, I am not going to die on that hill or whatever, I just think it’s a bit sloppy with all these unused ports. If they would be usable in the future however… Like maybe routable to some other port… Idk. I guess I was traumatised for life by a fake mic input on one of my cassette recorders. Now I just can’t stand anything that suggests usage (usefulness? usageness? Whatever they call it) but doesn’t provide it
It’s possible my troubles with getting literally anything other than the base modules, this one, and Surge XT, is that nothing is compiled for M1 processors? The log says the downloads always fail, so for now I can’t use anything I can’t download a build of on github somewhere. Unfortunate, but tis what it tis?
It seems that in an ideal world of attenuverter heaven only the outputs maybe would need gain. As inputs can be fed from 'verted outputs and the splitting of “occasional” outputs with more 'verters for differing inputs would be free in an ideal world. Is it really just an LFO cost limit of physical hardware that leads to a need for large numbers of mults?
I’m going for say red for outs, and green for ins, given the green for go connect first hardware no shorts. Maybe there should be a virter extender standard? Place one and the names appear, by
attach(X_IN, "at in");//get attenuverter if available
and
params[X_IN].get...();//becomes a scaled automatic (set too)
Oh dear. Yeah, the all-in-one Airwindows library plugin might not be for you then there are a number of things like that which just have to be like that, full stop. Frequency controls aren’t standardized or 1v/oct either. Changing those would break… literally a world of plugins out there, some of which are in saved projects in all sorts of DAWs on music from underground to literal multiplatinum chart toppers (there’s a guy who needed me to update a secret weapon to M1, who’s never wanted his identity revealed but was very insistent about needing his plugin to work on his new machine which was M1…)
One thing about these is, there’s two ins and two outs at the bottom, and literally everything else is a VST parameter from 0 to 1. There’s absolutely no way to tell what will end up doing anything, so I like the simplicity of 'these are jacks, here’s a little attenuverter (I guess in case you’re getting negative voltages in, and need to make them function? Is that common?).
This is not the plugin for making everything WITHIN the plugin, make sense to people. There could be another plugin by someone (open source, woot!) that curates the collection and adapts everything to taste. This is the one I can direct people to, where everything new I add is pretty immediately available in Rack no matter what it is, without effort on Paul’s part (important!)
Anything that doesn’t serve that goal isn’t part of the vision for this plugin. This is the one that’s just a machine for taking my entire library in, and making it patchable-to, no matter what the plugin is or does. My stuff is all MIT and Paul’s is likewise open source so it’s very possible to build upon and I encourage it, I just need a version that meets my needs (among them, letting it be hands-off for Paul: we may well collaborate on other things if this works out well, but it’s real important for this to not become a time/energy sink. We are really, really close to done.
Well, it’s fine if it works in a weird manner. It’s fine if it’s not standardised. It works - everything’s fine. It doesn’t - why is it there then? Maybe there would be some kind of use later and if there is something planned, I totally understand why these ports are there. Like for later plans or something like that… And I also understand why people would like to have them too. Like maybe to randomize the presets\programs with already set cables… And that’s why I proposed an extension and not just deleting the unused ports or making them invisible
Be patient with me for not wanting an extension, or the modulation matrix me and Paul briefly talked about. Honestly, I have a fierce and true vision for all this, and one of the things about it is that it welcomes other people taking my things and making 'em THEIR things in their own ways.
I’m trying Paul’s script for adding the proper ARM builds, that should fix my problem
The slug in plugin.json or the AU four letter slugs? The repo has no capitalization as the .json slug does. Minor but given some python supply chain attacks based on close words or capitalization along with the concept of forking, … not likely related though as I didn’t get the slugs reference. Although git would complain about a clone to a non empty directory.
Pretty much I just grovelled through what I could identify and found things like ‘cfoulc cf’ and ‘kockie69 SquinkyVCV-Main’ as far as stuff I wanted to be able to include. I’ve already got SurgeXT, Fundamental and mine. Looks like the script is working, which is normal for baconpaul
Oh, no, wait, it’s absolutely not. It’s trying to do it as if it was on Paul’s computer. I may or may not be able to fix that yeah, it wants to be on Paul’s computer and it wants the SDK. False alarm, I got nothing
I exported the wrong dir, I just have to figure out whether it wants to point that at the program, or the SDK (which I do have)
Yeah, I’m nowhere, I get a lot of ‘already up to date’ and ‘make: jq: Command not found’. I found the slugs but can’t simply export RACK_DIR as the location of my Rack SDK, and I’m not competent to fix this. I will go without modules for those I can’t find in your google drive
chris: just install the x86 version and run under rosetta. ARM is still pretty dev-like and lots of the user gestures - like the library! - aren’t ready yet.
naw, I’m fine for now. I got Audible and Befaco and Surge XT and Airwindows and Fundamental, it should be fine for now
Correction, I got them and it turned the downloads into a folder, and updates grabs a new thing and re-does the folder, but it creates a plugin.so file and not a plugin.dylib, and nothing shows up. Can’t go no further right at the moment, see you folks later in the day. Paul, weren’t you off doing stuff today? Don’t worry yourself about this. It’s just Rackisms
yep I agree there is a DB with primary and unique keys somewhere, but it implies a date where someone else names a repo rack-modules again … easy enough to fix by a target git argument, if the git pull is not automated. https://library.vcvrack.com/KRTPlugina 404