Great! I think option 2 is the least error prone.
3 Likes
Agreed, but I just realised it would get a bit complicated when there are more than one cable plugged into a single jack
5 Likes
@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…
2 Likes
…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
1 Like
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)
2 Likes
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.
2 Likes
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?
5 Likes
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
6 Likes
@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.
1 Like
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 !! 
3 Likes
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.
2 Likes
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?
2 Likes
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.
6 Likes
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.
3 Likes
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…
4 Likes
give us a link
3 Likes
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 !!
4 Likes
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.
3 Likes