For each module there needs to be a panel. This means designing and fabricating panels to expose the corresponding modules which has various overheads. We therefore can’t easily provide every possible module as a riban modular panel. So let’s consider what modules we want to prioritise…
I have started by identifying the types of modules that would be required to implement a simple synth, similar in function to a MiniMoog:
Oscillator (VCO)
Filter (VCF)
Envelope generator (ADSR)
Amplifier / attenuator (VCA)
Audio mixer (Mixer)
Noise generator (Noise)
Signal slew (Slew)
Bogaudio has created a lot of modules in the plugin that could be used for many of these - indeed I have used Bogaudio for the first few panels I have built: VCO, LVCF, ADSR. At Synthfest someone noticed this and asked why - saying that they use Bogaudio as their go-to plugin because they tend to find what they need in the collection and like the sound of them. So I am tempted to continue to use Bogaudio as the basis for the initial panels.
Ideally modules should be polyphonic and if not, have a reason why they are monophonic. riban modular is designed to be polyphonic by default so I want to avoid adding non-polyphonic modules unless there is a good reason. Of course there are many use cases where monophonic is desirable and there will be a mechanism to do this.
My opening gambit is:
Bogaudio VCO - we could use LVCO but this loses the PWM (which I think is a real boon) and separate waveform outputs (they become switchable) which I am less worried about but maybe there are use cases where this is advantageous? The SLOW switch allows the VCO to act as an LFO so I don’t plan to add a dedicated LFO (yet).
Bogaudio LVCF - I think the extra functions on the VCF compared with the LVCF may not be popular. (If course I can be wrong!) The LVCF provides the functions that I think of when I consider a filter.
Bogaudio ADSR - There are more complex / feature rich envelope generators and having extra stages, e.g. DADSR(H) can be advantageous. ADSR is the envelope that I grew up with so it feels familiar and may be something others also like but alternatives are definitely to be considered.
Bogaudio VCM - This combines VCA & Mixer. This means you end up with more inputs and controls but may reduce the quantity of panels required.
Bogaudio Noise - I am not sure what “Blue noise” is but we live and learn…
Bogaudio Slew - This can provide effects like glissando. There may be alternative choice of oscillator that may have this built-in but the abiltiy to slew a control signal seems like a very useful feature. This module has lots of controls and inputs that may prove challenging to fit onto a small panel but we can but try.
I haven’t yet looked at sequencers. I forsee challenges fitting one onto a physical panel. I wonder whether the more functional ones have lots of (hidden) controls and the simpler ones may be limited. I am erring towards the simple side initially with the possibility of building one for our purposes at a later date (using the learning from Zynthian’s step sequencer).
Please consider what modules you may want and what VCV Rack / Cardinal modules could meet these desires. (Note that plugins host one or more modules.)
Also consider how we might combine modules on a single panel. (Note that panels are the hardware that instantiate software modules.) In the prototype I have combined two Bogaudio ADSR, i.e. created a 10HP Dual ADSR panel. At least during prototyping I may do more of this, e.g. combine Noise and Slew so that I can build different panels using common hardware (PCB). It may prove unwise to do this for production as users may prefer to have separate 5HP panels for each module giving more freedom to build their desired rig. There are economies to be had by combining modules on a single panel, e.g. the cost of a 5HP panel may not differ much to the cost of a 10HP panel but chosing good bedfellows may prove challenging!
I am also designing the Universal Panel that allows adding many modules to the patch but providing access to the inputs, outputs and parameters via menus making it possible to add any (maybe some) modules without the expense of buying dedicated panels. This gives the obvious advantages of lowering cost and space with the disadvantage of more complex access so may suit modules that are seldom changed. This may also have a side benefit of allowing modules to be added that do not have (or need) dedicated panels available, hence reducing the overhead of designing and fabricating panels for all modules. It is worth considering whether the module you want is best implemented as a dedicated panel (with all those lovely knobs and switches) or as a virtual module that can be hosted by the Universal Panel.
MIDI interface is a module that also needs to be added. One might consider this as a candidate as a virtual module but some may benefit from the abiltiy to rapidly access the patching sources and destinations. The standard MIDI module has the following inputs and outputs:
Pitch
Gate
Velocity
Aftertouch
Pitchbend
Mod wheel
Clock
Retrigger (output only)
Clock divide (output only)
Start
Stop
Continue
Volume (I may not expose this)
Pan (I may not expose this)
As you can see - this would be a panel with lots of source and destination buttons, many of which a lot of us wouldn’t use (much).
It’s probably just because it’s what I’m most familiar with but I really love the jw modules’ grid seq. It can be randomized or made to be pretty organic or just play like a straight 16 step. It would definitely need some page buttons and lots of knobs though (20 I think minimum). Maybe just too much. Are you planning all knobs to be pots or are some going to be encoders? The latter with some ring LEDs would be much better I think for this sort of case so pages of knobs can show state correctly. Most sequencers it seems need a good clock module too so I’d hope to see one on the list.
I want to give a similar experience as traditional modular systems so mostly potentiometers but if it makes sense to add encoders to a module then this can be done. I’m not keen on LED rings as they tend to be low resolution, expensive and difficult to implement (physically). It may be an option and I could investigate how few LEDs are required to give a diffused ring of gradual fading / changing colour, adjacent LEDs. I only want to consider this if it is signing benefit.
Clock - yes! I’ve not looked at what’s available but a clock with tempo and divided outputs sound useful.
JW Modules GridSeq has these quantities of controls:
(16x is for the quantity of steps)
That is a lot but I fully expect a sequencer to be a large beast. Given it is likely to cost more than other panels (due to the size and quantity of controls / hardware) we should avoid investing in too many different ones and be careful in our selection. We have the benefit of being able to test these out in VCV Rack / Cardinal before comitting to design and fabrication of panels.
Virtual module designers have the temptation to add lots of features because it is relatively cheap to do so, adding small buttons, context menus, multifunction controls, etc. Physical panels have to consider space, cost and user interface in different ways so there may be features on a virtaul module that don’t make sense or are not worth adding to a physical panel. We could simply not expose these but we are likely to be hit by users telling us they always use / want that feature…
[Edit] I might try implementing the JW Modules 8Seq which is a bit simpler and provides the features I want from a simple sequencer:
Adjustable up to 8 steps
CV & Gate output
Steps can be enabled / disabled
I like th addition of the probability per step too. This could probably all be fitted into a sensible sized panel.
With a a paging scheme you reduce the number of components nearly in half, and I don’t imagine a good experience with potentiometers this way. I envisioned with grid seq a “shift” button to switch between the note and the probability knobs of the grid. Using encoders with click also takes care of the toggles there to enable/disable the gate. Agreed with the LED rings but maybe a linear fade between a few leds might help give a useful visual. Considering the module can change the knobs on its own by triggering the random note cv input or toggle button, I think encoders would be the only feasible way. It would be a complex module for sure. Maybe someone else can suggest other sequencers, I just have stuck to that because I love having the note probabilities.
FWIW I was just browsing a bit on the VCV library which gives modules a “popularity” score and Bogaudio ADDR-SEQ is nearly 1.5x more popular than grid-seq and will need MUCH fewer components.
I enjoy the discussion and doing some armchair UI design hope it helps.
I looked at Bogaudio ADDR-SEQ but dismissed it because it does not give gate output. I like the idea of being able to select which steps will trigger a gate so that you aren’t stuck with a rigid pulse-per-step trigger from the clock and as you say, probablity is a nice addition.
I will have a play with LED rings and encoders. You may be right that they could offer a good experience but I want to avoid the discrete steps that encoders have if we are controlling continuous (CV) controls. There is the option to use the (very much more expensive) RV112 continuous potentiometers. Zynthian code base supports these so our friend jofe has already done the legwork on the software side but cost may be prohibitive.
[Edit] Maybe PEC11 encoders without detents might give the desired behaviour. They may still be too low resolution but we can try different approaches to see what works best.
[Edit] Knobs switchable between functions will have to be encoders really because absolute controls (llike potentiometers) would jump to the wrong value when function switched. We can do a mute until swept type pickup function but I don’t find them very easy / natural to use. Also there isn’t such an easy way to indicate current value. Separate knobs provides instant access and instant display of value. We could use pots with push / pull switch to enable steps.
Yes, unless you press the random note or prob buttons that change the values. Regarding resolution, you can get clever with estimating velocity and scaling the step size so that you can both get to where you want without lots and lots of spinning and also allow careful fine tuned changes.
I’ve never seen those dual wiper “quadrature” potetiometers before. That’s cool. Seems like that could be ideal, but cost prohibitive. They’re also still going to be relative so the state visibility issue still stands. The Korg volcas do a pot mute like you describe. It works, but I don’t love that either.
I just had the thought that maybe you should use a few leds in a line over the knob rather than in an arc around the knob just to further divorce the idea of the rotation and value being 1-1 and give more flexibility in behavior. Maybe if higher visual resolution is required you could have a few 7seg characters that display exact values while you are turning a knob and just a low res indicator on each knob. Lots of possibilities. Lots of fun
Cut it into 5 led sections so you can indicate exactly 0, 25, 50, 100% and cross-fade between leds for any middle values. It would end up ~4cm per knob so maybe not tight enough for a complex module. Could try with 3 leds too. With a diffusive cover it might still look pretty good.
Yes, we use WS2812B LEDs. They are approx. 2mm wide and need a capacitor nearby. We could put a few of these in a line. Pots / encoders don’t want to be closer than 20mm centres so we could fit a few, maybe 6 in a line. Or maybe a couple more in an arc. There would need to be some form of diffusion and separation otherwise you tend to get too much bleed between adjacent LEDs.
I guess it would be a bar that extended with fade in of each segment to give the impression of higher resolution. I would have to play with the sequencer to get a feel of what is required. It is moving away from the analogue analogy. If we add a complex module then it may benefit from a richer UI.
I want to add a simple pot-per-step sequencer. It is a nice, simple idea that is fun to play with. Each step would have a toggle to enable the step and there would be a selector for sequence length. This is old school sequencer that seems a good first step. More complex sequencers can follow. I would not expose the random button as it conflicts with the absolute potentiometer settings.
When I built the proof-of-concept prototype (which I demonstrated at SynthFest last year), I ran Cardinal on the RPi and interfaced using OSC. This allowed me to use any of the open source modules that were compiled into Cardinal. This year I started to work on the next phase which included removing the GUI dependancy. Cardinal & VCV Rack present the modules in the GUI with cords and lights and flashy images, all of which is overhead not required by riban modular. The codebase for the GUI part is substantial (maybe over 50% of the overall codebase) and the resource usages is also substantial (maybe 20-30% CPU and a fair chunk of RAM). So, of course this should be removed and my plan was to write riban modular core code that hosted open source Cardinal / VCV Rack modules and stubbed the GUI functions - that is, implement empty functions that are called by the modules for its GUI. In trying to do this I have discovered that it is rather challenging because, not only does Cardinal provide GUI functions and handling but it also provides a canvas to each module onto which the module can draw, using any of the GUI toolkit’s functions - so to stub this I would have to stub every function in the GUI toolkit. GTK has thousands of these so it is not a pratical approach.
This means I doubt I can write the core code to host VCV modules directly, without significant modification to each VCV module’s source code.
I wonder if anyone has any suggestions on how I could implement the original (stubbing) plan?
If I can’t do that then I may need to reduce the aspirations of the project to provide a smaller quantity of curated modules. (In many ways this was already envisaged because each module needs a hardware panel but I had hoped to share similar hardware panels with multiple modules.) Of course, modular synthesis is about choice and users may expect to be able to select from a very wide range of modules which may be constrained by such a curated approach.
I would love to hear any ideas on this matter. I will continue to investigate the stubbing idea but a spark of inspiration from the community (or Ether) may lead me to a solution I am yet to comprehend.
I am considering offering two catagories of panels:
Common or popular panels - panels that many users want and have a fairly high demand
Less common / popular panels - panels that fewer users want and have a fairly low demand
The common panels may be stocked and available for rapid delivery (within days) whilst the less common range would be fabriacted on demand with a longer delivery time (weeks). This would resolve a significant issue I have with on-demand production of front panels at an acceptable cost. I could offer a premium service for rapid delivery of the less common range (probably about a week) at a premium cost (maybe +£30). I haven’t done a detailed analysis of this approach but these estimates of time and cost seem about right.
If this approach were to prove acceptable to customers then it could unblock one of the obstacles I have been struggling with.
hope it helps.