Three cool new small features coming to Audulus
  • I just got off the phone with Taylor from our weekly meeting - we had some good ideas, one that's for Audulus 4 and two that are for Audulus 3.

    The Audulus 4 feature is that we get rid of the Min-Max function on the knob node so that the knob only outputs 0 to 1 signals. It will be up to the user to translate the output of the knob to the range they want it in, using either expression nodes or one of the knob translate modules you can find in the new module library. This obviates the need to explain to people the rationale behind keeping the knobs 0 to 1, leading to the heartache of a new user making something huge and really awesome, then sharing it, only to realize they need to go back and change all the knobs (which are often not via tabbed, and so difficult to trace down). Audulus 3 patches will be grandfathered in, but you'll no longer have the UI in 4 to be able to change the ranges.

    For 3, we're also going to implement URL help embedding in modules, so that when you go to help on a module, it goes to the actual module's section of the documentation, and not the patch node like it currently does. There won't be a UI for this - you'll have to do it in the code of your patch itself - but this way, more ambitious users could edit their code on a computer to include links to forum posts about the patch.

    We're also going to rearrange the right click menu on computer so that the library appears on top rather than on the bottom of the menu, to drive users towards using those modules, and make it easier to just click and move sideways to the library when building patches, rather than hunting towards the bottom.

    What do you think?

    PS: I'll get back to other people on the forum this week! Thanks for all your input :)
  • I think restricting the knob’s range is a good idea. I would like to suggest that you also clamp the range of any modulation signal attached to the knob at 0-1. Currently you can modulate a knob past it’s configured range. As an old rocker, I like the idea of being able to “turn it up to 11” but it makes coding easier if you know the potential range of an input. For instances where you need a wider signal range you can always use an input instead of a knob.
  • +1 clamp that knob! overflow is bad.
    maxresdefault.jpg
    1280 x 720 - 84K
  • I can see the sense in restricting the range of the knobs from 0–1 so that ‘everything can modulate everything’ and how that can also help keep users from shooting themselves in the foot (which also reminds me a little of general macOS vs. iOS discussions), and also how the clamped knob is a handy thing to have.

    One aspect that I think I'm going to miss though (since it seems as if this ship has pretty much sailed) is the ability to sometimes enter a specific value for a knob. For example, when I was working on my scale detuners I liked that I could manually set values for a knob specifically calibrated in cents: +4 or -8 cents for example. That could of course still be done with a little mental conversion (which in the case of cents is simple enough) but it was nice to be able to easily enter a value, especially when in the process of building things. Sometimes there are knobs that aren't meant to be modulated.
  • What? It won't be possible to enter a specific value anymore?
  • @Sansnom @ RudigerMeyer - you will be able to enter a specific value, just not one outside of the 0 to 1 range. If doing this is important while you’re building I would suggest using a via tab before your knobs so you can disconnect them and connect an expression node with the precise value you want (or just do the mental math like Rudiger is saying) before reconnecting knobs.

    Or you can use an integer maker and then it’s pretty easy to dial in +8 or -4 cents. You’d just create the integer then convert that to cents. You could even scale the knob with say a mapper node or some expression so you can easily dial in low values while higher cent values go by more quickly.
  • OK. I personally don't like that change much. The good old flexibility of the knob will be missed. It will be more complex to do the same thing than before.
  • You haven't mentioned whether the constant node would also be restricted. In most cases I prefer the expression node since it's obvious what the current value is, however the constant node does make a nice trimmer and would certainly serve to allow you to enter values while constructing a patch. I often use a constant node with an attached value meter to fine tune a patch and then replace it with an expression when I'm happy with the result.
  • @sansnom @stschoen - all you need to do to range the knob is use the knob range module (available in coming update) to do the same function. We’re getting rid of “hidden features” and things like knobs on modules (like the delay node) to make the nodes more primitive and explicit.

    It stinks but some features exclude others - we understand why some users might like to be able to enter values onto a knob, but the interconnectivity provided by keeping all knobs 0-1 outweighs that convenience, because it means all modules that anyone makes now will be automatically compatible. A new user might be confused why all library modules respond to 0-1 modulation, but something they download from the forum wouldn’t be.

    It also is a little against the metaphor of a knob to be able to turn it down or above more than its minimum or maximum value (as it works right now).

    I guess it’s worth asking too @sansnom - what do you use min/max and enter direct values for? I haven’t used them myself in years. Is it just while you’re building? What about connecting an expression node with an exact value is more inconvenient than doing it directly on the knob? Asking not rhetorically but because maybe there’s something I haven’t thought of that could be a good case for keeping it the way it is, or for designing something that would take the place of the function you like it for.
  • A little bit like stschoen it happens mostly while debugging or tweaking a patch. Sometimes I like the idea of letting the user go beyond 1, i.e. beyond the normal value. This is the case for the depth knob of my ensemble effect. In that case I feel it makes sense (double the normal value, or half the normal value). Setting back the knob to a given precise value happens a lot though, so this would be a big loss if removed, I'm surprised you never do that.

    One thing I have to say, as a long time user. Since you're arrival you're focused on building standards. Modules, i.e. patches that conform to these standards, are at the forefront. Everything is pushed toward the use or the production of modules. But there was a time where creation in Audulus was free of standards, without modules. I totally understand your view but there are some users, like me (what about the other long time users we don't see anymore on this forum?) who almost never use and have no interest in modules. I'm sorry to say that because I know how much love and work you've put into this framework, but that's the reality.

    I 've been using knobs with crossfaders a lot lately to conform to the standard though, so I should be ready hopefully ;)
  • Actually I've realized it's a bit worse than that. When using knobs to dial timings like in my ADSR it's very handy to enter the max or desired value directly on the knob (just like in the original ADSR node)
  • @SansNom - I see what you mean - and you're of course still welcome to build things to your own standards! The only problem is that if you want to share them with other people and have them get some use out of it, they'll either be limited in how they use them (won't modulate knobs), adapt them in their own use to fit the library (adapt the knobs to the module library standard), or try to use it, see it's not behaving normally, and give up trying to use it.

    However, it's not like standard signals don't exist without modules. Nodes use Hz, gates, amplitude values, etc. You can't plug a negative number into an envelope's time value, because negative time doesn't exist. As you noted, the crossfader naturally goes from A to B with 0 to 1. The audio output is capped at -1 to 1, so it doesn't make a lot of sense to create an oscillator that goes between -1,000,000 and 1,000,000 (plus, it complicates the kind of waveshaping you can do when you have an oscillator that exceeds -1 to 1).

    So the standards that are set are there not to really constrain people, but to give the freedom to do things that would be hard or impossible to do without them - namely, collaboration. They're also very much a natural outgrowth of what what's already there.

    If you want to share your creations with others (and learn from others creations) it's hard to do that if the first ten or twenty minutes is spent getting an understanding of how the knobs are ranged and what exactly the signal standards being used are doing and why - especially if there's no included documentation.

    And in a more broad stroke, for the general overall long term viability of Audulus, we need to have an ecosystem that is welcoming to beginners without simultaneously dumbing-down or sacrificing functionality. The module library is not quite skeuomorphic, but it's much more familiar to modular users than nodes are. Furthermore, it allows you to interface with hardware with ease.

    Taking the min-max off the knob and clamping it between 0 and 1 (and also removing the ability to name the knob, which you can do with text node) is at once both more beginner-friendly and advanced user-friendly (how many combined hours have I and other users spent just deleting the name of the knob node because we put the name on the inside, or don't use one?). Also, if you wanted to apply any sort of curve to the knob, you'd have to keep the knob between 0 and 1 anyway because the curve needs to be applied first before ranging it.

    You've also created some of the better filter modules available in the library, for which I know everyone's grateful - but you surely don't build a filter every time you sit down to make music with Audulus?

    Anyway, long response, but just hoping you'll come around to seeing it the same way, or the new change won't put you off of using Audulus, because like I said, you've done some of the best work of anyone on the forum here! :)
  • I'm fine with with restricting the knob from 0 to 1 and scaling it. Having some built in range checking is always useful. As an alternative approach you could keep the min/max/value submenu but restrict modulation of the knob to 0-1 where 0 would be fully off and 1 fully on. This would allow the knob to represent whatever the designer wished internally but would only allow an external input to "turn" the knob from off to on rather than override the minimum and maximum values configured on the knob. I'm not so sure that removing the name field would be an improvement. I typically name the knobs during development so that when I expose multiple knobs I can easily identify them. Because all the knobs are exposed immediately when grouping a set of nodes, you would have no easy way of identifying the knob. Once the design is complete I typically relabel them, either with a graphic or text inside the knob. I think any time I might save not deleting the name would be lost if I have to manually identify each knob. Why not simply remove the "knob" name from the prototype knob, but leave the ability to rename it. That way you can leave the names off or on as you choose. What are your plans for the constant node? If the expression node is optimized, there wouldn't be any reason to use it from a performance perspective, but as a "trimmer" I still think it would be useful. I think you could make an argument that it should still allow the min/max/value sub-menu since it is not something that can be modulated.

    In general, I'm of the belief that simpler is better. Making the knob a straight 0-1 control fits well with this approach. I like the ability to directly modulate the knob since it saves on screen space and provides some of the functions of a "normalized" input at least for static values, but I was never too happy with ability to modulate the knob past it's configured range. I would also be fine with removing the knobs from some of the fundamental nodes and providing modules instead. I would love to have a delay node that is just a delay without the feedback or mix. You could provide a module with those features but often what I really need is just a straight delay. There are obviously some nodes that are redundant, particularly if and when the expression node is optimized. Having an add and multiply node, but no subtract, divide or negation makes no sense to me.

    As far as the module library is concerned, I see great value in having a broad selection of pre-built components available. No only does it allow beginners to quickly produce some sounds, it provides an excellent way to learn the fundamentals of modular synthesis. While I prefer to use nodes when designing a new element, I also appreciate being able to quickly grab an LFO, envelope generator, mixer etc. when constructing a patch. I think the trend toward simpler, single purpose modules combines the best of both worlds. I certainly think there is room for both approaches in Audulus.
  • @stschoen

    "As an alternative approach you could keep the min/max/value submenu but restrict modulation of the knob to 0-1 where 0 would be fully off and 1 fully on. This would allow the knob to represent whatever the designer wished internally but would only allow an external input to "turn" the knob from off to on rather than override the minimum and maximum values configured on the knob."

    The problem here is that the knob range is a mystery unless you inspect it. You also cannot apply curves unless we built a separate curve menu in the knob node, which is not something that Taylor wants to do, and was in fact the impetus behind the decision to take away min-max.

    "I'm not so sure that removing the name field would be an improvement. I typically name the knobs during development so that when I expose multiple knobs I can easily identify them. Because all the knobs are exposed immediately when grouping a set of nodes, you would have no easy way of identifying the knob."

    The answer to this is to include in the building section pre-arranged knobs that can be cut and pasted into a module. The other method is to turn the knobs so that you can tell which are which (which is what I do). So if you have 4 knobs, you turn one all the way down, one all the way up, and the other two slightly to the left and slightly to the right. Then you can identify them when you come up to the subpatch level and match them with the text node/SVG icon.

    "Why not simply remove the "knob" name from the prototype knob, but leave the ability to rename it."

    It goes along with Taylor's push to make all of the nodes more explicit and not have hidden menus - same idea with min-max. One idea that just popped into my head would be to have an in-app splitscreen mode where you can see both inside and outside a module at the same time. This way you could tap on a knob and it would be highlighted on the panel. Dunno how feasible this is, but do y'all think it's a nice idea?

    "What are your plans for the constant node? If the expression node is optimized, there wouldn't be any reason to use it from a performance perspective, but as a "trimmer" I still think it would be useful. I think you could make an argument that it should still allow the min/max/value sub-menu since it is not something that can be modulated."

    I think this might be a good idea, and a good compromise - I never use the constant node myself, but I can understand why people would. @sansnom - what do you think about that?

    "I would also be fine with removing the knobs from some of the fundamental nodes and providing modules instead. I would love to have a delay node that is just a delay without the feedback or mix. You could provide a module with those features but often what I really need is just a straight delay."

    Exactly! That's the direction we'd be going in.

    "There are obviously some nodes that are redundant, particularly if and when the expression node is optimized. Having an add and multiply node, but no subtract, divide or negation makes no sense to me."

    Yeah, the expression node will be optimized, and perhaps you can just go ahead and build with the expression node knowing that in the future it will be. I like the simplicity of + and * since they're used much more often than subtract and divide, but point taken.

    "As far as the module library is concerned, I see great value in having a broad selection of pre-built components available. No only does it allow beginners to quickly produce some sounds, it provides an excellent way to learn the fundamentals of modular synthesis. While I prefer to use nodes when designing a new element, I also appreciate being able to quickly grab an LFO, envelope generator, mixer etc. when constructing a patch. I think the trend toward simpler, single purpose modules combines the best of both worlds. I certainly think there is room for both approaches in Audulus."

    Definitely! I see the modules as avenues to explore as well to creating your own modules. What we want to prevent though is beginners just using nodes and not really realizing what modules are for, and why they're generally more powerful and sound better. A lot of the reviews and feedback Audulus gets about sounding "thin" or "digital" is from people using just one oscillator through a filter node, not understanding that Audulus nodes are more low-level than another synth's oscillator and filter combination.

    PS: Our forum badly needs a quoting ability.
  • I'm familiar with the "turn the knobs to identify them" approach having used it many times myself. In fact that's why I started naming them so I wouldn't have to. Not a big deal but still I think having a name for the knob has some merit. If the expression node is useable with no penalty then having just an add and multiply node is fine. Kind of like the level node. It's really just a multiply in different skin but it does serve to more clearly identify which input is the signal you are altering.

    I would agree about the need to prioritize the modules vs. the nodes. I think the new iOS create menu does this pretty well. Moving the example patches from the create menu to the new document menu, making modules the default, and the new, more accessible documentation should go a long way toward improving the initial user experience.
  • BTW I'm fine with a simple 0-1 knob, I was only suggesting the other approach as a possible alternative.
  • @biminiroad- "If you want to share your creations with others (and learn from others creations) it's hard to do that if the first ten or twenty minutes is spent getting an understanding of how the knobs are ranged and what exactly the signal standards being used are doing and why - especially if there's no included documentation."

    At the same time, modules are given an official support and online documentation, while regular patches lost their metadata with v. 3.5. Obviously the gap gets deeper. Now there are more explanations on the module versions of my filters than the originals. I can't update because I have to rework all my patches by copy/pasting the metadata inside the patch, which I find awkward.

    As for the constant node getting all the flexibility needed for debugging and tweaking, why not.

    On the debate modules/nodes, the problem comes from our interpretation of what Audulus is. For you it's mainly a modular environment ala eurorack, for me it's a graphical programming language designed for audio processing. 99 % of my work is based on nodes.
  • @sansnom

    "At the same time, modules are given an official support and online documentation, while regular patches lost their metadata with v. 3.5."

    The problem with the metadata was that people didn't know it was there and weren't really taking advantage of it. I know it's a loss to have to shift to documenting patches inside them, but it really is better in the long run to move forward doing that. Again, it goes with the philosophy we're trying to cultivate of everything being explicit without a bunch of hidden features.

    Also, although the work isn't complete yet, I did work a lot more on the nodes documentation first before switching to the modules docs. I did that to help the people who were already building to be able to understand the nodes more fully, knowing that they're the real backbone of the program.

    Metadata was sort of a flawed way to comment on patches to begin with because ideally people should do a node-by-node breakdown of what's happening and why - it's much easier then to understand the signal flow, and also pick out individual parts of a module that you might want to reuse in something else.

    We definitely need a better in-app text editor. BTW you *can* paste in text with paragraphs and have the paragraphs preserved - you just can't actually make a paragraph break in the text box - dunno if that helps you at all.

    "On the debate modules/nodes, the problem comes from our interpretation of what Audulus is. For you it's mainly a modular environment ala eurorack, for me it's a graphical programming language designed for audio processing. 99 % of my work is based on nodes."

    I don't think it's an either/or, but there certainly are a lot of modules that help when building with nodes - especially things like the high-low detector, or change detector. Audulus gives you the freedom to work in both paradigms, and foregrounding the modules for the more general public doesn't make the nodes less accessible to users like you, ya know? The idea is to be able to work at all levels of abstraction - from total all-in-one standalone synth down to modules down to nodes.

    Anyway, just want to end by saying we really value your and everyone else's feedback - none of this would have been possible without the great community here! :)
  • Like @SansNom, I view Audulus primarily as a visual programming environment focused on audio processing. I view the module library like I would view a library in any other programming language, as a collection of programs which have already been developed to simplify application development and to assist in dealing with routine programming tasks. I use various libraries extensively when coding in more traditional languages, I see no reason why Audulus should be any different. I would hate to see Audulus lose any of the low-level capabilities it has, and would love to see more, particularly in the areas of MIDI processing and more sophisticated persistent variables (samples etc.), and if making it more accessible for the casual user leads to further development of the core then I'm all for it. I don't think either approach precludes the other.
  • As with @stschoen I’m also in favour of keeping the names on knobs. Although one often ends up adding names with the text node or using SVGs, the default names are a great ‘quick and dirty’ solution when figuring out the UI of a patch and perhaps moving around the location of the knobs a number of times before settling on a layout.

    I’m also worried that while one can achieve any kind of transformation of 0-1 with the expression node, that that’s also going to mean a lot more clutter in patches.

    There are also some situations in which being able to set a range on a knob is really useful when it remains so compact. Want to quickly check out a range of pitch possibilities on a VCO without the complexity of the keyboard node? – a quick -4 to +4 knob as @stscheon has often used in his demos. Simple, (visually) compact, and it gets the job done.
  • @stschoen

    "I would hate to see Audulus lose any of the low-level capabilities it has, and would love to see more, particularly in the areas of MIDI processing and more sophisticated persistent variables (samples etc.), and if making it more accessible for the casual user leads to further development of the core then I'm all for it. I don't think either approach precludes the other."

    Audulus is going to get something like 40 new nodes in Audulus 4! So the low level stuff isn't going away, it's just becoming even more low level, at least in this knob's case. Definitely more MIDI stuff coming too!

    @Rudiger

    "the default names are a great ‘quick and dirty’ solution when figuring out the UI of a patch and perhaps moving around the location of the knobs a number of times before settling on a layout."

    The solution should be a better way to go between UI and inside of patch though - one temp fix is to have banks of ready-to-go knobs that are pre-arranged that you can cut and paste into your module. The other is my new pet idea of having a splitscreen within Audulus where you can look at two different parts of your patch at once (like inside a module and outside of it) so you can then tap on a knob on the inside of a patch and it will highlight on the outside.

    We're also going to have group UI element movement in Audulus 4 which will make things a lot easier.

    "Want to quickly check out a range of pitch possibilities on a VCO without the complexity of the keyboard node? – a quick -4 to +4 knob as @stscheon has often used in his demos. "

    There's a module that outputs -5 to 5 for that! Quicker, simpler, more explicit, and looks nicer than just a knob. Not included in the module library yet, but will be - @RobertSyrett made it I think.
  • I'm looking forward to all of the improvements to come! The group UI moves will be great. I hope we'll eventually have the ability to expose the UI of a sub-module. That would allow you to construct a sub-module (like a scale and offset for example), complete with knobs, graphics etc. and simply insert it, and expose its UI. Combined with inputs that can be "normalized" it would be a big step toward re-useability.
  • @biminiroad “There’s a module for that.” :-)
  • Screen Shot 2018-03-09 at 2.51.45 PM.png
    982 x 612 - 77K
    freq knob.audulus
    5K
  • @biminiroad I think the idea of being able to see inside a patch and outside for UI design purposes is a good one.

    Having to set knobs and buttons to different settings to be able to determine which control corresponds to the one in your UI is very awkward and time consuming.

    Having template controls you copy into your patches as you’re constructing them seems like a good idea too.

    Another alternative would be to name knobs as you’re creating patches but when they’re saved, Audulus automatically creates a text node and no name knob. Being able to group objects in the sub patch so they move together when you’re trying to design your UI would be another way to deal with this issue. Lock and unlock groups like in vector graphic apps would seem to translate well to Audulus.