Drambo to Control Ruismaker FM
So I was playing around with Ruismaker FM today (which I'll refer to as RFM), and I thought that I really loved the sounds coming out of it.
As I spent time with RFM I realized there were many significant issues:
1. RFM loaded as an AUv3 in AUM just takes way too much screen space despite having simple controls.
2. RFM control knobs don't allow for the level of precision needed to dial in "sweet spots" easily.
3. RFM doesn't allow for track selection without triggering the sound on a selected track at least once, which is a deal breaker basically 😄.
Since Drambo is always used in my AUM sessions as my main sequencer, what if I could "fix" all these RFM shortcomings by creating a control template for it in Drambo so that I basically never had to interact with RFM's UI? It addresses UI efficiency, silent track selection, and precise value adjustment.
I was also really looking forward to using Parameter Locking with RFM, which implied having to create a control map in Drambo too. There were just too many reasons to create an RFM map, so that's what I did.
Overall this little "project" turned out to be what I would consider a convincing success, but it was far from perfect.
I ran in a few issues and I thought the stuff I stumbled upon was really worth discussing:
ISSUE #1:
The recurring theme with Drambo's modules seems to be the internal use of unipolar or bipolar values using a -1.00 to 1.00 range system. When I attempted to map RFM's "Wave Oscillator" selector (CC MIDI value range: 0 to 5) as well as RFM's "Wave Modulation" selector (CC MIDI value range: 0 to 7) to buttons in Drambo, I was faced with a hurdle:
My Buttons selectors were skipping 1 of 8 RFM Modulation waveforms.
What I did was:
- "Buttons" module sending gate value data to [needed to select RFM "Oscillator" and "Modulation" waves]
- "Knobs" module knobs sending data to [needed to control the data range output to RFM]
- knobs in "CC generator (multi)" module [needed to actually send CC data from Drambo to RFM]
Through trial and error, I eventually found out I could send custom "Buttons" gate value data of less than 1.00 (0.98 in my example) as a workaround for the data "rounding up" issue.
I had to use that trick for ONE of the 8 buttons I created to control RFM's "Wave Modulation selector" parameter so that the waveform corresponding to the 7th highest value (out of 8) would not get skipped because of math considerations.
For people not familiar with this technicality, this issue happens when Drambo's internal value range gets converted to the standard MIDI 0-127 range when output to RFM. Data values being rounded up/down cause the skipping of MIDI data values in some cases)
The buttons contained in the "Buttons" module can be named to efficiently represent each of RFM's waveforms, which is superior to RFM's own UI since it just offers a 1 button selector where users end up having to cycle between 6 or 8 values.
ISSUE #2:
I had to settle for the "Buttons" module as my selection mechanism for RFM's waveforms, as it gives clear visual feedback of what waveforms are currently selected as opposed to a knob.
However, because it doesn't have an "exclusive" button press mode, more than 1 button can be activated at once in a "Buttons" module. This in turn implies that I have to deselect a waveform in order to replace it with another one otherwise the mapping just doesn't work as intended. It's definitely not ideal, but it's acceptable.
One of the consequences of having to deselect waveform button before pressing another is that the waveform temporarily gets reverted back to the waveform associated with "MIDI CC value: 0" and this causes issues in cases where the user wants to parameter lock that parameter.
ISSUE #3:
Even thought Parameter locking external AUv3s did NOT work adequately (value changes don't affect the sound in time for notes quantized to the grid), there was at least ONE workaround that could make parameter locking functional:
That is to use step OFFSET specifically in the OFFSET sub-menu (as opposed to the COMP sub-menu) in order to dial in the smallest OFFSET value possible. This allows AUv3s the amount of time needed to process a parameter value change request right before Drambo sends a signal to trigger a note.
With Drambo as it is, if parameter locks were "fixed" in the sense that they actually accounted for step offset, we would effectively no longer be able to parameter lock external AUv3s unless a function was added to add a small adjustable "hidden" timing offset specifically for the purpose of solving parameter lock issues of this type.
Any ideas for improvements (or if someone knows how to implement a cycling wave selector button) are more than welcome!
Comments
Don’t have the time at the moment to diagnose or digest most of this post, but have some thoughts regarding the first issue you bring up - about value rounding when converting from Drambo’s native -1 to 1 value range to MIDI 0-127.
The last time I used AUM, I remember that modulation was converted to midi between apps. I don’t think AUM has built in modulators or the ability to create custom controllers (I haven’t used it in a couple years now..).
As an AUv3 plugin host, Drambo doesn’t suffer this issue. If you expose RFM parameters within Drambo, you can modulate them as though they were native parameters, even at audio rates. I know offering a different host may not be a solution that works for you, but I wanted to point out how Drambo handles exposed AUv3 parameter modulation in case you were a new user, or as of yet unaware.
@aleyas Thanks for your reply! My experience with Drambo (and iPad music making tech) is still limited even though I'm quite motivated lol 😊
It's indeed a very interesting point you bring up mentioning that the rounding up/down issues I referred to are non existant when using Drambo as a host.
I do remember back at the end of last November after buying Drambo I was testing Fabfilter Twin 3 with Drambo as a host and being pleasantly surprised by how smooth filter sweep automations were. At first I thought it was smoothing being built into Twin 3 but now with what you just hinted I'm thinking Drambo's remote control Filter knob resolution was most likely much higher than just 100 possible values (0.00 to 1.00)?
While AUM's flexibility and UI efficiency potential is just too important for me to consider letting it go as my main host app, I'll definitely be mindful of this very pleasant technical subtlety "discovery" you brought up as my learning process continues.
Could this be the dream tech that renders the NRPN headache obsolete?
About #1: I remember that I had issues with small but problematic offsets too, would need to have a closer look at the exact values
About #2: Yes, I've requested a radio buttons mode in the Buttons module long ago but it seemed like I was the only one asking for it
About #3: You probably try to fix something that isn't an issue in Drambo itself but rather in the way you're controlling AUv3 parameters. Apart from the potential delays coming from AUv3 control to MIDI to AUv3 parameter conversion, you also lose control precision by quantizing the value range into 128 discrete steps. Not to speak of some AUv3s that won't reflect param changes immediately.
I love AUM too for it's clean and quick UI and its MIDI matrix but there are 2 major reasons for me to use Drambo as my main host and sequencer instead of AUM:
As for the cycling wave selector, I have 2 tips for you:
@rs2000 Hey RS!
About the "radio buttons" mode I think what's so cool with that idea is that there really wouldn't be any need for creating another "Buttons" module entirely, just to offer additional logic options for the module that's already available (not sure if that's actually that much more efficient than creating another module though lol).
When thinking about this further, I thought that ultimately having a single button that would display cycling names wouldn't be adequate for my specific "requirements", not in the sense that it wouldn't be enjoyable/useful to have, but more in the sense that this design would be incompatible with parameter locking (I'd love to be proven wrong on that though). That might not be a consideration for use cases where users absolutely need extreme UI real estate efficiency, so of course it'd be awesome to have the option and I'm surprised you didn't get more traction when you made that suggestion since UI efficiency is the "name of the game" on iPad.
Anyhow that's why instead of the potential "giga" hassle of considering programming a button with cycling name values functionality (which I'm sure would have its fair share of implementation challenges from a UI perspective) I assume it would simply be more efficient as an intermediate solution to have a "Buttons" module logic "feature expansion" where only ONE button out of a group could optionally be selected at a time, as that would preserve parameter locking compatibility (I think?) and it would in practice at least match the functionality of a radio button even though it's less efficient in terms of UI real estate.
The more I think about this the more it feels like it'd be a useful tool to have in many applications and it probably would be worth a feature wish-list post 😃
About the cycling wave selector tips man you're a legend lol! That up/down switch circuit is impressive.
In full transparency though, I'm kind of intimidated at the thought of diving into this whole module rabbit hole (even though obviously it's just a matter of time!).
Yesterday I checked out Drambo related content on "SoundForMore Tutorials" YT channel and pinpointed all the subjects that felt useful and went over all of them in an effort not to fuck up my RFM mapping implementation out of ignorance considering the ridiculous amount of time I anticipated it was going to take me to do the mapping for RFM's 6 tracks etc.
As I kind of hinted in an earlier post I had put the whole "module exploration" thing on hold because of issues I had with the sequencer (unipolar step offset, limited UNDO functionality, impractical polyphonic step gate length adjustment, inability to program pitches on a polyphonic step without triggering audio, p-locking not accounting for step offset, etc.)... but as I'm realizing there's room for workarounds (and Drambo improves over time), since Drambo is IMO pretty much TOP 2 most important app on iPad with AUM, I'm at least trying to get past the stuff that could use getting "ironed out" as it would be stupid of me not to be at least somewhat educated to Drambo's music making meta implications. Sooner or later I'm going to have to go over Drambo's PatchStorage stuff, I've already identified Ben Richards and ZhouJing as my exploration starting point but... it's overwhelming 😅
Sure @groovegcs, learning all that takes time!
I've been working with modular synthesis environments long before Drambo was born and I'm looking back at many years of patching, experimenting, playing and messing around with nonsense patches just to see what happens 😄
By the way, since I'm focussing on what works rather than on what's flawed, I'm having much more fun with all these toys.
@groovegcs @rs2000
"By the way, since I'm focussing on what works rather than on what's flawed, I'm having much more fun with all these toys."
+1
Guys! that thing is frickin' fantastic lol
Combining that RFM mapping template with:
1. RFM Multi outs + AUM routing flexibility
2. Drambo's Song Mode (or clip launcher whatever you wanna call it!) +
3. Drambo's sequencer + parameter locking
4. Drambo's precision horizontal knob control gesture
Is just insane!
Also, as Fabfilter Pro C2 doesn't work properly in Drambo as a host (compression ratio locked to 100% despite turning the knob), that AUM setup bypasses the problem and still lets me use Drambo.
I tried my luck asking giku for a fix for p-locking external AUv3s to work without having to throw offsets on every steps... crossing fingers 😁
I might try expanding the mapping too by adding like 3 FX send knobs routing into AUM track send controls, not too sure if that can work but I'm hopeful.