If there is a way to group a set of plugins in the GUI, maybe to be like a folder, and only show the plugins in the group when clicked on them, I feel can help to create a cleaner look on the GUI, especially when using a big number of plugins.
Will be great if the group or folder can be save as a preset of some sort, and is import into any of the other pedalboard with a simply drag and drop. Many time I will have to recreate a group of plugins exactly the same way in multiple pedalboards. This idea could save a lot of time I believe.
Like using abstractions or subpatches in Pure Data, you could add âinletsâ and âoutletsâ to your group, or use it in different pedalboards, as if it were a pedalboard within a pedalboard.
I love the Idea.
(*1) Effect blocks:
You can select a range within a preset and move/delete/⌠in the GUI and/or save it separately as a new effect block. Within a preset you can then load individual effect blocks into the existing preset.
I think there is something in the works that may accomplish this. It was mentioned in a previous thread by @James (quote below)
Maybe someone on the MOD team can give some more detail as to what these âblocksâ are and whether they will satisfy this âplugin groupingâ idea?
Thatâs right, we have been discussing a feature like this for a while that we refer to as âblocksâ but it is essentially a group. It will look and behave almost exactly as it has been suggested here only with some added bonuses like being able to have saved control assignments so that when you drag a block onto a board it will automatically assign to controls.
One reason to do it is to avoid having to recreate the same sections on every board as you have suggested. The user would be able to create their own blocks and share them so that people can assemble boards with these premade building blocks
The other reason is that we see this as being a necessary element for an on the fly pedalboard builder. Since there is a lot of variation in plugins, we need to containerised them so they have consistency and can be easily assembled on a board on the device and since the control mappings are saved to the blocks, you donât need to do control mapping when assembling a board on the device
I mentioned in another thread recently, itâs currently not in the roadmap because itâs a big project and we already have a lot of things to finish. It is in the backlog and we see it as being something that will make a huge improvement to the workflow
Itâs really great to see this thread to be honest because itâs almost identical to what we have been discussing and itâs really great to have the need for this confirmed by you guys as users!
Oooooooooooooooohhhhhhhhhhhhhhh <3
New to the Dwarf scene and I quickly thought something like this would be a great addition and time saver, glad to see itâs (somewhere) in the backlog
I would just like to say that as a new Dwarf user I have also thought that a âComposite pluginâ (applying the Composition software design pattern to plugins) would be very useful.
I would really like to see this happening in the webUI ! I see these point to be talked though :
what if the block added in the pedal board uses the 7 pages, should those pages added after th ones configured in the main pedalboard ? In this case it would be really appreciate to have the ability to change the order of the pages
what if the main pedalboard and the block added contains the same midi message mapped to a control ? Should they stay the same for both controls so a midi message can be mapped for more than 1 control ?
what if the main pedalboard uses 75% of the CPU, and the bock added uses 75% too⌠Should block addition be prevented ? (so that means the CPU consumption is evaluated (with the buffer used) and saved with each pedalboard)
This shows a small part of the work to be done I suppose ?
