MOD UI improvements for creating connections

Contribute Feature Requests
#1

[Moved from Management of FOSS community plugins in the MOD Plugin Store]

Another point is that if you are thinking of generating an income from the use of audio plugins, the use of audio plugins should be as simple as possible.

For example, adding a plugin to an empty pedalboard involves 4 steps: 1. removing the bypass connection, 2. adding the audio plugin to the workspace, connecting the audio plugin to the 3. input and 4. output.

If I want to test another plugin, there are several more steps. If you want to replace, there are several steps. If I want to add an audio plugin between two, there are several steps.

Remembering that the steps are costly:

  1. Release the instrument,
  2. put your hand on the mouse,
  3. execute the the steps, that includes:
    1. drag the pointer to the option
    2. press the left mouse button
    3. drag the pointer to the destination
    4. release the mouse button
  4. Pick up the instrument again.

Other similar equipment on the market allows you to replace one plugin with another with few button clicks.

An interesting option to buy would be to test before. Ideally it would be a possibility to test for some time (like the MS Zoom 100bt had)


, but a refund option before a few minutes or hours of use may be enough.
It is expected that the developer using the platform to market an item will make available plug-in videos and audios.

If they can easily replace one audio plug-in with another on a pedalboard, an interesting addition would be a recommendation system that lists audio plugins installed and available in the store.

Out of curiosity, I’m starting a master’s degree in Computer Science. I’m just studying IA for audio plugin’s recommender systems. I thought about using your database (pedalboards.moddevices.com), but the database is very small (few shared pedalboards for many audio plugins).

2 Likes
Management of FOSS community plugins in the MOD Plugin Store
List of feature requests (MOD Dwarf)
#2

Hi @SrMouraSilva, a little late to chime in but hopefully not too late.

We appreciate your comments. We’ve certainly thought about all those problems and have plans to address them in the future. Creating an easier to use UI sometimes conflicts with the idea of giving total creativity freedom.

We do have plans to address the issues you described in a future version though. Keep tuned!

Cheers,
Alex.

5 Likes
#3

Creating an easier to use UI sometimes conflicts with the idea of giving total creativity freedom.

I feel much the same as @SrMouraSilva. Before proceeding, let me clarify that I love the Duo and all the work the team has put in.

The pedalboard interface is beautiful to look at and I think also serves as a great marketing tool. Whenever I’m explaining about the Duo to others I typically show them one of the pedalboard screenshots so they can have that “A-ha!” moment. There are certainly some nice advantages to the visual aspects of the pedalboard interface in terms of overall presentation, browsing, and quick recognition. However I find the actual process of creating and editing pedalboards one of the most frustrating aspects of using the device overall.

This is all highly subjective of course. As a long-time web developer who has recently gotten into music, I’m often a little disappointed in the UX of the digital audio software ecosystem. I understand that are longtime historical and cultural reasons for the dominance of skeumorphic designs in this realm, and that there is a tremendous amount of momentum behind doing things according to long established traditions.

As @SrMouraSilva points out, a standard operation such as adding a pedal into an existing chain becomes a tedious process. There have been a number of times where I’ve ended up inadvertently removing other connections or adding unintended connections. “Let’s see what this sounds like” becomes a few minute exercise in rebuilding all the connections. I find that I am frequently dragging the pedals around to different locations in order to keep the signal paths visible. There’s no per-pedalboard visibility into which controls are mapped to hardware and making changes here requires another multi-step click/press/touch process per control. In comparison to say configuring a new Ardour session from scratch with a track or few, each with up to several plugins attached, and assigning a few hardware mappings - it feels like an order of magnitude more time to get to a similar result via the Duo interface.

I hope I’m not complaining - just sharing experiences. In the spirit of being a contributor it is on my wishlist to find some time in the next few months for putting together some alternative interfaces or utility tools that could run on the MOD SDK, and which would help with some of the workflow pitfalls I and possibly others are encountering.

7 Likes
List of feature requests (MOD Dwarf)
#4

My own experience is that I do occasionally create unwanted connections when moving pedals around but it’s a small price to pay for the totally flexibility of being able to do the most intricate of parallel audio paths, or processing separately the two outputs from a stereo delay. That level of specification is one that no dedicated audio hardware unit that I’ve had can handle, and I greatly value that set of possibilities over losing any of that in favour of a drag and drop audio chain ala the various iPad audio processing apps…

5 Likes
#5

Maybe inserting a new plugin might be eased by simply being able to drag and drop the plugin box onto an existing cable which would then get split in two ends that would connect themselves to the most “obvious” input and output sockets.

I agree that it sometime may not be that easy to determine the obvious sockets, but it many cases it is.

Allowing disconnecting/reconnecting a cable on the source end might also help.

As for the reverse process (i.e. deleting a plugin) : adding a second “suppress” button that would not delete the input/output cables but connect them into one could also greatly improve the whole process without causing too much of a change to the general logic of the interface.

6 Likes
#6

These would both be useful for me, for sure…

1 Like
#7

For me, flexibility is also a major selling point. But there are ways to improve the UI; drag&drop and avoiding the deletion of connections when pedals are removed, were mentioned already. I’d actually find arrangements to a grid really useful or intelligent distribution carried out by an algorithm. Graphviz is something widely used for drawing all kinds of charts and might be an inspiration…

I only have simple pedal boards, but often want to hear pedals in different positions of the chain. To automate this, would be the third most important Duo feature for me (after, loading impulse responses and having an expression pedal). Application could be: select two or more pedals, click a button which disconnects the cables, shifts the pedals accordingly and reestablishes the connections.

2 Likes
#8

I also have some sort of grid feature in mind, with the understanding that each visual paradigm will have its own set of limitations.

If we assume that pedalboards are DAGs (directed acyclic graphs) then grid or tree style UI components could serve well. Boards can be constructed that aren’t DAGs but I’m guessing the majority in existence are.

1 Like
#9

@unbracketed Thanks for your feedback, greatly appreciated.
I have bookmarked your post so I can revisit it later when the time comes to improve the UI.

Based on the feedback I’m seeing here I might try a few things in the current UI to improve on those problems pretty soon (hopefully for 1.6). However a full redesign will be needed at some point to properly address those concerns. Rest assured that I feel the same way about the UI as you do and it’s definitely in my backlog to get them fixed.

On a side note, I’m very happy that we have a reasonably good enough UI which brings new ideas and starts new conversations about how we can make things better. This means we’ve touched something deeply important to all of our users.

Keep the ideas coming!
Alex.

4 Likes
#10

@Azza I’ll be working on some improvements along those lines soon. I like the “suppress” idea of yours.

4 Likes
#11

We internally call this the “stomp-box mode”. We’ve been back and forth many times about building this sort of UI but it certainly brings more limitations and will cause a split in the UX forcing the user to think ahead about building a simple vs. complex pedalboard. Later on the user decides to do something more complicated and it prevents him from using the stomp-box mode again on that particular pedal. This will be a source for many many bugs. Having two separate ways of doing the same thing is most likely not the right solution. I rather improve the current UI and make it good enough for both use cases.

@eggsperde Your example is a perfect one. We should allow our UI to accommodate all use cases without creating much hassle. We should not force the user to pick which kind of UI he prefers. More options will be a lesser experience in my opinion.

1 Like
#12

@acunha, @unbracketed: On a scale of 1 to 10 - if you had to put a number on how efficient / practical / restrictive the current UI is, how would you rate it? There are some things I would improve, but IMO there is many more that could be worse. I guess what I am saying is: the fully flexible arrangements and skeumorphisms are fine with me and I’d prefer a evolution over revolution.

#13

@acunha: Look very much forward to the next Beta phase! Are you guys already working on it?

#14

Just at the requirement level for now. I want to experiment with a few ideas first to see if I can find a few quick wins.

1 Like
#15

Hello,

A suggestion, Mod-ui provides a REST and WebSocket API for management.
Since support for multiple views is difficult, you could document what mod-ui already provides.
Other developers could create applications or programs by consuming the API.

I’ve thought about trying to send some pull request to the project,
but I do not feel comfortable with the architecture of the html / js pages of the project.

If there was a documented api (with API Blueprint + Aglio, Swagger + ReDoc or similar), I or any other developer could create other forms of control.

Hugs.

3 Likes