something which i think would be useful… anyone else?:
situation: one pedalboard with a bunch of presets. i get to a show, and want to tweak my input and/or output EQ for the room characteristics. it’d be nice to be able to say: “keep the settings of these two plugins unchanged when selecting various presets”. that way, i can adjust those for the room, and have them “pinned” as global settings for all the presets, rather than having to go in and re-save all the presets with the adjusted EQs.
so, basically: could we designate some plugins on a board as “global”, to remain unchanged through presets?
I don’t know if this will help you…
but I have created same pedalboards with different outputs. Usually stereo vs mono. It means I have to save two of each but it’s an option.
I like the idea of being able to disassociate a parameter from presets though.
Perhaps the way to do it would be a constant “off board” set of plugins for post processing. This would be independent of the pedalboard and presets so they don’t change when loading presets, pedalboards, or anything. There may be an argument for having a pre-processing set too.
instead of pedalboards being monolithic canvases, how about allowing us to build pedalboard modules, which can be saved/reused independantly and can be interconnected arbitrarily? then allow us to designate which modules are included in any given preset.
I’ve had a similar idea, and this is what I hope the architecture evolves toward over time. Instead of plugins, everything becomes a ‘component’ or ‘module’. Components would consist of one or more plugins, presets, and mappings. The simplest component would contain just a single plugin. The Pedalboard concept would still be the same in terms of persisting the state of a collection of components. To address some user’s needs you could also have the idea of a few “global” components. For example you could have three slots: Global override, First component, Last component. Examples:
Global - I add an EQ plugin to this slot. When I get to a gig I adjust levels on the global EQ. Whenever I load a Pedalboard containing the same EQ plugin, the Global settings override the Pedalboard state for that plugin
First - insert this component at the Input(s) and connect to the first component on the active Pedalboard
Last - insert this component before the Output(s) and connect to the last component on the Pedalboard. I think @solobasssteve mentioned he is including a multi-band limiter at the end of all his boards now - probably a great idea.
that would be ok for someone who always uses the same plugin, but download somebody else’s pedalboard who used that eq for another task, and your global messes it up. Do you keep that EQ that you use all the time in the middle of your signal chain? Or is that just hypothetical? I’d expect most of these use cases to be fine at the very end of the chain.
The other two make more sense to me.
However, I think this subgraph stuff is really outside of the scope of realism for now (though interestingly the program ingen does this and there was a period that mod was working on ingen for their backend). I hope a simple solution allowing consistent post processing can be added much sooner.
Or is that just hypothetical? …
I think this subgraph stuff is really outside of the scope of realism for now
This is all hypothetical Just rapping on possibilities. Given the team’s outstanding commitments and roadmap, I know nothing like this would see the light of day for years. But the software is all open source and motivated and enterprising developers can fork it and bend it to their will.
that would be ok for someone who always uses the same plugin, but download somebody else’s pedalboard who used that eq for another task, and your global messes it up
Right. But I assume most users who would be using a feature like this would understand the basic mechanics. A UI warning would go a long way Global component "My Looper" will override SooperLooper plugins on the current pedalboard, would you like to disable "My Looper" for this board?
Love the idea though! Perhaps it would be a little less abstract, if we considered pedalboards to be the modules you speak of: They contain fixed settings and require one or more plugins to modify the incoming signal. So actually the only thing missing is the ability to run them one after another. Or am missing something?
See, what we need here is a standard. And then when that standard is established we’ll create another standard and that one will be all that everyone will ever need…
So … standards = standards +1? I see you’re a man of culture as well.
But seriously: what would it take to enable module/pedalboard stacking? Each module needs two audio inputs/outputs and all the magic contained inside it is already defined, implemented and works well on the Duo. Plumbing together the respective inputs and outputs is also not entirely new: except for the connections to the hardware, it would be like running two LV2-plugins in series… right?
a “meta-board”, which can contain and interconnect arbitrary arrangements of multiple instances of the already-existing pedalboard construct, sounds like a great and relatively simple idea!
then, to address my original question, we’d just need to be able to say things like: “exclude THIS particular pedalboard from the presets saved by THIS meta-board”.
cool, @eggsperde … thanks for the idea, and totally count me in as a tester if it goes anywhere!
mod-host is the part that is responsible for the running audio system. It loads, connects, and runs the plugins via the JACK audio interface. mod-ui is what presents the web interface and is what organizes pedalboards and settings together. mod-host itself has no concept of a pedalboard as you can see in the mod-host API. Pedalboards are an abstraction made available by mod-ui and they are basically files on disk that contain the state of the pedalboard graph. mod-ui reads that in and then makes the correct series of connection, param setting, and midi mapping calls. This is great, because it means we can bring our own abstractions.
Conceptually, we just need to start writing bits of code that will build and manage the running state of the system for whatever we define those states to be. As a first step, prototypes could be made with Python/shell scripts that power users could use to build, manage, and run this component / module / nested pedalboard / pedalboards-within-pedalboards / pedalboards-all-the-way-down concept. Of course, most users would require or benefit greatly from a UI, which would be a great deal more work, but getting to a proof-of-concept point for this meta concept seems like it would be attainable in a hack day or two.
Thanks for the link, @unbracketed! I looked through the protocol/commands mod-host exposes and it seems to cover all the relevant parameters… except that it only addresses individual LV2~plugins over which a script would have to iterate, save and restore their states. That means, if somebody wanted to implement the discussed features, she/he would have to re-implement most of the functionality that makes up a pedalboard.
Just rapping on possibilities. Given the team’s outstanding commitments and roadmap, I know nothing like this would see the light of day for years. But the software is all open source and motivated and enterprising developers can fork it and bend it to their will.
