Agreed, but I just realised it would get a bit complicated when there are more than one cable plugged into a single jack
@James I agree, this will be complicated. As well: If pluging cables like that is possible it should also be possible to release the cables in a comparable manner because this feature is not really worth the prize if I have to unplug the effect from another location. Letās say I want to shift the Reverb from before the delay to after the delay. Then I have to unplug it manually on the one side and can implement it automatically on the other sideā¦ hmmā¦
ā¦or imagineā¦ if I just want to park an effect somewhere and accidentially it plugs in the pedalboardā¦ Then I have to unplug it. This can be a mess
Thatās a good idea, perhaps there could be 2 options for unplugging on the bar next to the settings button above the plugin
- Unplug Empty (removes all cables connected to the plugin)
- Unplug Through (input 1 goes to the destination of output 1, input 2 goes to destination of output 2)
this is a good idea. For me the question is if this plug- and unplug feature is worth the prize. It is a good idea but how often is it really easing the userās live? For me personally it is fine if I plug and unplug manually.
I agree completely with @Kimā¦ good idea but could be a mess. Perhaps would be better after an Undo/Redo function.
In my opinion it takes longer to map again the controls than plug-unplugā¦ So +1 vote for @redcloud proposal swap/morph plugin by drag and drop, keeping the mapped buttons as @spunktsch says.
On the other hand, I think in the Mod-UI the game changing will be the blocks of plugins: For me, most of the plug-unplug and mapping is to reuse some plugins and connections in another pedalboard. Once it just means to copy a block, it will be much fasterā¦@James this is in the roadmap, right? could you explain a little how it will workā¦
- Will it be a black box with some inputs and outputs and a button to edit, but easy to delete, move the complete block.?
- or when you place it in the pedalboard is not a block anymore?
- Will it keep the mapped controls?
I donāt think it needs to be a mess. For the plunging part, the invisible area can be quite specific so that itās not so easy to do it accidentally. This is quite common for node-based editors. The unplugging part shouldnāt be messy at all. I agree that undo/redo function is a higher priority, as well as scroll zoom and transport buttons not being hidden in a menu
I think this will be very complicated unless you are dropping the exact same plugin which would be pointless. Not sure how this could be done
Unfortunately, this had to be pushed back on the roadmap. Itās actually a fairly huge undertaking that we canāt fit in at the moment. But it is definitely on the backlog
Itās not fully specified yet but basically yes it will be a box that stays as a box on the pedalboard that has inputs and outputs like a plugin.
It will be able to store mapped controls. I hope that one block will be device agnostic with the plugins and routings but that it will have device-specific control mappings. Or it will have control mappings with priority so depending on which device it is used on, it will have the appropriate number of control mappings exposed for that device. A device with less controls will still have the highest priority controls available and the lower priority ones will not be visible (chopped off)
This way, any block you make can be used on any device. Probably there would be some automated test to check the blockās CPU load so that a block that maxes out a Duo X could not be accidentally loaded onto a Duo
As I said though, this is not currently being worked on even though we would really like to, there are a bunch of other quality of life improvements and bug fixes that need to be made before we can start on this mammoth feature which we do think will be a game changer
@James This is exactly what I wanted to say. It would be a cool feature and it would be nice to have it. But in my eyes it has not the highest priority.
Of course you know betterā¦ then very good!
Perfect!
In my opinion most of the times if you replace a plugin, the new should be similarā¦ you could do a simple guess:
- knob 1 ā knob 1ā¦
- switch 1 ā switch 1 ā¦
and if itās wrong nothing happens, anyway the actual mapping is lost. Even if itās only the On/Off is very good! I think you save a lot of clicksā¦ In comparison a plugin in the middle of a cable is 2 clicks saved.
Oooh pity! but I understand is quite big. Hope you find a way to simplify it, so it can be done soonerā¦ perhaps without mapping and device agnostic, or limited only to PreProcess and Postprocess (at least like a first step and proof of concept), Otherwise I see pedalboard building in the device quite difficultā¦
What about some kind of copy/paste in a clipboard??
In any case, if this is pushed back Iām sure you will show us some amazing features sooner !!
Long names on list should scroll in ping pong style
The string should automatically scroll from right to left, 1 character at time, until the end of the string is reached then scroll to the opposite direction in a loop. Ideally this behaviour should be adopted for all elements that display a string but, to me, would be enough to use it in list items and titles since the top bar can display snapshot title too.
In general, plugins that generate file names automatically (without user input, like recorder) could contain a timestamp YYYYMMDDHHMMSS with the time obtained via javascript from the browser?
what if the browser is not connected?
perhaps you should seek out the most common use case and consider is a mvp?
perhaps it is putting a mono pedal between a mono output and input?
drag the pedal on top op the connection and the pedal lands in between them.
Even though this doesnāt solve the stereo or complex issues, it solves 100% of the requirement for simple mono use AND it already does half the work for stereo or more complex use cases.
just some ideas to keep it simple but with the main functions and reuse as much code-graphics as possible (so easier for users, less bugsā¦ and faster ) I hope they are helpfulā¦but I could be wrong (Iām just a user with some software knowledge)
-
Device controls not accessible on the pluging block editor, but only some limited number of internal controls (for example 4 switches and 18 knobs per block). No need for logic depending on device, cpu,ā¦ No need for big blocks, otherwise add another block or directly in the pedalboard. For example you add a compressor and map On/Off to internal switch 1, a wah On/Off to internal switch 2.
-
On the pedalboard building you just add a block similiar to a normal plugin, with the same icons on top, where only the internal controls are exposed. There you can map internal switch 1 to a device control.
Of course this has a clear drawback, you have to map the controls every time you add a blockā¦ but wait there is a function proposed by @redcloud to replace plugins and keep mapped controls and voilĆ ā¦ you replace a block and you still have the mapping (same number of controls safe guess ). Only the first time, you should assign themā¦ but for me is not a problem.
By the way another problem solved would be some controls not modified with snapshotsā¦ You just add a block with some controls not exposed.
I suppose this is just a layer on top, internally (mod-host) it will work just the same. And probably on the Mod-ui you donĀ“t need a new tab. Just on the PB building, the plugin block has 2 sizes:
- plugin size, same function like a plugin but only the exposed controls
- block editor size: where you add plugins, connect cables, and inputs and outputs (audio, midi, cv)
And on the plugin selection horitzontal roll, just a new category: Blocks, with a + to build a new oneā¦
ā¦ sorry for the long post, I thought I write it before I forget it.
No worries. Thanks for sharing your inputs on this. Itās quite a big feature so inputs are really welcome!
I mapped them
I think It will be very useful to have an option in the PB to enable auto-mapping controls to Device. Not only in Mod-ui, but in the future PB building in the device itself.
For example, when you add a Plugin automatically maps the On/Off switch and the first 3xknobs on the first empty page.
Of course this is not for your main PB for gigs, but just for testing some Plugins it will be faster and easyā¦ Or as a starting point.
I think some guys with a raspberry did something similarā¦
give us a link
je je donāt get me wrong, Iām really happy with my MOD, but before getting my Dwarf I played with a Raspberry and Mod-Uiā¦ for a time I used a zynthian image which has an automapping function for modui, although not optimal because it maps everything, it also has a way to build effects in the device, Later I manage to build myself an updated mod-ui.
ā¦ but now a Real MOD is just another beast !!
Hi, on the Dwarf I would like to switch directly to a specific Page. Maybe with the help of some shift function and the three buttons or so. The scrolling through the pages via the A button toooo slow. And while Iām at it I wish for a custom page name and subpage name.
Itās funny that I started a new thread about this and @plutek put in the link to hereā¦
I called it a cluster and couldnāt figure out what key words to use to find other discussions about this idea.
Iām glad itās on the list of items but understand it may not be towards the top.
It would be great to even have some kind of way to select a string of connected plugins and make them into the size of just one small plugin to save space. From there, it would be great to save that cluster/block as itās own thing like another plugin. It could be a black box but I know the mod guys have a style and will let us choose, or even create our own, graphic.
To take it a little furtherā¦
It would be great to be able to customize the settings we want to edit or hide settings we donāt use.
I can imagine the settings screen of these blocks could be really big and having difficulty finding the settings you change on the regular.
Anywayā¦ just some of my thoughtsā¦