Sorry, that’s a deal breaker. Labels need to be on knobs. The reason for labeling knobs is to label the knobs. If you think the label should be on rather than below the knob, ok. But knobs need labels associated with the node.
1 Like
“Please keep labeling for sure then.”
“We’re definitely getting rid of labeling…”
The knobs would still he labeled, just by the Text node or SVGs. If knobs must have labels then why don’t buttons need them too?
I do believe we have had this conversation before. I do think you should be able to label buttons, and directly modulate them with cords. The only thing that makes them remotely tolerable is that you can expose them one at a time and so, placing them meticulously, work around this short coming. But it is a short coming.
Placing SVG and text nodes where labels used to be is a perc. It allows for greater freedom when finalizing a design and sharing it with others so it looks nice. But labeling knobs is critical to debugging and developing complex patches without adding another layer of visual elements you have to individually move.
An alternative might be grouping UI elements together. If a text node and knob are grouped such that when one is selected the other is as well, like adobe products, I could see maybe doing without the label in the menu but I strongly encourage you to not do away with the current knob before Audulus 4.
2 Likes
We’re not going to do away with labels until there is a better alternative to labeling. Were you thinking I was suggesting otherwise?
Sounded pretty imminent, I was like 
1 Like
I tend to agree with @RobertSyrett. Although I almost always remove the labels on knobs, inputs and outputs when finalizing a design, they make it much easier during the design process. I do however, enthusiastically support clamping the knob, particularly with respect to modulation. The added convienence of changing the scale is outweighed by the potential for error since it is not obvious what setting a particular knob may have. I also think that being able to modulate a knob past its limits is a potential source off error. If you could control whether a knob was exposed you could exposed them one at a time. I like the split screen idea as a possible approach, but it could have issues on devices with limited screen space.
3 Likes
It’s not - it’s just I’ve stopped using the other knob so I don’t have to go back and replace them later. If you don’t want to use it yet you def don’t have to! 
2 Likes
I really didn’t quite understand the knob clamping. Here’s what I think I understood:
Some modulation sources produce and output wherein the range is outside the scale of its proposed carrier (target knob). Clamping somehow forces the source into the correct range appropriate for modulation. While you can pretty much modulate anything with anything, in specific cases you will need to add a node/function in order to translate the information into straightforwardly compatible values.
How does one know when to clamp? You mentioned that the clamp knob is not yet available in iOS, so I assume the example you provided in my patch is a workaround for iOS based sound design?
1 Like
So modulation and gate signals are the only signals that you should attach to knobs without clamping. Clamping keeps the incoming values between a given range - in this case, 0 to 1, which is the default range for knobs.
If you stick an alternating -1 to 1 signal onto a knob, you can end up making the module do some wacky unintended stuff. It doesn’t happen for all controls, but it can cause a patch to break especially when adjusting Q on the built-in LPF.
The clamped knob will let everyone just attach whatever to whatever without needing to worry about stuff breaking.
We’ll also be getting rid of min-max function because it interferes with this nice neat interchangeability.
2 Likes
There is a clamp() function available using the expression node which gives you the ability to clamp any value. It’s clamp(x,min,max) where x is the value to be clamped and min and max are the minimum and maximum values. The clamped knob is restricted to 0 - 1 so it essentially has a built in clamp(x,0,1) function. The clamped knob is not yet on the node menu for iOS, but it works on iOS now
2 Likes
Blockquote So modulation and gate signals are the only signals that you should attach to knobs without clamping.
This is a bit foggy for me. What constititues a “modulation signal”? LFO vs. VCO? Sample and holds? What is not a modulation signal?
Blockquote There is a clamp() function available using the expression node which gives you the ability to clamp any value. It’s
clamp(x,min,max)where x is the value to be clamped and min and max are the minimum and maximum values. The clamped knob is restricted to 0 - 1 so it essentially has a built inclamp(x,0,1)function. The clamped knob is not yet on the node menu for iOS, but it works on iOS now
It seems like, keeping the end-user in mind, there ought to be a real graphically standout clamp node/module that is coloured different than everything else, or some way in which when you go to wire something unclamped, the wires or knobs or something go grey.
I remember that one of the big innovations that made Reaktor Blocks so user friendly was that you would wire anything to anything. But not al knobs are directly patchable, the patch point has to be “exposed” so that the designer can decide which knobs are suitable for modulation.
Even if a pop-up window thats said “clamp?” came up when an incompatibility was detected would help – that is, if anything I am saying makes sense…
I suppose for now if I am unsure I can put a value node on a signal and see whether it is with 0 -1 ?
https://github.com/audulus/docs/blob/master/modules.md
If you look at the Module Signal Standards here, it explains what the 4 major signals in the Audulus module library are.
Basically modulation and gate signals range between 0 and 1 which interface with knobs nicely.
Audio ranges between -1 and 1, which doesn’t interface nicely with knobs.
Right now, when you attach an audio signal to a knob node, it will actually modulate down to -1, even though it won’t animate it with the blue level indicator.
Going negative on some controls is bad, so the new standard will eventually be a knob that will only get modulated between 0 and 1. If the modulation input to the knob is greater than 1, the knob will stay at 1. If it is less than 0, it will stay at zero. That’s the clamped knob.
Sample and Hold is a modulation-generating signal (hence it being categorized under “Modulation”).
Here’s a comparison of the old and new knobs. They are both being fed a -2 to 2 signal. The old knob outputs the signal unchanged. but the new knob keeps it between 0 and 1. If the knob were controlling something that didn’t work at -2 you would have a problem.
knob test.audulus (9.3 KB)
There’s a tradeoff between flexibility and standardization. Audulus allows you to connect anything to anything which makes it very flexible, however it also makes sharing patches a bit of a challenge. Without some kind of standard you would have to research every module to determine the appropriate range for each input, output, and knob. In order to make sharing easier we strongly recommend that “modulation” signals stay within the range 0-1 and “audio” signals stay within -1 to 1. Audulus itself does not distinguish between signal types, Everything internally is just a 32 bit floating point number. You are free to do whatever you like like with a signal, but if you are using other’s modules you may get unexpected results. A good example is the ADSR node. If you modulate the knobs with negative values it gets a bit weird. The advantage of the clamped knob from a designer’s perspective is you don’t have to worry that the signal will go out of range
2 Likes
We may change this in a future version making a gate signal that is only 0 or 1. This would free up a ton of headroom in some digital-heavy patches.
2 Likes
I’ve given some thought to the value of different variable types in Audulus. Memory is not much of an issue these days so speed would be the only potential advantage. I would love to have an integer type where you wouldn’t have possible rounding errors and a true boolean would be good as well, especially if we had a full complement of logical functions. On the other hand it introduces some conversion questions and variable type mismatch issues, so I’m not sure if it would be worth the added complexity.
1 Like
It would be a MASSIVE improvement in speed. Right now everything is sampled at audio rate, including gates. Instead of doing that, it would only be sampled when a change (0 to 1 or 1 to 0) is made.
We’re still discussing how to implement it, and want to keep interchangability as much as possible (and still might!) but the CPU savings on especially large patches with lots of logic is huge.
2 Likes
Does this effect the “720 degree phase input (-1 to 1)” of @robertsyrett’s Oscimillator synth voice?
I can see the advantage of lower sample rates for non audio signals, but I’m not sure what you mean. Wouldn’t you have to sample the gate to see if it had changed? The problem I see with variable sample rates is deciding what is and isn’t audio. Things like lights, meters etc. could obviously be updated less frequently, but for example how about a knob? You could definately have a knob that is being modulated at audio rates and if you were sampling it at low frequencies it certainly wouldn’t work properly. What if your gate signal is at 1 kHz?