What's your top feature request for Audulus? :)
  • >I think there should be a phase control from 0-360, but you can already do FM with the math nodes and whatnot. What you can't do is sync two audio oscillators and have one start at 0 degrees and the other at 90.


    You can already set phase with the phasor oscillator.
    90 degree phase difference..audulus
    15K
    Screen Shot 2017-08-02 at 2.06.26 PM.png
    957 x 536 - 89K
  • @RobertSyrett - Yeah, I'm talking about the anti-aliased audio oscillator :) Thanks for adding that patch though!
  • I would love to have some sort of non-volatile memory other than the knob and toggle mode trigger. A node than would provide read/write storage of a single value that persists when the patch is opened and closed would be incredibly useful. Both the knob and Trigger are read-only from the perspective of the patch itself, so there is currently no persistent writable storage and even volatile storage is limited to the sample and hold node.
  • @stschoen - the non-volatile memory will come in Audulus 4, with the Data node :)
  • AUv3 for iOS seems in the pipeline. Are there any plans on cpu improvement as well? I guess running Audulus in multiple instances will eat up cpu pretty fast...
  • @Heiliger_Bimbam - As I understand it, there are 2 main areas of CPU improvement to come:

    1) Streamlined expression node. Currently using a Mult or Add node uses less CPU than an A*B or A+B expression. That's something Taylor will get to at some point.
    2) Signal sample rates. Audulus currently evaluates every signal at 44.1kHz, even the ones that go to lights. Lights could be updated every 60Hz and save significant CPU in larger patches with lots of them. It would be ideal to have a sample rate node that would adjust the sample rate manually in-line so you could up/downsample for effects like distortion and filters, and downsample for control signals like buttons and some knobs. Before the sample rate node comes, Taylor will probably just adjust the way lights and buttons are calculated.

    That said, Audulus isn't particularly harder on your CPU than any other synth program out there - it's just that it's possible to create larger more complex synthesizers with Audulus than most. You wouldn't be able to have a large patch in Moog's Model 15 and expect to open many instances of it (at least, that's my understanding - haven't had much first-hand experience with it).

    A third improvement would come in people streamlining how their patches work too!
  • Sounds good :)
  • Double tap an output and then double tap an input to connect without dragging
  • 1. Would love to be able to double-click the text- and expression-nodes to edit them. Would save quite alot of time.
    2. I accidentally drag my modules when playing with knobs quite alot. How about right-click a module/sub-patch and lock it in place? Or maybe would that go against the "philosophy" of the ux?
    3. This one is probably not possible, but alt-drag is a common "duplicate" function in alot of apps (and finder). Would also save a bit of time not having to locate the location of a paste outside the viewport.
  • @SynthEnthusiast - I just realized there's a little-used feature where you can right click on an output on computer and the wire will stick to your mouse without having to hold it down. I know this isn't iOS, but thought I'd share. Good suggestion though.

    @Dantveita
    1. Agreed.
    2. There's a lock function on iOS, but not on computer - I think there should be a lock modules and lock view option both. Taylor and I have been discussing this on the issue tracker.
    3. alt-drag is pan currently. ctrl-c+v is pretty quick. What would be best I think is if Audulus just had custom keybindings like games usually do. The paste thing is going to be solved by "paste under mouse/finger" improvement that's coming.
  • Screen Shot 2017-08-14 at 12.47.48 AM.png
    277 x 160 - 12K
    Screen Shot 2017-08-14 at 12.49.33 AM.png
    408 x 152 - 11K
  • @robertsyrett that's a good one! And yeah since it has its own subcategory in the bar I unstickied it. I don't want too many stickied posts to overwhelm the new forum users :)
  • Lasso-tool + Shift: After making a selection with the lasso-tool, holding shift lets you make a new lasso-selection :)
  • It would be great if you could create a module, insert it into another one and then expose it's UI elements (knobs, triggers, meters, LED etc.) and possibly the frame. That way something like the Curvature synth would already be "separated" into sections.
  • @stschoen - that's high on the list def - would also get rid of lots of redundancies and the need to rip functionality out of a module so that it can be exposed.

    Actually that function + group move on UI would have made making this synth take 1/10th as long. Of all the feature requests I think those two added together would spark a mini revolution in patch design for Audulus.
  • I'm playing around with a 16x16 led display and 95% of the time was moving lights and making sure I moved the right one.
  • @stschoen Taylor and I talked about this today and it will probably be more of an Audulus 4 thing - he's pretty much at the point where MIDI out is the last thing he'll do for 3, then he'll start working on Audulus 4 features.
  • I think that makes sense. That would be a big change for a point release.
  • I look forward to AUv3 in Audulus. I hope midi out for AU is also planned. This will be perfect for using and building sequencers in Audulus and using them in hosts.
  • I know this thread is insanely long, but there are a few walls I've been running into with Audulus lately, and I'd like to add them to the list (if they're not already):

    1) a more efficient EXPR node

    I don't think I'm overstating when I say that the EXPR node is the heart of nearly every really interesting thing you can do with Audulus. From custom filters to sequencers, to you name it. You're gonna need an EXPR node or two ... however the thing sucks CPU like a hoover.

    This is a serious limiting factor to what I can build with Audulus. For instance, I've managed to hack together a pretty good sounding formant filter, but since there's no stock bandpass filter with a Q setting, I need a custom filter ... at least 5 of them (10 in stereo), each of which needs a boatload of EXPRs.

    The end result is that I can't actually USE my formant filter in any context other than "here's a demo of my formant filter". A minimal step sequencer and a minimal oscillator are about the best I can do. Polyphony ... well ... it can be done ... carefully. The problem is all the EXPR nodes ... However ... I think we could bypass the NEED for so many expr nodes if we had:

    2) a division node

    3) logic gate nodes not constructed of exprs (OR, XOR, AND, NAND, etc)

    just those two things would probably make the need for an improved EXPR node less relevant (as we can bypass interpretation of the formula text -- I suspect that's the big CPU spend). So yes ... slightly less elegant to patch than the EXPR node, but efficient so we can stack them n-levels deep with minimal CPU overhead when they're buried in things that potentially need a lot of replication (like filters).

    Some other things on my list:

    4) let the 'shape' input on the OSC node modulate the phase on the sine wave (like the way it modulates pulse width on the square wave. super easy FM.

    5) a stock BP filter with resonance (Q)
    6) a stock all-pass filter
    7) an FFT node

  • I agree with @plurgid regarding the expression node. Personally I would rather see an improvement in expression node performance rather than additional basic logic nodes. I suspect that the expression nodes are interpreted rather than compiled, so there is probably room for room improvement. +1 on the filters. It would be nice to have a set of bi-quad based filter variants as basic nodes rather than having to use the "cookbook" formulas.
  • @carnbot - MIDI out is definitely planned for AUv3

    @plurgid @stschoen - Taylor has mentioned that there are some things he can do to really streamline the expression node. Like right now for some reason the mult node is more CPU efficient than doing x*y in expression. Not sure why this is, but Taylor has it on his radar. My sense was that it's a complex thing to pull off and he might be waiting for Audulus 4 to do it, since it might take a while to do. But yeah, totally hear you on that!

    Furthermore, in A4, we're going to import the whole Csound library, which includes a lot of stock filters and things that will run wayyy faster as nodes. So nodes section will definitely be exploding there, and it will make it much easier to do formant filtering, for example.
  • Glad to have you back! Good to hear that some changes might be on the way! I have a tendency to gravitate toward the more complex patches so any improvements in efficiency would be great.
  • I had to look up what it would mean to import the whole Csound library. Seems pretty amazing!
    http://csound.com/get-started.html
  • @orand - yes! sorry I should've posted a link. There's a TON of stuff - this is a more direct link to the features overview: http://csound.com/docs/manual/PartOpcodesOverview.html
  • Automation and MIDI learn in AU?
  • sysex pls. :)
  • Midi Out would be very cool,

    Plus the function of selecting the audio device connected to your laptop/pc.
  • Just a quick thought. Can all of the signal wire and graphics animation be turned off as an option. When Audulus is placed in the background, patches will always play just fine for me. I was told that the choppiness and glitching is caused by the graphics load. Would seem like a very viable option. I would rather hear the music than watch all of the pretty lights flashing (ha ha)
  • @waynewedge - the flashing wires don’t take up really any of the CPU - it’s that every pixel is being redrawn constantly. If it weren’t, there would be stuttering when you zoomed in and out.

    Good thinking, but it just wouldn’t amount to any significant CPU savings. Taylor is working on more graphics optimizations though :)
  • My biggest wish is AUv3. This would be the first custom AUv3 effects builder to my knowledge. If this happened it would take the iOS community by storm and the patches would overflow onto audiobus posts.

    My second wish is for the unsexy work of optimizing the coding so that the CPU hit keeps diminishing. That way we can get into some serious automation and AUv3 stacking down the line.
  • @futureaztec - AUv3 is coming soon! It’s in alpha right now, but very close. I agree it will be huge for iOS!

    Taylor’s pet project with Audulus is to always keep working on the optimizations. I know that especially when running it in the background, a lot of CPU is freed up, especially when you’re running it on a high pixel screen like the iPad Pro.
  • Well I have read quite a few posts on here wondering about a way to disable the graphic animations for performance, so maybe that will be a good way to run it ugly -- like when I used to play quake 3 with horrible graphics but such a smooth frame rate. :D

    Well I am very happy for you with AUv3 comming. It will probably be the biggest thing to hit iOS music this year. However, if running 3 AUv3's of Audulus in one DAW cripples production work (having a nice delay, a side-chain compressor, and a gate effect, for example), then the usability will probably center more around niche patches than so much custom basic effects. Personally, I would like to be able to build a whole bunch of little low cpu patches and have multiples to work with in a session.

    Cheers to Taylor for the hard work. I am sure there is a nice feeling when a laggy patch all of a sudden tightens right up after remodelling the back end for weeks.
  • Very happy to see AUv3 confirmed. Feel like that’ll be unreal when it’s completed. I’d probably make Audulus my only synth app, not just my favorite one. Another feature I’d love to see would be a frequency spectrum table node to graph harmonics from sound input to assist in additive synthesis and EQ/mixing.
  • Yeah, if you could just drop a low cpu graph in a track channel it would help so much with DDMF's 6144, for example.

    I would also like to see some improvements to the spline node. Namely the implementation of curves. I really love using the spline as a gate and if curves could be brought into play it would just be at a whole new level...

    I really love Audulus btw -- just had to say it!