Audulus Module Design Guidelines
  • Here is a preview of the guidelines that govern how things are laid out and spaced in the Audulus module library. This is an in-progress draft, but I'll have it done by the end of the day to send off to the author of Push Turn Move, a book about musical instrument interface design by Kim Bjorn.

    Comments and input is appreciated! Once this is finished, it will be formatted and placed in the section of the website.

    Keep in mind - these are just the rules for what goes into the module library, with explanations of why things are the way they are. They're not rules you have to follow if you don't want to - but they do have some thought behind them!


    Back the kickstarter here:
  • What's the rationale behind not using the built in label on knobs, inputs, etc? I rather like the built in labels myself ... you've never got to think about what label goes with what object when things get messy ... and the default spacing layout etc looks pretty good to me.

    Also text labels on i/o ... and this is some ocd shit but ... a single character text node does not align properly within the circle of an i/o port and that drives me nuts. What's the harm in letting audulus just put the i/o label where it wants to?
  • @Plurgid -

    "All modules put a premium on a condensed design. This is done to optimize screen real estate for iOS - especially for the iPhone. Tighter spacing means more modules can fit on screen before the user is zoomed out too far to patch, turn knobs, or press buttons."


    "Knobs are labeled inside their perimeter with Text nodes, rather than editing the name directly. This allows knobs to be spaced close together. Knobs are labeled with abbreviated, standardized control names. For example: a capital “A” is always “Attack,” as in this envelope example below."

    Make sense?
  • BTW Just so we're clear - this isn't anything I expect y'all to do. This is just explaining the what and why behind the design of the module library. You can choose to follow these guidelines or not, it doesn't matter to me! But if something is going in the "official" Audulus library, it will adhere to these design rules.
  • I guess I get it ... you can squeeze more stuff inside the module UI.

    You've got an infinite canvas with awesome zoom powers at your disposal though ... there's something to be said for clarity.

    Just my two cents though :-)
  • @Plurgid - totally, I get it - and I went back and forth on it for a while. But really any larger spacing than it is makes playing around with the modules performance-wise very unwieldy on especially an iPhone 5's screen - just wanted to minimize the zooming in/out for performances.

    You can see I used to label them directly in the first version of 3's module library:

  • +1 for Clarity

    Clarity is part of optimizing screen real estate, even on iphone. One of my main critiques regarding the library modules is a lack of clarity. I know that with a revamped help document a lot can be left blank, but I literally had to deconstruct several of the modules to understand what the knobs did. Some are still a mystery. One of the first patches I really understood was Plurgid's phase modulation operator, because it was kindly labeled.
    I admit that NOW I enjoy that the basic LFO is so compact, but clear labels help beginners and advanced users can make their own modules.
  • @RobertSyrett

    "but clear labels help beginners and advanced users can make their own modules."

    That's the eternal battle of Audulus - optimize for pro users, or make it more explicit for first time users. I usually end up skewing towards pro users and hope the documentation as it grows both in-app and on the website will on-board first time users.

    Attached is a control abbreviation glossary. The idea was also to explain their controls in the metadata, but no one looks at that.
    Control Abbreviation Glossary.audulus
  • I mean, it does promote new user to make their own modules because the library is too confusing. That's how it worked for me anyway ;-)
  • Take for example the Gate Summing Sequencer. How do you know what any of that is? you can read the glossary, know that there are gates to the left and knobs to the right, and you can plug in LFOs and it acts like a mixer. What is the context for using this module?

    Another legitimate reason for more generous spacing would be clarity of where cords are connected. When in/outputs are tightly packed, the input will enlarge as you hover near it and make it easy to fat finger the cord into the wrong slot. Complicating things, the bezier curve of the cord makes it difficult to tell which hole it is connected to.
  • @RobertSyrett - The Gate Summing Sequencer is an extension of the Basic Sequencer, and attaches to the same outputs as the Pattern Buffer. It should come pre-attached so you don't have to mess around with it, but I just haven't gone back to do the next round of module library revisions yet.

    I honestly only work part-time for Audulus, and I have this constantly evolving hierarchy of what to do next that I struggle to keep up with. Right now the triage is:

    1) Support questions that are easily answered
    2) Support questions that take some time, or are bug reports I have to follow up on
    3) Answering questions on the forum
    4) Working on documentation
    5) Advertising/communicating with the community
    6) Video Tutorials
    7) Beta testing/feature/module development
    8) Curating the module collection on the forum and in the app
    9) Researching Audulus opportunities for institutions and charities

    1-3 can sometimes take many hours a day
    4 is hundreds more hours of work to go
    5 is an ongoing thing I try to do about an hour a day
    6 I can't even think about again until I get 4 mostly done
    7 I mostly do in my free time
    8 is something I want to circle back to when I get 4 done
    and 9 I have some plates spinning that come up now and again

    I hope this explains why things don't always get done as fast as people would like - Audulus isn't the best it can be right now, but it will be! And input for docs like these is really a big help.

    The message I've gotten from people is that they want more better complete documentation, so most everything below that is on hold until that happens.

    In short, the library isn't meant to be confusing, and it won't be with proper documentation. If you look inside the Clock module, that's my ideal for in-app documentation. I'd also like to have more example patches that show you how to use each sequencer, but I also don't want to clutter up the patch browser too much and overwhelm newbies. It's all a balancing act.

    I'm open to suggestions to make it less confusing, but anything that would trigger another total redesign (like there was from the first Audulus 3 library that was more Eurorack-like to the new one with standardized signal flows) would take hundreds of hours of work and tweaking and would really have to be worth it.
  • For documentation, have you guys thought about setting up a wiki?
    You've got a real pool of talent among the Audulus user community that's also fairly passionate. I know if there were such a wiki, I'd probably contribute.

    Just a thought ... I know it's hard to do big things with a small team, that's one way a lot of projects do it.
  • @plurgid - yes, that would be great, especially in the future where we'll be integrating more user modules into the module library and people can add their own documentation. I want to get a solid foundation for it first though, and I'm pretty close! :) Part of opening up the docs like this in the in-progress state is to get some wiki-like feedback. Really appreciate you and everyone else who's so active on the forum! It really helps drum up enthusiasm for Audulus that spreads to others :)
  • I hope I haven't come across as too demanding, I understand that change is incremental. I would also be happy to contribute to a wiki.

    Just curious, are you going to have to redo all the documentation when Audulus 4 comes out?

    Also, a modest proposal. What if you include an added layer of abstraction between the compact iOS version and the actual guts of the module that provides a "eurorack" style of interface?
    RHS SHAPE LFO.audulus
    Screen Shot 2017-05-02 at 4.24.34 PM.png
    942 x 517 - 110K
  • I think a wiki-style piece of documentation would be a great addition the official docs. It could even be marked as a "user-contributed" so people understand its something "less official" than the "official docs".

    Semi-related (to a wiki) is some kind of versioning for patches, something like @eall123 is doing in
  • @RobertSyrett - no no no, sorry I didn't mean it to come off that way! I just wanted to lay out exactly why development goes so slow on my end. I'm also a perfectionist and the more I work on something, the more work I see I can do, and then it just compounds.

    Taylor's working on like 2 other apps at the same time too, so he's super busy as well. Just trying to give some perspective is all - I'm super conscious of how under-developed the module library is right now and will amend that really soon!

    And, no - Audulus 4 won't be a big redesign, apart from the UI for creating patches (as we're discussing in another thread) and all the info will stay the same. I may have to update a picture here or there, but that's it - the info will remain the same.

    I'm not quite sure what problem you're trying to address with " What if you include an added layer of abstraction between the compact iOS version and the actual guts of the module that provides a "eurorack" style of interface?", but I wouldn't usually put meters inside a patch like the one pictured since they would just suck up a little CPU time. It's my understanding that the light nodes use a lot less, so I like those for a really cursory feel of what's going on if there are modules within modules.

    @diego898 - I think maybe at first we have some admin approval of edits as they come in, with some discussion around changes, but I think it will be largely self-correcting like the real wikipedia is, with the most advanced users doing most of the editing. This wiki is of course something that Taylor would have to set up, so it would arrive on his timetable no doubt. And yes, we could do something Github related where you check in patches and can see changes between versions. I'll bring this up with Taylor next time we talk :)
  • Do displays use up CPU when they are inside the module? I thought they were turned off when you couldn't see them.

    My thought was you could have a more expansive explanation intermediate to the cryptic compact version and the inner workings. It's just a thought. As it was a "modest proposal" I am under no illusion that you will take it on.
  • @RobertSyrett - maybe not? Not sure I'll have to ask Taylor. And yeah have you looked inside of the clock module? That's a pretty thorough walkthrough and an example of how I want all the modules to be eventually.