@stschoen, good points, I forget that iOS must also be considered! Language perhaps less of an issue. I do like the smaller compact nature of the modules and especially the use of SVG graphics. I’ve not used Audulus for a while and I made my initial post after opening the 3D cube sequencer!
@robertsyrett, my bad about assuming it’s eurorack clones, I thought that’s the direction the library was going in given all the hype in that world! Thanks for the pointers I will focus in on those sections…
This one might be tricky and should certainly be seen as a “nice to have”… You know how when you select a knob to adjust it expands to indicate that it is active? It would be great if any underlying text, label, SVG, RGBLight, etc would remain visible and expand with the knob.
There is a work around, you can cut and paste the element you want to be displayed on top, and it orders the way the visual elements are stacked.
Since the knobs are in some ways optimized for iOS, how are you imagining it being an advantage to seeing what’s under your finger since your finger would be on top of it anyway?
What would what you’re asking for look like? Would everything inside the knob get bigger? How would it know how to do this? Like if you had some text that went outside of the knob’s area, would it only magnify what’s inside there?
But again Im wondering how useful it would be to do this since your finger occludes the inside of the knob while you’re tweaking it on iOS. Know what I mean? Maybe I’m missing something about this.
Yeah, I understand your questions & the challenges. I use the Apple Pencil which significantly reduces finger occlusion (and fingerprints!). And, indeed, this suggested feature is really a “nice to have”.
Perhaps I could be a little more specific.
(1) For the Knob node, keep the label visible when tweaking.
(2) For the Level and Constant nodes, add a label field just like the Knob node which also remains visible when tweaking.
(3) For all three of these nodes, add a “graphic” item centered on the knob that remains visible when tweaking. This “graphic” would be the place that you could pin an SVG (or perhaps a Light or RGBLight node).
I guess the other point is why do you need to see the label of the knob that you’r tweaking while you’re tweaking it? Presumably you already know what knob you’re turning, right?
I see what you mean as a nice-to-have, but I guess I’m asking is it just a cosmetic thing or would this actually be useful in some way that I’m missing?
Yes - definitely cosmetic! I guess I’m just used to other apps whose labels don’t disappear when you are tweaking. 
Yeah but that has to do with how Audulus shows you knob positioning - the knob gets larger so you can see it on the outisde of your finger, whereas on other apps like Korg’s have a little box that comes up that tells you the value of the knob. The reason it darkens on the inside it to provide contrast between the knob itself and things around it (imagine if nothing was occluded - you could probably even see the inside of other close by knobs inside the perimeter of the knob.
It wouldn’t be this way of Audulus wasn’t also on iOS is my guess. That said, I really hate the knobs on hardware emulations where there isn’t some iOS-friendly indicator for their positioning. Like I love Moog’s sound of their apps, but especially on an iPhone the indicator dot is vanishingly small.
Is there a module that mixes down LED values into a single number?
You could use a digital to binary converter to split a digital value into 3. We have 19 bits available so if you use 18 you could get 6 bits per color which would give you 0 - 63 steps for the value for each color. Not accurate enough for fine color, but possibly acceptable for general use
That is perfect!
Just updated with a no display input as well
Looks like I downloaded at just the right moment!
The display model is using the new clamped knob so you can modulate it as well. This is a case where out of range values would definitely cause unexpected results. Inputs on the no display version are clamped at 0-1.
Just noticed something is out of place on the one display. Give me a second and I’ll fix it.
color mux-demux V1.1.audulus (89.6 KB)
I’m a newbie and a lot of the time it still feels like I’m flying blind. What would be very helpful is an audio rate oscilloscope. Additionally, a spectrogram, instant as well as over time, would be nice.
In my other life, I’m a software developer and I tend to think in modules and interfaces. Modules in Audulus are more like macros. They are copied and expanded to each place where they are used. That makes it difficult to update a module everywhere it is used.
The in-place “Help” for modules is not really helpful: It only says that it’s a patch node. I’d rather see a help message for the specific module.
There is already an item for AUv3 on the Megapoll, but I think it might apply to macOS only. If it applies to iOS as well, please clarify. If not, please add iOS AUv3.
Both are coming in Audulus 4 
Tell me about it! Haha I still want to go through all of the modules and add node-by-node explanations of what’s going on and I have to do this all manually. Not sure what can be done to streamline “updating” a module after it’s been implemented in a patch without risking breaking the patch. Open to ideas though!
That is something I’m working on right now - if you see the Weekly Update I posted, what I’m doing is adding a ToC to the modules documentation which will help in the future for adding the help function that points directly to the module’s docs rather than the Subpatch node. However, you can actually enter the module and get an overview of what it does inside. It’s everything that’s there in the documentation minus the new tables I’m adding.
AUv3 is coming to iOS before it comes to Mac actually
If I get this right, modules don’t really exist, they are just files containing subpatch nodes. When I insert a module, what I really get is that the subpatches from the module file are inserted.
Of the cuff, I think patches need an identity (uuid) in order to identify the original patch as well as its descendants. What makes matters more complicated is that patches can be modified in all the places they are used. There is no obvious latest version and you probably don’t want to go into git-like version control. So maybe a timestamp must do to identify a version, without any notion of lineage.
Given these two bits of metadata for a patch, it would be possible to replace a specific version of a patch in a selection of files. It would also be possible to do this for all older versions or all versions.
For a patch that has become incompatible with its forebears, it might be necessary to detach it from its lineage (fresh uuid).
Yes modules are just patch files. The problem I see with updating something is like sometimes to create a new module, I use existing modules and edit them. OR I use a module inside another module.
I guess what I’m saying is it’s a tough thing to figure out and I’m not sure what benefit it has for users? How would it replace a module with a new module but then retain the same knob/button combos?
It would make my life easier when I’m updating the library and change something like a building block and have that propogate out to everything that uses that building block, but at the same time, it seems like it could both cause some big problems and would take a while to code up (thus taking time away from other features).
I’m not poo-pooing the idea at all it would be awesome to do this I’m just not sure if it’s possible 
Oh and basically modules are little JSON packets so they do exist “by themselves” in a way, but all modules are created within Audulus and thus have to exist inside a patch file (i.e, there is no separate “module” file).