Normalled connections in Audulus

Hi there. is it possible to make “normalled connections” in Audulus and if so, how? Forgive me if I’m using the terminology incorrectly, what I mean by this is having one input connected to a node by default, but then using a different input if that input has a cable connected.

One example of this in the hardware world is in the Moog Subharmonicon where in a certain mode, the Sub1 osc is routed to Osc1 for PWM, but if you connect something to the Osc1 PWM input on the patch bay, it uses that input instead for PWM, overriding the hardwired connection from Sub1. Is there a way to do that kind of thing in Audulus?


Welcome back! Unfortunately there is no way currently to determine if a node has a cable connected, so a “normalled” connection isn’t possible. We’re hoping that this will become available at some point in version 4.

You could use a trigger node (in toggle mode) and a crossfade node to switch between a default signal source and an input.
like this.audulus (1.6 KB)
This isn‘t as elegant as a ‘normaled connection’ but it does the job :slight_smile:

The convention in use looks like this, if I’m not mistaken:

Just a int/ext below the toggle.

1 Like

Thanks @stschoen its been a while. I’m just coming back to playing with Audulus :slight_smile: so much cool stuff has been made since I was last here!

Thanks all, I thought that might be the solution.

@futureaztec (slightly unrelated) I didn’t realise you could expose the Osc wave shape button. That looks so good!


@futureaztec since you mentioned “convention”, is there a thread or any docs on what the main conventions in developing audulous patches are? It would be great for me to catch up on best practice. I did a bit of a search but didn’t find anything.

I like your avatar. I wish I had one of those!

I am not a builder but maybe I can make some gestures and other people might correct or supplement these…

My foggy understanding of the module conventions has to do with when the collection of Audulus modules had to be moved from the old forum to this new one. In order to creative that archive, much work was done assembling a file.

If you look through the modules you can see that certain ones went through several iterations. It seems like one of the first efforts to redesign layouts across different builders was the “uModules.” While builders themselves have their own conventions (like eurorack builders), the uModules made it simpler to organize larger patches and lower CPU consumption.

I would say that the next major phase of this type was @biminiroad’s work on the Reface Library. To be honest, I gathered that there was some hesitation to wholeheartedly adopt all of the reface conventions for every builder, but even the most unique designers seemed to have incorporated at least some.

The Reface Library thread is very long and @biminiroad did a lot of work. I think this was the final version:

What the Reface Library did do was to bring multiple features, that would normally require multiple modules, into single objects. For example, this filter has “drive” built in.

However, many modules have undergone further improvements which are supposed to be documented in the modules section on the forum. That being said some builders may make key changes to their designs but not actually update their original posts in the category. Take @stschoen’s Simple Looper, for example. He has built a similar looper called the “Clocked Looper” that I am a huge fan of but it is hidden in this thread. Given the fact that just entering all of the details in order to post a module must follow “posting conventions,” it makes sense that a builder would sometimes sidestep all of this extra work.

Obviously many of these modules are rare finds that must be cherished in the sense in which a scholar might value rare ideas found deep in minor works. Regarding the conventions; lastly, there will be quirks with each builder. Finding ways to communicate signal flow, knob naming, etc. is it’s own art. I have found the module documentation extremely useful when exploring someone’s creation. In effect, one is often not only learning how the tool works but also learning how synthesis itself works.

  • I should add that there is some extremely well put together documentation:

I did notice that the link to the signals glossary is broken. That’s too bad. Still, there is some amazing stuff in the module documentation book that might be worth brewing up some coffee :coffee: and exploring!


We used to have one but it seems to have been misplaced. At least I couldn’t find it. Probably when we changed to our current Forum platform.

Probably the most important conventions have to do with signal ranges. Numerical values in Audulus are all represented by 32 bit floating point numbers. Without some accepted “rules of the road”, numbers can take on a very wide range of values so we have accepted a few guidelines.

