uModular Collection Beta
  • I was curious about the graphics program, will it still be under Audulus LLC?
  • I see your point. It’s always wise to plan for the future. I prefer them centered from an aesthetic perspective so if there is an eventual fix coming, it makes sense to put them in the middle. I’m hoping that Taylor will make triggers attachable like knobs at some point. Please give Taylor my best wishes for his new project. If it’s half as good as Audulus, I’m sure it will be successful.
  • >>make triggers attachable like knobs at some point.

    This is the only non-confusing solution. Make a new node, say the button node, and make it like a knob node. It would always be exposed in a sub patch and you can label it and you can attach wires to it.
  • Love these mini modules! One question - will there be non SVG versions of these modules? As windows user I can't find way to see them.
  • @TDWD - no there won't, but SVGs are coming to Windows, too!

    @stschoen - we have talked about that actually - making triggers attachable. Maybe a suggestion to him as to what that would look like would help inspire him?

    @RobertSyrett - I think the MIDI trigger node should really be called the button node - no need to have 2 of them, we just need to make them attachable. Once that's done, it would be easy to go through and just delete the inputs - moving the is the PITA.
  • New collection adds the LFOs and some other things - up to 233 now! I also adjusted the LFOs so they have more of their range in the slow portion of the sweep - so 0 to 0.5 is 0 to ~1.5Hz
  • @biminiroad, I consolidated the expression nodes driving the shift register LEDs. It should reduce the CPU a bit.
    umod turing modified.audulus
  • @stschoen - nice!

    Here's a uModular revision of your NR transform - hope you like the little tune! Thinking about a nice concise way to indicate maj/min...might just end up putting an extra set of lights at the bottom.
    Neo-Reimann Triad Transform Demo.audulus
    Screen Shot 2017-10-11 at 12.32.51 PM.png
    1600 x 1738 - 892K
  • Ah looks like i pit the transforms in upside down on the panel I’ll fix that pater
  • I noticed you replaced the root note dial with an o input. In the original implementation the maj/min button selects whether the third of the starting triad for the transforms is a major or minor third. The internal registers hold offsets from the original root which is zero (A). The root note knob transposes the starting triad up the scale to match your desired key. While you can certainly change the root note at any time, the original transforms are only cyclical as long as the root note is constant. Just an FYI. BTW I think the patch is great!
  • @stschoen I think there needs to be more education about the intended use for the neo neo-riemannian music. Honestly I had to read the wikipedia article befor I kind of understood it. What I think might be useful in the context of the uModular would be chord generator that would be 3 quantizers set to the same scale that outputs a triad that you can change between major and minor and set inversions.
  • @biminiroad I think if there is room for constant node and knob node, there can be room for buttons and triggers.
  • @RobertSyrett - the Knob and Constant are very different though - one is automatically exposed and the other is unexposable. What would be the point of having two different buttons? I guess what I'm saying is there's a reason for Knob/Constant in a way that there wouldn't be for Button/Trigger. To be clear I'm in favor of adding the wire to button feature, just not sure why it would need to be a separate node.

    As far as the NR stuff goes, I know that the cycling it does is musically "supposed" to be in one mode, but in general, if you clock it like in that demo patch, it changes very dynamically over time and starts to rise as well, until you reset it. I put the quantizers after the transformer too because it made it sound a little more musical to my ears - I'm not huge into experimental scales myself, but of course the option is still there.
  • @biminiroad

    I'd put the reverse to you, why do we need knobs? If we could expose the constant node it would be exactly the situation we have with the trigger. There would technically be no functionality lost since inputs could route signals to the same source as the exposed constant. You could label the constant with a text node and you are good to go. Unexpose the constant for in internal trim pot. You would just lose a bunch of convenience.

    My point is parallel construction of interface is a benefit to the user experience. There are really only two controllers in Audulus, buttons and knobs, and they should be treated with parallel access to cords and the ability to label them. There are greater intellectual challenges to be had in the world of sound design than how do I combine a binary signal input to my button and how do I differentiate all these buttons once I expose them in the UI. That would be the point, to make it less of a hassle.
  • @biminiroad, I had noticed the “climbing “ too. I found the three primary transforms (parallel, relative and leading tone) were pretty stable, but the secondary ones tended to go off the deep end in one direction or the other. I put a reset in my patch that triggered when it got too high or low. Since the transformer only tracks ratios, it shouldn’t matter if you put the quantizer after. Honestly I don’t understand most of it either, it was just something that the O&C module had that sounded neat. I wasn’t trying to be critical, as you point out, you can certainly feed it a fixed pitch if you want, just explaining why I used a knob. I would suggest that the critical difference between a constant and a knob is more to do with MIDI than exposure. Since a knob needs to respond to incoming MIDI messages as well as touch events, it probably needs to be refreshed more frequently than a constant. I would also like to see labels on triggers and have an option for triggers to respond to midi cc messages as well as notes.
  • Knobs should be seen as potentiometers and constant nodes as trim pots. They’re in different form factors to discourage people from thinking constant nodes are primary controls. There is no similar analogy for a button (i mean maybe a modem reset button, but theres no need for anything anyones made in Audulus). It also helps in thinking about what controls are exposed to a panel - I know ipso facto that all the knobs nodes are on the front panel and constants arent. If we had only one node that wouldnt be the case.

    But triggers are meant to be interacted with. If they’re inside the patch they’re either deliberately hidden (respond to MIDI keys without taking up UI space) or exposed onto the panel. Very few if any patches use hidden buttons so in general i can assume when looking in a patch that those are buttons exposed to the UI.

    So my point is there’s nothing that’s gained from having two different button nodes. We just need one button node with more features that we see on the knobs like labeling and direct modulation.

    What you call parallel construction I would call unnecessarily confusing to newbies. I rarely, if ever, use constant nodes myself, and part of me leans towards trying to convince Taylor to get rid of it since the benefits of it are so marginal especially when weighed against the small contribution it makes to people feeling overwhelmed when they first start using Audulus.

    Fact of the matter is anyway Taylor’s not going to add a new node if it doesnt do something very distinct from what’s already there. In some ways I’m in favor of getting rid of the reverb and distortion nodes, along with some others, which are legacies of when there was no patch library and even no subpatches. Thats why the noise node disappeared - the random node + lpf filter node did exactly the same thing, so why replicate its function as a node?

    Anyway I hope you understand I see where you’re coming from and why your reasoning makes sense, I just dont think you’re taking into account some of the important ways that knobs and constants are different from a button/trigger dichotomy you’re suggesting, and the fact that maybe someday we will deprecate the constant node too in favor of fewer more focused nodes.

    And no @stschoen I didnt take it as an insult! Its definitely using it in a different way in this demo but I can see the benefits of just letting it cruise between two on a root.
  • @stschoen - here's one that lets the transforms ride a bit between resets/changes - there are some really inspiring changes in there that i almost want to capture and play back, it's a really fun module to explore with.
    Neo-Reimannian Triad Transform Demo 2.audulus
    Screen Shot 2017-10-11 at 5.36.23 PM.png
    1846 x 1736 - 996K
  • 237 modules!
  • :) @biminiroad, love the patch. I agree that we certainly don’t need extra nodes. I would be in favor of ditching the constant node unless there are performance benefits, assuming the knob is not exposed by default. I sometimes use it instead of an expression, but only because it’s slightly more efficient.
  • @biminiroad

    >>here is no similar analogy for a button (i mean maybe a modem reset button, but theres no need for anything anyones made in Audulus).

    There actually is an analogy

    Knob are to trimpots as switches are to jumpers.

    But that's not the point, nothing you can say is really going to persuade me my point is invalid. My opinion is based upon frustrations encountered when using Audulus. Knowing the approximate rational for how @Taylor prioritizes coding doesn't alleviates the tedium of exposing trigger nodes one at a time because that is the only way to ensure you aren't putting i them in the wrong places.

    >>If they’re inside the patch they’re either deliberately hidden (respond to MIDI keys without taking up UI space)

    That actually isn't true, midi cc only responds to the level of abstraction you are looking at. I found that out when I was making that live patch for the modular group. It would be nice, I admit, but currently triggers can't even be toggled with midi data so I just ended up avoiding them.

    >>What you call parallel construction I would call unnecessarily confusing to newbies.

    Well that's why we are making the uModular collection, isn't it? I think we are having a conversation about the second order organization underlining finished modules in the current iteration of Audulus.

    >>I rarely, if ever, use constant nodes myself

    So with uModular it's fine to set the aesthetic standard. It's your show, you are the boss. But it's a mistake to think that the things you view as extraneous should be eliminated. I candidly think the osc node is extraneous, yet I don't think Audulus would be better without it.

    >>Anyway I hope you understand I see where you’re coming from and why your reasoning makes sense

    I understand you hear me, this makes me glad. Also, as we have talked about this before, I hear where you are coming from. I think there is room to have this be one of the things we disagree upon, like the Muff Wiggler forum. Also, I'm grateful for all the great stuff that happens within Audulus and with your helpfulness in particular. My grievances on the hot button issue (intended) of triggers just happen to be very well defined because they annoy me.
  • Here's the latest for my contributions. I edited the scale and offset module for range and centering (halfway on offset was two octaves down) and added a four step chain-able sequencer that takes external inputs instead of knobs.

    10-12-17 updated file for bug fix in quantizer.
    Screen Shot 2017-10-11 at 10.27.09 PM.png
    1180 x 977 - 297K
    uModules - take 4.audulus
  • @stschoen Any changes to the shift register, or was that included for good measure?
  • I only changed the scale and offset and added the sequencer. Also encapsulated the numbers for the various scales. I've stuck all these in one file just for convenience. Hope we come up with a workable library soon.
  • ty for the clarification. You know what's funny? I'm always shifting things down two octaves by default, so no wonder that node sounded just right to me ;-)
  • @RobertSyrett, me too, that's probably why I didn't notice it until now. I just discovered a bug in the quantizer. It works fine set to A (0 for root note) but adds an extraneous note when set to C as the root using the natural minor scale (adds an A for some reason). I would have never noticed but I was testing the note display. I'll have a look at it tomorrow and see if I can figure out what's going on.
  • bummer, I was going to use it to make a triad generator. I shall hold off.

    edit: this is why meters are so useful!
  • Actually I wasn’t sure if it was the quantizer or display, so I used your tiny keyboard display to check my work. It and my display agreed, so I decided it was the quantizer. To tell you the truth, I looked at the equation I’m using to change the root, and I don’t remember how I came up with it. Tomorrow is another day! :)
  • Lol @robertsyrett you are literally triggered! Jkjk

    Solutions to your problems that dont require a new node:

    1-group expose (coming - expose from subpatches up levels)
    2- midi keys not responding is a bug and I will file that, but its not so terrible since the keyboard node can do the same if not more
    3- constant nodes probably should die and be replaced by a knob that can be exposed or not exposed
    4- the oscillator node is anti aliased - i know the aliasing sound doesnt bother you (or me) but it does bother some people. There is no node that could replace it like a knob node could replace the constant node, so thats not analogous.
    5- I keep telling Taylor that small changes to the way the workflow is handled would make for more and more complex patch development and he hasnt gotten around to it because a) he’s working on a new app b) he’s spending all his free time keeping Audulus running on the new OS releases c) he tells me these small additions are not as easy as it seems. He understands perfectly why they would help and is eventually going to change. The workaround right now is to create basically template knob/button arrays that you can copy/paste into a new patch. That way you still might have to move around a bunch but you dont have to expose them one at a time
    6- Audulus would be more efficient to navigate building if there were fewer nodes. Also the menus could use a redesign/reordering. Theres no reason for the Mixer node. Fewer nodes means fewer distractions when navigating to the menu item you want.
    7- since the trigger node is optionally exposible, it does everything you say you’d want two separate nodes to do, except it needs to be directly modulateable like the knob. I guess my argument got bogged down in reasoning that it makes more sense to have two separate knob nodes (which are also visually distinct - would the button node look different?) than two different buttons, because I dont really see too terribly much of a need for the constant node if the knob is optionally exposible. I think it should still be exposed by default (and perhaps so should the trigger node) but the ability to unexpose it would make the constant node useless. It would probably also be good for the button to be defaulted to latching switch behavior since the proportion of patches that use them as switches rather than momentary buttons skews heavily toward the former.

    So yeah I understand your annoyances, and we’re going to address all of them eventually, but a new node is not the answer to that - expanding the functionality and fixing bugs for whats already there is.
  • Hi folks, my mantra for programming is "there's always one more bug" and that often seems to be the case for Audulus as well. I discovered a bug in the quantizer module I developed for the two versions of the uModular scale quantizer. This also affects the maj/min quantizer in the uModular collection. The bug occurred when a 0 value (A) either was not in the scale or was masked. If the input note was closest to the octave (1) then a 0 would be output rather than the closest unmasked note. My apologies. I have attached revised versions of the affected modules and updated the uModules file I posted yesterday. @biminiroad, I took the liberty of correcting your version as well.
    uModular Quantizer V5.audulus
    uModular tiny quantizer V4.audulus
    Scales Maj-Min Quantizer V2.audulus
  • I’ve taken another shot at a micro version of my scale bender. I decided to do away with the knobs and only provide the 1/o inputs on the front panel, along with a knob on the side (easily duplicated) that can be connected to the particular step(s) one would like to bend.

    The side knob is calibrated so that one can set precise deviations by hand within a range of + or - 50 cents, with its output scaled to 1/o so that it can be connected directly to the inputs. One can still open up the patch and set ratios or fractions under the hood as well as see a numerical display of the precise deviations for each step. It feels a little more elegant than my previous attempt.

    Here with a quick demo. I’ve also included a clamp in the keyboard module so as to avoid the dreaded white cables.


    I also noticed that the position of the D# and E inputs had been swopped around in the previous version with knobs on the front panel. I’ve replaced that file with a corrected version.
    RM µSB.audulus
  • wow, that's like scale bender extract! very nice use of quartertones in the patch also.
  • @rudiger - thanks for the contribution!