I am (painfully) aware that the design of riban modular limits access by many potential users. Its current design relies on the user having sufficient mobility to be able to reach the hardware, push buttons and adjust knobs. It relies on the user having sufficient eyesight to be able to distinguish between several different coloured indicators and to read panel legends that may be small. The signal flow and consequent sound design relies on users having sufficient cognitive ability to understand the process. Financial accessibility is an important consideration. Users have constraints on their finances and will choose what suits them on a cost / benefit decision.
I want to consider how we may improve the design to allow more wide adoption and access for as many different users as practicable. This is a subject that I am passionate about and know that early consideration of such elements within the design process results in better access for all (rather than trying to bolt on solutions later.) To that end I want to engage with all users to consider how we can provide the most accessible implementation of riban modular.
The core principle of riban modular is to provide an implementation of sound design using tactile control panels at the most affordable cost possible. These goals already touch on some accessibility points, e.g. cost, tactile. I will try to break out some of the elements of access here and start a discussion on each.
Visual
Initial designs of riban modular use coloured illumination to indicate state. This may indicate that a button is an input or output, that the button has been pressed and is involved in a routing operation, an indication of a parameter state, e.g. waveform shape, etc. I see a few issues here:
- Users with limited luminosity detection (including partially and fully blind users) may not be able to identify an illuminated indication at all
- Users with different colour or hue perception (including colour blind users) may not be able to distinguish between different illumination states, e.g. colours
- Users with limited contrast perception may not be able to distinguish different or (slow) changing light intensity
- All users may not be able to read written legends, e.g. if they are low contrast, wrong size or font, etc.
Initial consideration of these points included:
- Selecting illumination colours that differ in hue significantly in the most common colour blind modes
- Allowing user to select colours
- Allowing user to select illumination intensity
- Testing different font types and sizes
- Testing different panel and silkscreen colours
These may address some of the issues for users with reduced or altered sight including colour blindness and contrast perception.
There should be alternative indication of all states to increase access for users without sufficient visual sense to use any or all of these configurations. It may be advantageous to provide an audio monitoring output that includes audible state indication that is not sent to the main (front of house) outputs, e.g. spoken indication of state.
These are the core components and some suggestions for how they may be accessed:
- Knobs - All knobs are tactile rotary or sliders. Most have absolute positioning, i.e. their current physical position (rotation angle or slider offset) reflects their current value. If a user is able to learn the location of knobs then each knob’s physical position could be identified. For sliders this could be provided by some zero value identifier such as a raised lip or edge of panel so that user can feel where the knob is relative to its end stop. For rotational knobs, some form of pip or physical pointer may allow a user to feel its current position. (Note that this differs to the current design that uses knobs without any such physical pointer other than a line in the top cap. This was chosen for aesthetic reasons.) It would be useful to know how much benefit such a design would provide and what are better and worse designs, e.g. points that protrude from the body of the knob, engraved indications in the cap / top of the knob. It may be beneficial for the value of a knob to provided by an audible method, e.g. spoken value. This may better suit discrete values. The main purpose of riban modular is to allow dynamic control of values and hear the results. The above suggestion of a physical indication of position may be preferred to a spoken indication.
- Knob scales - Each knob will traverse a range or set of values. These will normally be visually indicated on the control panel using a silkscreen or similar. It may be beneficial for the range of a knob and its purpose to be identified in a non-visual way. This may include spoken indication of the knob or learned knowledge, e.g. information about a panel’s controls in a non-visual presentation of documentation (or text to speech enabled interface) and user learning the physical location of the knob. (I am insufficiently experienced to know how acceptable this is to the wide range of users that may rely on this.)
- Buttons - Most buttons are tactile press and release operation with an audible and tactile click on press. I believe this provides significant feedback to all users that the button has been pressed and released. There may be lever type toggle switches which are very tactile with intrinsic positional indication but these are not currently planned. Push buttons will change state which is generally indicated by the button being illuminated, using different colours and light intensity, e.g. flashing to indicate the state or value. A button may toggle between two states, switch between several values, change behaviour based on duration of press, etc. I think an audible indication of a button’s state could be advantageous. This could be a tone or spoken phrase that indicates the state. I think using tones to indicate short, long and held actions could be beneficial and complementing this with spoken phrase for current value or state may be a good option, e.g. a short beep for press and release, a longer beep for long press and a longer or different tone beep for hold. The first short beep may not be required if the state is indicated and the user can feel the button press. The other two may be beneficial if the state or value is not obvious or announced.
- Illuminated indications - Panels can have lights that indicate a value or state. These may not be directly associated with a button. Such an indication may change state to respond to a user action, e.g. waveform selection from a single button in which case the above button indications probably apply. An indication may change to reflect some other state change, e.g. a trigger pulse. Audible indication of such events would almost certainly be inadvisable, immediately becoming a cacophony of sounds that are mostly indicating states the user is currently not interested in. It should be possible to enable and disable audible indication of such state indicators. How this is done may be a challenge. There is a module that acts like multiple modules with a display and encoder and buttons. That module provides a menu diving method of accessing parameters which of course needs separate accessibility consideration but maybe a similar module might be utilised to allow selection and configuration of such audible indications. There would need to be some balance between complexity and space, e.g. it may need some form of menu type workflow, e.g. to select the module and select the parameter and enable / disable audible feedback as well as querying what is currently enabled and maybe disabling all. I will add a bullet below for menu driven modules.
- Routing indication - The interconnections between modules is done with push buttons and indicated by the colour and lumination pattern of those buttons. During a routing operation a source button is pressed to start the route. That button flashes to indicate it is selected for routing. Any destinations to which the source is already connected light and all other destinations extinguish. Pressing a destination button will connect or disconnect and complete the routing operation. There could be a spoken phrase to announce the list of currently connected destinations. Traditionally analogue modular synths tend to have a single connection. riban modular allows multiple connections but I would imagine that the list would seldom be very long. To avoid long and invasive announcements, a beep could indicate successful completion of the routing although it may be advantageous to confirm the correct source and destination have been connected or disconnected. There may be a challenge for users to find the correct routing buttons. All buttons feel the same and their names are shown as text on the panel silk screen. I am eager to hear any suggestions, particularly from experienced users of how they currently navigate tactile surfaces. Braille labels may be an option, e.g. dedicated Braille alternative front panels. This may not be a universal solution. Some users may not be sufficiently familiar with Braille. The presentation may be challenging to implement within the available space. The cost of dedicated panels may prove prohibitive.
- Rotary encoders - There is currently only one module that uses a rotary encoder but a previous point suggested it may be advantageous to implement a similar panel to configure audible feedback. Rotary encoders are tactile and can provide some physical feedback by way of indents or clicks but do not give absolute positional information, i.e. you do not know what value they currently represent. They tend to work with some form of feedback indication, e.g. a graphical display or audible tally. Modules that use rotary encoders should provide audible feedback of the state of the interface they are driving. That interface should ideally be configured for the user, e.g. a sighted user may have a graphical menu and parameter system whilst an unsighted user may have an audible menu and parameter system. It may be possible to combine these two to have a common menu system with option of audible feedback.
- Visual displays - The only graphical display currently designed is a menu and parameter module that can emulate any other module. As described above, this may be emulated with audible feedback, e.g. text to speech indication of the menu and parameters names and values. There may be complex modules that require graphical user interfaces implemented in visual displays rather than buttons and lamps as described above. I am trying to avoid these but if they prove necessary their design should be done with accessibility in mind.
- USB computer keyboard - There was no plan to add support for a USB computer keyboard but it may prove advantageous for driving some elements of riban modular using a command line interface. This may allow users to type commands, mnemonics or single characters / shortcuts to trigger operations including setting and querying states. Combined with the previously mentioned audible feedback (tones and speech) this may offer a rich interface for control and monitoring of the virtual states within riban modular, e.g. routing, discrete values, etc. Combined with the tactile physical interface of knobs this could provide a significant increase in accessibility.
- Building and operating a rig - A riban modular rig consists of a Eurorack enclosure, external power supplier, Brain module and several control panel modules all connected via a ribbon cable. Some construction aspects may be awkward for users without full sight. These may include identifying panel type. Previously mentioned solutions may include Braille or user recognition of physical panel layout. Interconnection is with a cable and plugs that push into sockets on the back of panels. These are physically keyed to avoid incorrect insertion. An unsighted user should be able to make these connections. Panels are placed in the enclosure and screwed into position with M3 screws. These can be awkward for anyone! An organised approach and physical dexterity are significant factors. The choice of enclosure (not provided by riban modular) may also help, e.g. threaded bar inserts may be easier to locate with screws than free moving captive nuts.The power connection is via a concentric plug. This should be fairly easy to identify and cannot be plugged incorrectly but some form of identifier to distinguish from other sockets like audio sockets may be advantageous. Audio is plugged with 1/4" jacks. There are 2 inputs and 2 outputs which are aligned so should be able to be identified by location. USB type A sockets are positioned towards the top edge which will hopefully aid users locating them.
Suggestions from experienced people will help with all of this.
Physical
riban modular is by nature modular. It is anticipated that a typical rig may consist of many modules which, despite the small Eurorack format will still be a considerable size. I expect a minimal system to be about 104HP. A user who’s mobility prohibits them from reaching such a large device may benefit from smaller, closer modules or some other form of control. There is a module called the Universal Module that uses an encoder and display to implement menus and parameter editors that can emulate any other module. The CAN bus that interfaces modules together can be extended beyond the enclosure. A user could have a small enclosure within closer reach that uses such a module to provide access to most features. One of the core principles of riban modular is to provide a tactile experience similar to traditional analogue synthesisers. It uses technology similar to virtual modular systems such as VCV Rack, Cardinal and Nord Modular. There may be limited benefit in trying to re-implement these alternatives that already provide computer hosted environments that some users may already be equipped to use. That is not to say that riban modular cannot have good accessibility for users with limited mobility but that it should not strive to solve problems that are already solved elsewhere.
The modular nature may allow enclosures to be built that are within easier reach of users. Modules are interconnected via a cable that may reach many metres so the physical structure could be adapted to improve physical accessibility. I feel this is a subject of its own that I invite users to consider.
Cognitive
Just like any modular synthesiser, riban modular provides pretty much unlimited opportunity to experiment with sound design. Interconnecting modules and adjusting parameters leads to unexpected results that are often more valuable than some intended target. This means that all users are equally likely to create magic no matter what their comprehension of sound design. riban modular, once plugged together is a bank of knobs and buttons which a user can press and twiddle until something sounds good, bad or interesting. The core element that needs understanding is routing or interconnecting signals. The use of colours to indicate sources and destinations may help users understand what goes where as well as the routing workflow that only allows sources to be connected to destinations. This differs from traditional modular systems which allow anything to be plugged together in potentially damaging ways. Some form of workflow demonstration or instruction may be beneficial, e.g. the system could have a demo mode that shows the effects of various operations. It could have an educational mode that configures the system with a preset routing then allows users to adjust knobs to hear the effect. There could be an option to disable routing so that a configuration could be set up or recalled and then just the knobs and parameter switches work, allowing users to experience the effects of those without changing routes.
Financial
One of the core principles of riban modular is financial accessibility. Every part is designed to minimise cost. It is also open source software and hardware (where possible or practicable) which allows users to create their own devices with components available to them which may prove lower cost. (Cost is measured in time, effort and financial outlay so differs from person to person.) The circuit diagrams, PCB layouts, source code, etc. will all be freely available. (This has not yet happened to avoid undue support burden during early design stages but should be exposed soon.) There is the Universal Module that can be used to replace many other modules with full (or near full) features but reduced direct / immediate control and monitoring, using menus instead. This can reduce costs dramatically, with one module replacing several. There may be initiatives to make hardware available to some users at reduced cost, e.g. subsidised by other investors. The margins are already kept as low as possible to support financial accessibility so there is limited option from riban ltd but we may be able to partner with others to further improve this. There could be a voluntary contribution fund. There could be bulk buying opportunities, e.g. if educational institutions shared resources. I continually look for opportunities to reduce costs and am eager to hear from others with experience in such areas.
I find that concepts discussed or implemented with improved accessibility in mind often lead to improved overall access for all users, e.g. the ability to drive a device with a command line interface can often provide all users with a tool that supports various workflows.
Please help us to make this a device that is accessible to as many users as possible. Please add any other accessible options that I may have missed. Accessibility is the ability to access something. It is not about disability. It is the positive access for all. Good accessibility benefits everyone, not just the few.