Audulus 4 Module Library Feedback



This would mean all documentation inside a patch could be hidden too rather than needing lots of text boxes - you could add node by node documentation but keep a tight layout


I think I’m proposing a similar system, just using the context menu rather than the mode system. But a mode where you can add ghost annotations could be fun.


If it were a separate mode it wouldn’t take up space in the context menu and only come up when you need it. Does that make sense as a design choice?


The always coming up was why I was thinking ti should be limited to 256 characters. But the context menu already exists and augmenting it might be less hassle to program. But a whole other mode might be fun to play with.


Yeah if we think about if as three separate modes - building, documentation, and performance (lock mode) it makes some sense to wall them off from one another a little.


Well, IMO, if it’s labelled there’s no need for tooltips. Without labels modules are often obscure for me. Even my own filters that have later been formated for the library, I had to look inside to understand what the knobs were doing.

I just had a quick look at images of your beloved eurorack modules, and they almost all have labels. That just makes sense to me. I personnally almost always work with labels and larger « modules », and I’m iPad only.

Truth is, would be cool to have more text editing possibilities (size, fonts).


Even with eurorack people buy new face plates for popular modules just so they can get rid of the artsy diagrams and replace them with plain English.

Minimalism is different than pragmatic in the context of clarity. The original @sansnom moog low pass had two knobs and they were very clearly labeled.


I totally get this, but two counterpoints: even clearly labeled stuff still needs a manual. You wouldn’t be able to tease out exactly what Maths does just because it has a Greyscale alt panel.

Other point: Eurorack and hardware in general has space between knobs built in as a necessity. But iOS contends with a different problem which is screen realestate.

You could have a tooltip for each knob and one for the module itself - the module one could give an overview and the knobs say exactly what each knob does.


Yes I’d love this too - resizeable knobs and buttons would help too. Small vs big knob is a nice way to give a heirarchy to the design. Filter cutoff = big knob, but overdrive probably small knob since its usually a set and forget thing.


Let me make a “Foundation” series of maybe a dozen modules to make my case that you don’t lose much in the way of screen space to gain a lot of clarity.


edit: removed the download as I discovered some bugs. I will refine and re upload in a separate post.

I think these modules could be for people starting out. I kind of have to rush through them because I have other matters to attend to, but they show what I think is a good ratio of size to clarity.


It would be useful to have options for tool tips that come up for individual controls, for modules, and the patch as a whole.


  1. Help Mode is hidden until you need it.
  2. Select which items you need help with.
  3. Module level and control level available without having to open up the patch or sub patch.
  4. Novice users less likely to mess up patches because they don’t have to open up sub patches to learn about how to use the patch.
  5. Help is an optional part of documenting patches.
  6. Can minimize text in the GUI because the user can supplement it with tool tips in help mode.
  7. Demo patches can be created which can used as templates for users to learn how to document their patches.
  8. Users can use demo patches to familiarize themselves with how specific icons are used so they can more easily figure out other patches despite minimal help documentation by the patch author.


I think you make a good point. If you’re concerned designing about a good GUI, explore all parts of the design elements: Color, size, shape. Understood together, they can all help you learn functions and relationships and prioritize your workflow.


From my perspective as a total noob, screen real estate is the least of my concerns. I would find labels on everything far more useful than even tool tips. Then I can see what is going on. If I then understood it I could strip it down to my own specification.


Streamlining a clearly labeled module is like a perfect stepping stone to building a module from scratch.


+1 for labels - I need to often open modules to find out what stuff is. That’s worse than using up real estate (in a scroll-y zoomable space) IMO :slight_smile: