A Year of Dome Music Technologies

[utdgrant]

The first Dome Music Technologies product to hit the CA Store was the RAT Pack Bundle, on 8th March 2022. I thought the anniversary would be a good point to reflect on my experiences as a developer over the past year.

I'm going to write a multi-part blog post about this over the next few days and I hope you'll indulge me. It will definitely be of most interest to other developers (like those who hang around in the Module Designer forum). However, it could be an amusing insight for VM users, too. I hope you can take something away from it, anyhow.

Part 1 - Beginnings With Voltage Module Designer

I downloaded the Voltage Module Designer development kit in early Jan 2022. I wanted to see how easy or difficult it would be to work within the development environment and to see if I was cut out for developing real-time audio DSP code. I’ve been a professional software engineer all my working life (~35 years), working mostly in real-time and embedded applications, so I was better placed than for example an SQL developer or someone who works in financial programming. My language of choice is C, with C++ in a close second-place, so Java was very familiar in terms of syntax and underlying concepts (particularly with C++). That side of things wasn’t a problem at all.

The actual VMD development environment is pretty friendly, and presents you with a good set of tools specifically tailored to creating VM modules. Installation is pretty straightforward - even grabbing and installing the OpenJDK Java environment is easy if you follow the instructions carefully.

There aren’t many YouTube tutorials about working with VMD. In fact, at the time, I could only find the original Cherry Audio one presented by Dan Goldstein. More recently the Aaron Lanterman one appeared.

The first modules I chose to create were both based on a simple RC charge-discharge circuit. I wanted to recreate the envelope generators of the Jen SX-2000 synth and the portamento circuit of the Korg Micro Preset M-500. The mathematics of RC circuits are very well described and it was surprisingly easy to implement their formulae within the framework of a VM module. Within hours of starting, I had a working module which would play nicely with the modules of VM Nucleus. Admittedly the user experience and panel aesthetics left a lot to be desired at this stage!

I refined the designs of what became the Big RAT and Smol RAT over the next few weeks until I felt they were ready to go live.

to be continued...

[Centripidity]

An interesting read. I look forward to more instalments.

[utdgrant]

Part 2 - Going Live with The RAT Pack

There is obviously a lot of work involved in the actual creation of a module. You need to get your algorithms clear, debug the code, make sure the UI is as ergonomic and intuitive as possible, then cross your fingers and hope that it gets through the CA approval process. To date, I've never had a single module rejected by CA, although I have made updates based on user feedback or my own findings.

However, having a working, approved module is only about 50% to 75% of the story.

From the beginning, I wanted to make sure that modules were fully documented. Even if the modules made complete sense to me, and if I felt the UI was intuitive to the point of not requiring an explanation, I always wanted to make sure that there was a user guide which explained the function of every knob, switch and socket. This was an absolute minimum baseline; more complex modules would require a description of their internal 'schematic' or logic flow.

I also wanted to ensure that every module or bundle contained a few presets which explained how to use my modules within more complex patches, as a kind of tutorial. To date, the only module which doesn't have a specific preset pack is the Simple Amplifier. Even then, there are screenshots of how to use it as a VCA and Ring Modulator in the documentation.

On top of that, I also wanted to create 'adverts' for each new module on the Dome Music Technologies YouTube channel. For more complex modules, I would also create demos and tutorials as appropriate. On my personal / band channel, I had used Windows Live Movie Maker (and more recently MS Photos) to create videos. However, the audio quality was always suspect from these two applications. Above all else, I didn't want compromised audio quality for module adverts. So, I switched to a combination of OBS for video capture of the VM environment and Kdenlive for editing. That has seemed to work well so far for my limited video editing skills.

Next, I had to consider pricing and demo length before going live. In the VMD documentation / FAQs, it stated that the minimum sale price for a module or bundle was $5, and I didn't want to go higher than 'pocket money' prices. So, the price of the RAT Pack Bundle was set at $5. It was also extremely important to me that people wouldn't have buyer's regret for any of my products. For this reason, I set a generous demo period of 28 on everything so that it could be thoroughly evaluated within your own setup before parting with your cash. That's a policy I've stuck with ever since and I'm really happy with it.

to be continued...

[Steve W]

I was waiting for the next installment with anticipation. It doesn't disappoint. Thanks for writing up these details. They are chock full of insights!!!

[Centripidity]

Yeah, my somewhat more limited experience accords with much of what you've said. When I started I also noticed the $5 minimum but that doesn't seen to be enforced.

[Centripidity]

Another comment I would make, and perhaps it won't be popular, but the issue of "demos" for a module is important. Your policy is very generous, mine is, so far, to offer 7 days, but perhaps yours is better. I did that because I thought that was enough to evaluate but I have the luxury of being retired and so I don't need any longer, maybe others do.

Honestly, I think CA should enforce a minimum demo period. I understand why they won't but I think it would be very helpful to users, and isn't that why most of us manufacturers are here? Yes, releasing modules to the CA store is a revenue stream but, for most of us I suspect, it's a very small revenue stream and we do it because we made modules we wanted and we'd like to get a few bucks back and a bit of recognition for our efforts, knowing that someone else values what we thought was interesting and useable.

I know there are manufacturers here who are doing this because the revenue is important. I get that and don't want to compromise that, but I also know that one of those manufacturers has possibly the most sensible/generous demo policy in the CA store.

I've seen modules I think are interesting but they offer no demo. To me, that's a lost sale for them.

