Yup. The Surge folks love modulation matrices and Surge XT modules have that, but I strongly prefer just exposing the 10 jacks for all possible plugins. (will be working on CStrip and Pafnuty so there are versions you can have, but it’ll involve releasing new full-on plugins on all platforms, not just this)
Like I said, given the option to have just four jacks assignable to everything for a prettier look, how can you not have all the potential inputs independently modulated
I really gotta get moving on a Pafnuty that’ll fit (there’s only two plugins that had 12 inputs and none with 11), it is already DC-friendly so imagine the possibilities of putting Pafnuty onto a simple LFO. And then modulating all the inputs simultaneously while you’re at it. Magic
I was thinking how to make the module look maybe a bit cleaner. And I guess all the CV inputs could be separated. I actually proposed something similar to Firo few days ago. It’s maybe my idea fix to make modules even more modular, haha.
I know it’s not a voting contest but I’m pretty happy with the current look of the Airwindows module. It’s clean and simple. I also like having all the 10 jacks visible all the time. And the color. And the dog.
I don’t think this would require expansions to be implemented, since SvgPort implementes Widget and Widget has a visible member and a setVisible() method
I did that oringally. if you have it cabled you get a dangler to nowhere.
current thinking is to change it to a different graphic if not used and not cabled.
Ah yes, makes sense, if you have something all cabled up and then change the algo… bad usability.
Although, there is ShowEvent & HideEvent, it might be possible to remove cables rather than leave them hanging, and potentially also save a cache of which cables were connected before the algo change
That might be overkill though, probably best just to have some indicator for unused ports
No doubt, but I really like having all the unused ports visible, because at any moment you could change to a different algo and use them and me and Paul talked about making the ports more complicated and configurable, and I expressed that I really, really liked the rawness of having direct access to all of them I think we’re good for the time being, and eagerly look forward to getting it to a state where Paul’s done with the plugin and can just let it expand with each new Airwindows release (such as a Pafnuty that’ll fit so we can do cooler LFOs).
Then people can ask me for stuff that could easily be in another module, or in a more curated and sophisticated module, and I can say ‘but this one’s done and I use it just the way it is’
Besides, any of the ports COULD be connected and made operational with a single algo switch. I think it should look like you can connect to stuff that doesn’t correspond to anything. You can, it just doesn’t do anything right then.
Imagine, patch challenges where you patch a bunch of stuff and then have to find an algo that makes sense
On other notes, I’m unable to work out how to install modules, having tried to get an SFZ player. Everything has the red dot, claims to download updates, and then nothing happens. Back to trying to solve that one.
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.
