The most basic UI could be a way to list all the plugins on the pedal board, show an list of the inputs/outputs, and add a “connect to” which shows a list of the potential ports to connect to. But the user experience would not be super great. It could be improved by being clever with the ordering of the lists though. Also one would need to be able to discriminate between two identical plugins if more that one of a given type is used…
Another approach could be to show an ascii art matrix of tiles and to be able to add plugins onto it, and then to select a pair of ports by navigating the tiles with two buttons to create connections. That would be visually a bit better and easier to select the right plugins, but there would then be a difficulty that the positions on the matrix would have to kind of reflect what we see in the Web UI.
As I see it, there are a lot of potential approaches, but they all have the problem of a quite cumbersome UX and the added complication that they would have somehow to reflect what is happeneing in the Web UI for consistency. We don’t want to confuse the user with a totally alien representation of a pedalboard compared to what they can see on the Web UI.
Of course, if we consider them as just “emergency” editing tool when no computer/phone is available, any UI design would be good enough. But the problem is that MOD would then be trapped into maintaining it without the ability to refurb it too much after that. Unless it’s considered a beta thing all along. UI should normally be thought well from the start otherwise you run into all sorts of issues.
I also thought of a quite orthogonal approach (and quite geeky), that actually encompasses a lot more than pedalboard editing, which is exposing a shell on the device itself.
Users could then do pretty much anything on the device without needing an external device. It would require a way to use the buttons to type in stuff, but maybe allowing using a small USB keyboard could also be a thing.
And it could then also be possible for the user to write scripts/python app taylored to their own needs (for instance an ASCII pedalboard editor), instead of relying on the MOD development team to do it.
Especially with a virtual keyboard where you use rotary buttons to select letters
However, I think the idea is more to allow running arbitrary commands, and more importantly, ascii-art apps. If the current UI had a beta option to allow to select a user written app from a list, we could start writing our own pedalboard editors and share them, and the one most prefered by the user would get a chance to become “official”.
And that would also allow a lot of other things to happen.
hm, i wonder if the dwarf could work with a mobile USB monitor (like an ASUS ZenScreen touch)? that would be cool: plug it in, configure with the flexibility of a desktop, unplug and go.
That would need additional drivers on the unit, which might be too much of a hassle I guess. Also, if we start needing too fancy extra hardware, why not use a phone or tablet?
I never said that the development of such a thing was easy. I was just sharing my personal user experience
There are a fuck ton of multi fx on the market, almost all of them allow editing on the hardware, some also work with editors. With all of these aida things and the dwarf, mod is clearly marketing this for guitarists. The thing is most guitarists (including me) just want is a series of 3-8 fx and being able to edit these fx also on the hardware, in terms of rearranging their order and swapping out individual fx.
The mod can’t do that, why at least for me I decided its unsuitable for this use case.
In the reboot thread, someone made a comment that was very much on point imho:
“Doing simple things on mod are incredibly complex, and complex things are incredibly simple”
This is were I pretty much ended: Doing a simple guitar pedalboard with 3-8 fx, is very cumbersome. The curation of plugins is all over the place, and I can’t do the things mentioned above. Even swapping an FX in the editor is very annoying.
Running a VCV rack/ Cardinal patch, a sophisticated processing chain for my synth that mimicks things I would be doing in Ableton Live with plugins, doing intricate usb midi routing and filtering is very easy, and there is almost no competition. So this is what my dwarf ended up doing.
So I really think User Base “Team Simple” has to be adressed here more (as this is also clearly the target group atm)
My proposal: Give us a pedalboard withing a pedalboard. A virtual container where we can put sth between 3-8 FX slots. All of these slots are swappable and interchangable in their order.
Only a list of curated plugins can be added to this container in order to maintain compability. We make sure all of the plugins can do mono to stereo, or stereo to stereo and the system will have a set of rules that chooses the right version of the plugin accordingly.
All plugins withing this container will be automatically mapped to the hardware UI.
I think the Zoom G1 Four is a very good example how you can design and edit sth like this with a bunch of buttons and encoders. As a matter of fact, this is the Multi FX that won against my dwarf in terms of Usabilty and effects curation: A 90€ multi fx
That being sad, I still believe in the potential of this project and I would love for it to grow in the direction we are discussing here
For many people going Dawless is a conscious decision of avoiding a computer or a tablet because of the potential distraction these devices bring. A tablet is something you use for browsing, checking your mail. For me personally that makes these devices bring me into a different headspace. The least thing i wanna do when in a jam is grab my phone, just because I want a chorus instead of a flanger
I’d say that you could have a chorus and a flanger on your pedalboard and decide to engage one or the other, exactly the same way you’d do with a physical one. Same if you want to swap the order. This could be available on your pedalboard from the start (especially because you can have as many instances of each effect on your board as you like).
So I think what we want to address here are more situations where something unexpected arise : I once had my bass player asking me “could you not add some tremolo on your gizmo”, which took me completely unprepared and for which I would have had to pull out my phone and faf around for a moment (which I did not want to). But I don’t think your container idea addresses that or I might have missed something.
I tend to agree with most of the stuff posted here.
It would massively help if you could assign a parameter of ANY pedal on the device.
Just from a list select footswitch/button/midipedal and assign alphabetical sorted list ->pedal → parameter.
This is a long ongoing debate (even before the crash) and has a lot of suggestions.
We have to be realistic here: there is only @falkTX atm for all code related stuff.
I bought an old iPad mini dedicated for this stuff. Printed a case that snaps onto the dwarf/pedalboard and keep it attached all times.
I also had the idea to have a separate app that would generated the file for a pedalboard ( (its all text based, so would only be a matter of coping it to the device). At least for basic plugins or in case of a fall back scenario.
The Chorus / Flanger thing was just an example. In practice I end up swappinng out / changing more than these two effects. I also really love to sit in the park with a small speaker and trying out different effects…on a hardware itself!!
That is exactly what I mean. You will always run into a situation where you have to tweak / change a relatively simple thing, that you didnt plan beforehand.
I was mentioning blank slots in the container, where you could load up extra fx for these spontaneous situation. So if the container has 8 slots, you don’t have to fill them all and leave some empty for these last minute changes.
It could also be that you can’t use the guitar you usally have and you need and extra EQ to make it work, there is always something in the end…
thats not such a bad idea after all.
True! But maybe in this case using the open sourceness and incorporating pi.stomps work somehow could be the low hanging fruit to make a first step with this?
I don’t remember exactly where, but I remember that the mod team wrote in somewhere that they going to (?thinking to?) to focus on this public. Maybe I misunderstood what the mod team wrote, but I agree with you.
That’s so true. And IMHO it’s a problem, because a lot of times what the guitarists need are a simple plugin chain.
Recently I was looking some other multieffects, specially new chinese fx, like Valeton, Ampero. What they generally have is a simple chain of effects, generally “a series chain”. Some enables to the user create a parallel chain, for example select one amp simulator on Left Channel and another on Right Channel. The most advanced equipment that I saw¹ enables to define two full independent parallel chains.
¹ not counting Mod equipment.
The flexibility what MOD UI offers doesn’t compare with them. But the physical editor of them works like a charm considering what they do.
So I think that maybe the mod devices could have a physical Light editor for simple chains. A simple mockup:
Maybe a charm solution for this is including custom lv2 ?attributes? into in and out ports:
if the input or output is designed to be mono, it must have mod:preferredMono;
if there is stereo input/output, the input/output ports must have mod:audioLeft / mod:audioRight;
ports without mod:preferredMono, mod:audioLeft or mod:audioRight will not be used by the editor;
you can combine mod:preferredMono with mod:audioLeft or mod:audioRight;
for the plugin be eligible to be shown on the Light editor, it must have an mod:preferredMono output and may have a mod:preferredMono input too;
the mod:preferredMono input isn’t required to be compatible with plugins like Click, Metronome, Audio file.
the mod:preferredMono output requirement could be relaxed in the future for support recording plugins.
With it, I suppose that we solve the curated plugins list and facilitate the implementation of some operations like plugin replacement, swap, inclusion, parallelization (splitting in and merge in).
For instance, this source of code defines the input and output audio port of the Collision Drive.
Yes, I agree that appears to not possible to this moment an effort on this way by the mod team.
IMHO, a live editor will works better than an full separate editor that requires that we manually include the created pedalboard. If we don’t use the web ui stuffs, probably a Bluetooth communication would be quickly enough.
We could talk with the PiStomp, MODEP and Zynthian guys to know how they communicate with the MOD Tornado API.
What I can imagine now: call the REST api for the necessary operations:
get plugins metadata;
add/remove plugin instance;
change parameter value of a plugin instance;
connect/disconnect plugins instances.
I remember that once I talked with @falkTX, and he alerts me that not all are exposed as REST (some things are WebSocket). But I think that the upper points are present on REST api.
The biggest problem is the inclusion of the input and output metadata. Without it we must to infer at some way witch inputs are supposed to be considered mono, left stereo and right.
Can I pay/donate my voucher if it helps you to make this? I don’t want a subscription or a paywall to access to updates but I understand you need “juice”/money to run and create new things
I made this post because I really want the platform to improve but at the end I felt frustrated because I can´t do much more… just post here and wait (maybe forever)
That´s why I suggested a survey to vote for community driven updates. Maybe having a roadmap with things to vote and unlock like in kickstarter/indiegogo? Making this will make you different from other companies because the users can make decisions and you can have money to pay for more developers
Obviously, the developer team of MOD Devices must be rather small,
so inventing the UI completely new from scratch won´t happen -
and I really don´t see a reason why anyway… The browser solution is quirky, hard to navigate but fairly okay.
Moreover, In general find MOD´s UI solution rather superior.
Still,
improvements have to be done for professional use, IMHO.
Though, @doremi, I absolutely agree -
without an (MOD´s) internal task force for debugging/improving
the UI people, including me, won´t be willingly stick to their product forever as I take my work as an Musician/Artist far to serious to deal with hacks all-day-long.
I am a Fractal Audio AxeFx 3 User - payed 2400 Euros for a unit,
which tightly gets debugging and improvements. But I hopped to MDW from one reason: I addressed one wish since 2 years Fractal Audio isn´t willing to listen to (JFYI, it´s gonna be a necessity for my setup)…
In short:
It´s just a matter of time some other company will try to fill up the MOD´s/Zoia/Poly-niche instead if there´s no existing customer wish-list for improvements upcoming,
and - which is to get done periodically
Hello. I am here again because I´m feeling like this needs a conclusion - clarification.
Please, I wanna ask the developer team of MOD @falkTX a brief opinion of this posts or what is reasonably doable or not
The browser solution is genius for creating things from zero but for quick changing parameters while using it as a pedal feels a bit lacking (you need to have all parameters pre-maped or a pc/tablet connected).
I think having a “quick edit mode” will fasten and improve the workflow. After looking at possible solutions I love the one proposed here Access every plugin parameter from the Dwarf screen which is having a nested menu with the 3 knobs of the Dwarf: 1 for changing plugins, 2 for parameters, 3 for values. Feels quick, easy and logical (you can even make a commercial trailer for the easiest to use multiFX).
Removing the friction of changing things while working with the pedal standalone will improve the user experience for sure but I don´t know what is doable.
Can we have the opinion of the developers? Thank you all for your contributions
It is something we keep talking about in the office, that we wish to do, but have to be realistic on what we are able to do.
In no particular order, a few critical items to do:
tuner improvements, nicely being lead by @brummer for which we appreciate a lot
finalize details on the “mod cabinet loader” plugin, which is more critical now due to NAM plugin consuming a fair bit of CPU
improvements (or better said, fixes) to the MIDI clock handling
deal with the max-gen online builder, which has been offline for a while now (doing this one right now)
finalize the control chain expression pedal details, needs some bugfixes and setup for the automatic firmware updates
figure out the best way to deal with WiFi, as bluetooth is not being reliable enough and even when it works it is so slow to the point of being painful
finalize the new drop&replace plugin feature, which now only needs the IO matching logic
go through the latest plugin store requests
keep up with support cases
as mentioned in Reboot retrospective and what comes next we are not really doing new developments now, it is all about finalizing the things we still had pending while doing QoL improvements along the way.
we change priorities as we see the need for it, a recent example being giving help to get the NAM LV2 plugin working nicely and bring it into the MOD platform.
but to be back on topic… one of the most likely scenarios for new developments is to convert the whole device controller (internally called HMI) to run as “dummy” display mode, I mean to move the logic behind all the button handling and drawing into the Linux system and only use the HMI side as a way to draw pixels and receive button inputs.
as the HMI side keeps growing on the amount of things it does, it also increases in its complexity and maintenance burden. it is also very hard to properly debug when issues happen, we often need to use LED colors and other indicators to pass debug information which obviously doesn’t scale…
so I think in the future we just convert the whole logic behind the HMI side and write it as a regular program, allowing much faster development, tweaks and testing too. not to mention allowing many more features that we cannot do at the moment due to its memory limitations.
I hope it would not affect possibility to switch the pedalboard, usb net/midi modes or enable recovery modes , as it is currently saving my day when more sophisticated software part goes south.
P.S.
Not sure if it is possible, but sounds to me that it would be great to have possibility to reliably switch to empty pedalboard with some kind of hw controls combination during device startup, in a similar way how recovery mode is enabled. As looks like currently - automatically loading broken pedalboard can get you into an endless loop and require unnecessary factory reset.