The fundamental nodes in Audulus use raw frequencies for the most part but we’ve found that a scale similar to the 1 volt per octave used in Eurorack to be the most useful. The scale is 1 per octave with A-440 as the zero reference. This normally indicated by the letter “o”. Most frequency inputs on VCO’s etc. use this standard.

The other generally accepted convention is the allowable range for modulation inputs. The community has elected to restrict modulation values to the range 0 to 1. With 32 bit floating point values this gives sufficient precision to avoid any “stair-stepping” and makes it considerably easier to connect modules contributed by different users. To facilitate this, the current knob node is internally clamped to this range. Modulation inputs are generally labeled with an “m”.

The community has experimented with different approaches to module layout. Many of the modules in the module section of the forum were designed when the current idiom was the uModule approach, where the modules were made as small as practical by using SVG graphical labels and connections were typically at the upper edge. Eventually it was felt that this led to considerable confusion on the part of new users so @biminiroad undertook a re-skin of the library to make the modules more user-friendly. This is the Library Reface file linked above. Audulus version 4 is currently in development with some fairly major changes to the UI so the next release of the library willl undoubtedly look somewhat different. I expect that the 1/octave and 0-1 modulation conventions will remain.

1 Like

Haha thanks! I created it ages ago back when RPG Maker 2000 was still a thing :laughing: . If you look for 8bit sprite sheets or a sprite character creator you might be able to find something you like!

Thank you both @futureaztec @stschoen. That’s an invaluable collection of info. I’m really looking forward to getting back into it.

Hey @zilch42 I noticed you were looking for some examples of the conventions, and I didn’t see it mentioned, but perhaps I missed it. Control Abbreviation Glossary.audulus (49.6 KB) and Input Output Glossary.audulus (47.0 KB) I think are the items you seek.

They can be found within Audulus by following the path as follows within the app:
New (or Create Document in Files browser of iOS) > Tutorials > Reference and you will see both of the files I attached in this post.

They are placed really well for a newbie coming in scared and wondering how to make the nodes turn into something that makes cool sounds and reading every part of the included patches, but not so intuitively placed for someone who has already been building in the app for a while, as you kinda tend to forget those examples exist once you have figured out your workflow. Any questions, like what you posed overhead, usually tend to end up as new sections of the forum, once you have a good idea of how things work :wink:

There are also some other great examples that can be found within this menu if you are looking for some inspiration and can’t find what you might be looking for within the forum. @taylor and @biminiroad did a great job of putting together a nice starter library to give beginners a pretty good idea of how things work in this app. Anything that remains is ready to be filled in by us synth nerds here in the forum. I hope this helps! :smiley:

1 Like

I thought they were there somewhere!

1 Like

@stschoen It was no easy task for me to find them either, because of what I mentioned about the placement for newbies vs. seasoned users, but I managed to get to them after about 20 mins of frustrated browsing lol. I hope that is what @zilch42 is looking for and what @futureaztec was referring to!

1 Like

Thanks @stevo3985. There’s heaps there in the tutorials folder! That’s great

1 Like

@zilch42 I’m so glad that I was able to help! It’s such a great feeling for me, personally, to have been in your shoes, with a lot of similar questions ~2 years back, sometimes feeling discouraged, thinking I was never going to get to a level of understanding like the people around me, and finally getting to a level (don’t get me wrong, I am by no means an expert, but) where I am able to help answer questions, offer tips and insight for problems faced, and being able to pay that kindness and offer assistance that I was shown forward to someone else with a strong interest in the world of modular synthesis is a real honor! Happy patching :smiley:

1 Like

@zilch42 I also have to say, that is a super dope avatar, btw! Where did you get that from? I would love to have a little 8-bit version of me, if that is something commonly available (although since you’ve already done it here, I won’t bite your style and use it for this forum hehe)!

Edit: I think it’s probably obvious to those of you following this thread that I certainly missed the place where this was already addressed above. Apologies for asking the same question again not even a full page scroll downward :man_facepalming: