Audulus 3 Library Reface


Here’s last one for tonight featuring a demo! It’s very high-cpu and might only work on a computer or more powerful iPad.

EDIT: actually it works quite nicely on my iPhone 7+! Could even screencap it while playing.

I suggest opening it up, listening to it, and playing with the tempo. It sounds great fast and slow.

Audulus 3 Reface (251.1 KB)

Audulus 3 Reface Demo 1.audulus (1.0 MB)


reface suggestions.audulus (206.3 KB)

Ok, I spent about an hour going over the 0.3 reface collection and I like what I see. I think the clock module could use an external run gate, and the attenuverter module should be capable of attenuating audio as well as modulation (it’s super cheap in terms of CPU), but other than that, not a lot to critique. Oh, well actually I think you can ditch the centered modulation attenuator as its features are already covered by the attenuate/offset module and I think most people would think to use it.

I began to try and adapt some of my favorite modules from my personal library to the new format, but I realized I don’t know the formal design language for spacing things and what you have planned for the contents of the empty folder. But i made a quick list of the things I wouldn’t mind seeing added and put them in a separate doc.

a few of my favorite things.audulus (286.0 KB)


I only got rid of it cause I thought no one used it, but if it is useful, then I’ll definitely add it back in!

Can definitely do that, and was wondering if to add it in, but I’m not sure when/where people use it? Just to add stereo separation or something?

I’m sorta making it up as I’m going along, but you can tell module titles are at the top, there’s a certain spacing between knobs, when possible modules fit into small, medium, or large+ modules…etc. If you get them close I can just move stuff around until it fits too! :slight_smile:


Questions about these:

1 - The VA AR is in there as “Basic Envelope” already - it’s a little different design, but if there’s something you like about @sansnom’s that I can incorporate, let me know.
2 - Do we need the octave shift module if all the oscillators have built in octave shifts?
3 - Didn’t you make a resetable divider/multiplier? How’d you incorporate that?

Everything else will definitely go in! :slight_smile: Other peeps - let me know if there are modules you definitely want to see in the collection.

I’m going to cut back on some of the redundant modules that are present, like for example: have 1 8 step sequencer that lets you select start and stop in sequence, rather than a 4 step sequencer also. But other stuff is staying in, although they might be combined into one module, like the Sample & Hold module now does both internal random sampling and external sampling, externally gated, etc.


I like the overall design aesthetic. As much as I liked the graphic labels, they could be confusing. The uModules were great for conserving screen space, but were often intimidating for the new user. As always, you’re faced with trade-offs. You could save some CPU if the basic VCO had a waveform selector rather than 4 oscillators, but again, it’s a trade-off. I like the multi output master clock, but the labeling is a bit obscure. I initially took 1b to mean 1 beat, but its actually 1 bar (assuming 4/4 time). Not sure if there’s a better way to label it.
I was wondering why you’ve added modulation inputs on many of the parameters controlled by knobs. Since you can modulate the knob directly, what advantage is there to having a separate input? I could see some use if modulation signals were bi-polar since the knob would serve to set a level around which the modulation would center, but if we keep modulation signals uni-polar you can only increase the value of the knob. You’re also defeating the purpose of the clamped knob which automatically serves to clamp the input between 0 and 1.


Actually, the way that Audulus processes stuff, unused oscillator nodes sit idle because they have no output, and unless Audulus finds a meter or audio output, everything upstream from it is not processed. That’s the primary reason I got rid of any lights that were causing CPU% to run up.

I can definitely expand the labeling - I thought it was obvious, but then again, I thought the icons were obvious too lol, good to have the feedback.

We’re getting rid of modulating knobs in Audulus 4 in favor of inputs with built-in attenuators/attenuverters. I’ll send you a picture on the Slack of it. It’s a step in that direction. I know some people might be upset since modulating knobs directly is a cool feature, but it causes some complications in the code when you want to put modules inside of modules.

Since we’ll have normalized inputs for Audulus 4, too, we’ll be able to determine how the knob interacts with the incoming signal - you could have it act as an attenuator, or as an offset.

For right now, they just act like more inputs for more modulation.


OK. That’s quite a big change! I think it can be OK but often one can save on an extra input in the UI by being able to modulate a knob directly.


Yeah it’s a trade off for sure - but there’s a new feature coming to iOS that will make saving UI space less of a necessary thing. Can’t say what it is at the moment, but people will definitely like it when it comes around! :slight_smile:


Here are the guidelines for I/O labeling I’ve been working with:

  • Mod = 0-1 modulation
  • Env = 0-1 modulation, but expects an envelope
  • Aud or Audio = -1 to 1 audio
  • Gate = 0 or 1 gate
  • Left/Right or L/R = Left/right audio
  • In/Out = modulation or audio input (for example, the Digital VCA has In/Out implying it can be used for audio)
  • CV = Modulation or envelope or audio - whatever you want.

If you have an input that is tied to a knob, label it with the knob’s label + type of modulation, like Hz Mod on the VCF, as opposed to Hz, which would imply the input takes a Hz value.