Seriously, if you have a protected software product to sell, why would you not offer a trial period? To me, and I say this as a theoretical user and not as a specific statement about any product or store, why would you not offer a trial period unless you thought users who got to trial your product would be disappointed enough to not buy it?

[Steve W]

I've seen modules I think are interesting but they offer no demo. To me, that's a lost sale for them.

This should really be discussed in another thread, but I agree. It is a module-maker's decision to make, but to me developers who say, "Buy it first and if you don't want to keep it ask Cherry Audio for a refund" are not the kind of developers I would want to support. But that's my decision as a potential customer.

On the other hand I am more likely to buy modules from a developer who has let me demo some modules that I ended up not buying.

Perhaps there is a tax benefit to charging and giving a refund over offering demos. Maybe someone who shows a ledger with sales and refunds can claim deductions that can't be claimed if there are no sales. ("No home studio deduction for you. Its a hobby, not a business.")

[utdgrant]

Part 3 - Lessons Learnt from the RAT Pack

There were two main lessons which I learnt from the development and release of the RAT Pack Bundle:

Lesson 1 - Don't try to cram too much funtionality into a single module.

This rule of thumb applies specifically to the Big Rat. My initial idea was to have it as a simple repeating envelope, with secondary functionality as an LFO. However, the more I worked on it, the more potential applications I realised I could squeeze out of it. Often, this would require a simple tweak to the design in order to extend the functionality, so I followed up each of these in order to increase the Value For Money quotient.

These included:

Slow / Fast / Audio range switch so that it could be used as an audio-rate oscillator.
Bi-Polar output.
1V / Oct control over Rise and Fall times so that it could be 'played' as a VCO.

The more I played with the development version, the more potential applications occured to me:

Gated / Synced LFO
Gated / Synced VCO
Ratcheting envelope generator
Zero-Crossing Detector / 'Guitar Synth'

However, on release it became apparent that in order to configure the module for these operations, you would really have to have a deep knowledge of how the module worked 'behind the scenes'. And, to be honest, that's probably a poor use of your time as an end-user (even if that user is me!). It's far easier to buy a module which is specifically intended as a ratchet generator than to get your head-space into the 'Big Rat Zone' in order to wrangle it into that purpose.

It's certainly different in the hardware world, though. If you spend a lot of money on a flexible, configurable module, then spending a bit of brain power to mould it to your purposes is probably a good trade-off. Especially if that one flexible module can take the place of several single-purpose units (Make Noise Maths, for example). In the VM world, however, I think a focus on a single specific use for each module is the best approach. (*Just my opinion, though).

Lesson 2 - Don't make several modules with the same colour scheme and panel layout.

This is what the Big Rat and Smol Rat looked like for most of the development time:

AllBlueRatPack.jpg (287.1 KiB) Viewed 4574 times

Whilst it looks very pretty, it turned out to be a nightmare for tweaking patches. Thankfully, I changed the colour scheme of Smol Rat to be tangerine before release!

[ColinP]

Thanks for doing this blog Grant.

It's interesting to read about other people's experiences and it'll be very useful for any new developers.

On your latest points...

Lesson 1: I agree up to a point. But the opposite can be true too. Often I feel frustrated by having to patch together two modules to achieve what should be provided by one.

For instance ever envelope generator could have a VCA bundled in with it as it only costs two extra sockets and having to combine DC Source with the Attenuverter is a pain when there ought to be an offset control in the Attenuverter.

Lesson 2: Again agreed up to a point. A sea of black panels with the same regular pattern of knobs and sockets a la Moog might look neat but as you say it's hard to navigate.

But all kinds of weird colors looks a mess too. Distinctive layouts and panel graphics are one route. Another would be user customizable skins. But unfortunately skinning is much more difficult than it should be in VM. It's crazy that the API doesn't even provide a means of changing the color of a plain panel's background.

Anyway, looking forward to more from you.

[utdgrant]

Lesson 1: I agree up to a point. But the opposite can be true too. Often I feel frustrated by having to patch together two modules to achieve what should be provided by one.

For instance ever envelope generator could have a VCA bundled in with it as it only costs two extra sockets and having to combine DC Source with the Attenuverter is a pain when there ought to be an offset control in the Attenuverter.

I think we're actually on the same page with this. I was talking more about configuring Big Rat in fairly non-intuitive ways in order to squeeze extra functionality out of it. The ratcheting envelope functionality is one example of this:

BigRatRatchet.jpg (135 KiB) Viewed 4524 times

I can totally understand why Bob Moog wanted to have a purist 'laboratory' approach to the original 900 series of modules:

What I mean is that most modules have CV inputs, which operate on a 1V/Oct basis (where appropriate). This allows you to modulate the module's parameters using any voltage source you desire, simply by connecting with a patch cable. He also provided stand-alone attenuator modules in order to tame the huge output voltage swings of source modules - using an LFO for vibrato, as an obvious example.

HOWEVER, given that attenuators are almost entirely essential, it was a poor design decision of Moog to make the purchase of (multiple) additional modules necessary. Especially given the price of those modules! (Maybe "poor design decision" = "astute commercial decision"! )

When ARP introduced the 2500 series, they provided all sorts of input and output mixers / attenuators within each individual module. Maybe less 'pure' in a scientific / mathematical sense, but from an end-user's PoV, a far more useful and practical approach.

Still, in saying all the above, I find it fascinating (and fun) to patch up VM900 and to get an insight into the user experience of the pioneering musicians and composers from the early days of electronic music. Plus, within the VM world, you can patch in as many attenuators as you want (900 series or CA stock) without having to worry about your wallet!