Audulus 3.0 -- What is to come
  • I've been hiding out in my laboratory working on Audulus 3.0.

    Here's what I'm shooting for:

    - new file format with near-instant patch loading/saving
    - removal of default/fallback values on inputs. Instead we will have a new Constant node. This simplifies the UI a bit.
    - simplification of some nodes: Osc will loose semitones/cents knobs. New Envelope node which doesn't try to also be a VCA (like the ADSR node).
    - reduced memory usage (especially during load/save)
    - backward compatibility with existing patches (don't worry!)
    - new I/O nodes which can output to the speaker, or input from the microphone within sub-patches

    Under the hood, there are really big changes that will make it easier for me to work on Audulus and implement the features you've requested :)
  • Also, the input and output nodes will be changing so they work based on exposing. So you'll have explicit control over where they appear on the front panel, and the code doesn't need to worry about how things are ordered. :)
  • Awesome! The JSON format is particularly exciting to me. :)
  • Exciting!!! Can't wait
  • Yeah, I'm super excited about this. It's going to take Audulus to the next level :)
  • And I can let a computer program make my 8x8 Conway for me, so I don't have to do the required 512 connections myself.. ;)
  • Can't wait, let me at it!
  • Any chance the new I/O nodes will support multi-channel USB audio on ipad?
  • @Neo, I'm planning on it! I ordered a cable so I can use my audio interface with my iPad :)
  • @jjthrash, say what now? How are you going to have the program make the connections for you?
  • @ceilidhshipley, as soon as the format of patches settles down, I can write a program to spit out something that looks like what @Taylor posted above. So long as the right "from"s go to the right "to"s and the "input"s and "output"s point to the right place, I won't have to manually do all the connections myself.

    Hard to describe, but the short version is that the consequence of the "JSON" format will be to make it easier for programmers like me to do fun stuff like that.
  • Coolio! That's a bit over my head right now, but I'm down to learn. Can't wait to see the v3.0 patches.
  • It's actually not much more complex than a spreadsheet. Instead of using rows and columns, you'd use froms and inputs. But it would take some understanding. Would be an interesting project to describe how to do such a thing, but I imagine there's quite a bit of work until 3.0 actually comes out. :)
  • Oh, I think I see. Something like the EMS VSC 3's routing matrix?
    EMS VCS 3.png
    1200 x 956 - 868K
    1024 x 1109 - 2M
  • @ceilidhshipley, the "wires" section is just a list of what is connected to what. So in the example above, there's a wire from output 0 of node 0 to input 2 of node 1 :)
  • yowza! the ability to write patch generator scripts! In javascript!

    I have ... ideas ... and stuff.
    Screen Shot 2015-02-24 at 9.36.29 PM.png
    231 x 214 - 97K
  • @plurgid, I'm predicting generated patches that will bring Audulus to it's knees :-\
  • Thanks Taylor, can't wait to try 8 channels into the ES-3..... you rock :-)
  • Thanks @Neo :). What do you use to hook your iPad up to your ES-3?
  • 3.0.png
    1232 x 1492 - 210K
  • The JSON patch specification format is a great idea, and taking time to refactor a code base to allow faster and easier development in the future is always a good idea. What about MIDI out and interfaces to hardware modular synths. It seems to me that many Audulus users will have come to it because they have and hardware modular synth, and see it as a natural extension of that. But currently integrating Audulus with a hardware modular isn't straightforward.
  • @bennelong_bicyclist, MIDI out will be one of the first things I work on after 3.0 :)
  • @Taylor, what are the goals of the UI tweaks?
  • @jjthrash, increasing the size of the node body makes it an easier tap target. Also, moving the I/O on most nodes to the interior is consistent with the changes I'm making to sub-patches.
  • Good progress on sub-patches today :)
  • @Taylor Cool! Question: what implication will expose-based ins and outs have on basic pre-IAP function? I have almost all the IAPs on iOS, but not in OSX (yet). Will we still be able to create meaningful subpatches without the Custom Node IAP?
  • @jjthrash, no changes there. There are actually still input and output nodes.
  • @Taylor Here's a question that's been on my mind.
    Will it be possible to copy exposed elements along with their locations to another subpatch? Or, perhaps, expose the panel of a subpatch within a subpatch?
    For example, the LCD numeral subpatch. At the moment, if I want to use it in a subpatch, I have to rebuild it every time.
  • @JDRaoul, yes, I've made the locations a property of the elements, rather than the patch node, so they should copy. We might need some way to move exposed elements around as a group.

    With no distinction between I/O and exposed elements, it won't be very useful to expose an entire panel. For example, your LCD numeral would be exposed along with its input (which you'd probably like to remain hidden). I suppose we could just have a policy of not re-exposing I/O. How does that sound?
  • @Taylor It sounds fine. But if it's possible to copy the whole thing including location, then maybe exposing the exposed is an uncessary layer of complication.
  • @JDRaoul, yes, possibly. Though in your case you'd copy and paste your LCD numeral but then not be able to move it around the panel without moving each of the lights. Exposing the exposed could be a good way to group things. Coding it up might be a bit tricky though.
  • @Taylor, I dig your drift. Just a thought. I'm looking forward to seeing what you come up with.
  • I'm wondering if the the sub-patch front panel could be edited in the same way as the nodes. Specifically, I mean the ability to group, and then drag as a group. I feel this would be the single biggest time saver for UI editing.
  • @ceilidhshipley, it's a good idea, it's just that the implementation gets complex fairly quickly. I'll be thinking about it :)
  • Thanks for considering all our input @Taylor. I can't wait for 3.0, I'm so pumped!
  • 3.0.png
    2095 x 424 - 155K
  • Sweeeeeeeet! Looking sharp @Taylor. I like the stereo output and what I'm assuming is a pared down keyboard node. Good use of real estate.


    1. Will I still be able to access all my outputs if I have more than just L/R? I have this fantasy that I will have each virtual instrument playing out of it's own speaker as if it were a live band in the room.

    2. Will I still have access to the keyboard node settings? (poly/legato, channel, etc.)

    3. And then to complicate matters: would it be possible to modulate the keyboard settings through inputs? i.e.) cycle through MIDI channels.
  • @ceilidhshipley, thanks!

    1. Yes. The speaker node is just a convenience.
    2. Yep. It's not done yet.
    3. Hmm... I definitely can't do poly/legato. But I could do MIDI channel. Feels kinda weird though to be able to modulate the input channel.
  • Yes, come to think of it, it does. My apologies, I'm getting things backwards. I want to be able to select virtual instruments with a hardware controller, but I can do that with demux. Sorry for the confusion.
    The only thing I really, really need in a keyboard node is pitch wheel support. I will say no more. Thank you! :)
  • @Taylor That looks real pretty!
    Will old patches need special treatment to work in the new environment?
  • @JDRaoul, perhaps some layout changes. Certain nodes may be automatically replaced with sub-patches. For example, the Osc node is loosing it's semitones and cents controls, but existing patches will be translated with a sub-patch (or if that doesn't work, a backward compatibility oscillator). Same goes for the ADSR which is loosing its ability to act as a VCA.
  • By the way, these changes are to give you more precise control to be able to build higher performance patches (i.e. don't calculate a cents/semitones offset if you don't have to, etc.)
  • The new OSC and ADSR's don't really sacrifice functionality. You can still offset by cents and semitones with a multiplication node. The ADSR can still act as a VCA by routing a control signal through it rather than audio. Is that correct?
  • vca.png
    739 x 376 - 56K
  • So the cents/semitones will have to be set with an Add/Subtraction node?
  • @AlbertGauer, yes, well, cents and semitones are exponential so a little math is required. I will probably include a convenience sub-patch that you can just drop in to get the old oscillator functionality.