Light nodes go on Gate I/Os, Red RGB nodes go on modulation outputs. Don’t use audio lights anymore as they will add to CPU of multi-oscillator outputs, like the Basic VCO.


OK! Very curious about the UI thing.
Looking forward to normalization as a possibility. :+1:


Really Humungous Reverb Demo.audulus (550.5 KB)

Expanded the size, added clamped knobs, and added a size modulation section.


Here’s my variable curve ADSR and FSK VCO refaced.
33%20PM 02%20PM
I can’t say I’m very happy about losing the ability to modulate knobs directly. I think it’s going to make the UI very busy. I think in practice you will either have to be selective about which knobs also have modulation inputs or resign yourself to having a large patch bay for each module. Currently we have an input that’s normalized to a knob and takes up no space in the UI. If you have to add a separate input and label you’re adding quite a bit of bloat. For the Variable Curve ADSR I added a modulation input for each knob just to see how it worked, for the FSK VCO I did not, but potentially sacrificed the ability to modulate any of the parameters controlled by the knobs.
For comparison I added the original VC ADSR:
Reface VC ADSR and FSK VCO.audulus (160.7 KB)


Being able to modulate any knob on an interface is one of my favorite features in Audulus and I would be sad to see it go as well. :cry:


What this makes way for is to be able to insert a module into another module, expose that whole module to the UI of a patch, and be able to construct new modules even faster. So instead of having to hook up new knobs to old knobs to bring those controls to the foreground, the knobs inside will just translate upwards. It will make making big modules even easier.


That would be pretty neat. I think I would be willing to sacrifice modulating knobs for the ability to expose the UI of a sub-module intact.


Yeah and you’d also be able to move the UI around as a unit instead of moving each individual thing at a time.


Check out the clock divider module in here - tweaked @robertsyrett’s requested clock divider that counts up on the display - added a reset and a variable PWM output as well.

Audulus 3 Reface (300.8 KB)


I like that you can also use it as an asymmetric slew, although it could use a few tweaks if it were to be used like that intentionally. I also like the curve of the decay, which is pretty much exactly like the AJH Synth dual contour module in eurorack.

I think of the built in octave shifts as more of a timbral control, like oscillators in a minimoog, and the stand alone unit more as a generative device melody routing. Perhaps there could be a toggle on the 1/oct attenuate/offset that quantizes to octaves? One of the fun things about making the modules taller is that it makes a little more sense to include more functionality that might not be used in a given patch, provided it doesn’t eat up CPU (which this won’t).

I did, but it still has some bugs that I haven’t sorted yet. The old-school clock divider comes in really handy when processing gate sequences though, since it is basically a counter, which is a different use case than the master clock. Perhaps I could put a reset in the one I have along with the count visualization to make the purpose clear.

I believe the idea is that the skeuomorphic designs will be more familiar to hardware modular users, but it has the added benefit of being able to mix to modulation sources.

If @biminiroad includes the audio attenuverter, users could use that to create negative values that offset knob placement. We can also spread the word about the expression node so people know they can just double tap an input and use -x for inverting the polarity.

Yeah, I came to the same conclusion, but I still like some lights on my modules :vertical_traffic_light::traffic_light::vertical_traffic_light::traffic_light:

:fearful: I am one of those people who is upset by that. Sticking a wire on a knob is really fun and it simplifies the construction of modules. I get how it caused bugs though. I think I ran into a few crashes on account of accidentally grouping things when wires were connected to knobs. RIP beautiful labeled knobs that you could directly modulate.

This is true in VCV rack and hardware modular, and the results are not catastrophic. Also, I think if there is a parameter you want to modulate, that is not available by default, we can still go in and make one in less than a minute for the purpose of our patch. I will miss directly modulating knobs though. There was a lot of fun in being able to experiment with modulating parameters that normally wouldn’t be modulated.

Well I suppose that does soften the blow somewhat, although the issue for me was not being able to group select in the UI editing process and having a bunch of unlabeled knobs appear stacked on top of each other.

Nice, it’s got a built-in gate smear!


Check this bad boy out - much better basic 8 Step Sequencer. Need to incorporate @stschoen’s pingpong clock but it has a problem with the reset that I think we can fix. Will also probably add a random algo too.

8 Step Sequencer Demo.audulus (58.6 KB)

Audulus 3 Reface (319.0 KB)


I like the new sequencer. I assume it’s a work in progress still as it could benefit from some indicator of that the modes do, but it’s like a little mini Rene in how it can shift the direction it reads the knobs. I’m not sure if it would turn into exponential spaghetti, but a 16 step version would be pretty amazing.

However it does make me revisit the design choice to no longer being able to directly modulate knobs. To make the most of such a sequencer You almost definitely want to sequence the algorithm. I think losing the knob as input/level display sacrifices one of the best aspects of using Audulus for what could be one of the best improvements to building in Audulus. So I really wonder, is any room for compromise?

Can we keep knob modulation at the top level of abstraction? Maybe a little dialog box that pops up if you try to group or expose knobs that have modulations attached saying that Audulus is disconnecting those wires with a cancel option?