What's your top feature request for Audulus? :)
  • The ability to copy patches & sub patches & upload them into some kind of file that can be shared by linking or pasting on iPad.
  • @Ripper7620, that sounds like Dropbox integration to me, no?
  • Yes, that would be great.
  • @Ripper7620, I noticed that AudioBus's sharing uploads the preset to their website. I wonder if that would be at all preferable to using dropbox from a user perspective?
  • @Taylor; Anything that makes access easier would be a huge plus, I haven't checked out the AudioBus website yet.
  • Hi Taylor, I think I raised this before, but an on-device folder/file system would be great. Rather than a whole screen full of patches it would useful to drop things in folders. Much easier to navigate I think. Dropboxis not always ideal or available in some cases.
  • @Sinapsya, is the one feature or two? ;-)
  • @Taylor
    As you know, I am wishing for non-volatile memory. A block of data that would automatically be saved with a patch would be very useful. Also useful would be a node with a single non-volatile bit, like a switch that remembers its state.
    Thanks for asking!
  • I'd like to be able to select multiple input and output channels within AudioBus, similar to Loopy. See pict.
    2048 x 1536 - 230K
  • Hoping someone will +1 someone else's suggestion :)
  • Granular Synthsis and Wavetable ;-)
  • @Sinapsya
    Granular Synthsis and Wavetable ;-)

  • @thinds, shall I replace your previous suggestion with that? You only get one vote ;-)
  • I'm sticking with my first answer as I think running multiple inputs to multiple outputs increases flexibility. And I really like the idea of non-volatile memory; definitely a benefit. But just to throw out another suggestion or two, since I'm on an iPad: 1) a recorder/sampler with the ability to midi toggle between .5 second to 4 seconds with playback as a loop, and 2) less memory usage from the pitch shifter. 3 of those brings memory usage up to .70. Most other things I think of, I think I can build myself in custom nodes.
  • No I think a decent folder system first............or granular:-)
  • Yeah, a folder system would be great.
  • Actually, thinking about it, a base tool package would be most helpful to new users. I mean, routers, bypasses, counters, different on/off switches, etc. There are quite a few here and there in posted patches, but nothing that has them all together. For someone new, opening a blank slate with no toolbox or any idea where to begin aside from the examples can be a bit daunting. If it was me, I'd ask the posters on here who have done very complicated patches to get together and build a base package.
  • Hi Taylor.
    I vote for the request of @thinds -- folders in the patch browser or any other ways to organise patches.
  • 1) Up-sampling/Down-sampling with a good antialiasing filter.
    2) Sampling Node
    3) Antialiased syncing of oscillators ( and don't forget to fix the 32 bit/64 bit discrepancy between phaser nodes and oscillator nodes).
    4) +1 for JDRaouls memory suggestions
    5) Simultaneous instances of Audulus in in simultaneous positions (source, effect, ouput) in AudioBus
    6) Scalable type face for better labeling of knobs and switches on dense UI's.
    7) Slider knobs (fader style)
    8) Dual stacked keyboards with pitch and mod wheels

    Above are in order of priority, 1 being highest, 8 being lowest.
    If only one vote, then # 1, hands down....:-).
  • Oh, and I forgot...a waveform select input on the oscillator nodes so that we can change waveforms at the UI level....(you can place that between #3 and 4 in my previous list)....:-).
  • Ah. Just read the thread from the top. Which I should have done earlier before commenting.
  • @thinds, no worries!
  • I'm sure @Tomaszmanderla would like to vote ;-)
  • Also, @ZenLizard, what say you?
  • Audio Unit Parameter Control in Ableton Live.
  • C'mon @Taylor, we all know how good you are, just implement them all at once. Nothing to it I'm sure?
  • I'll second @thinds latest motion (but not changing my vote)....(I think Taylor wants the summer off... Not a chance!.....:-) )
  • @frodebang, welcome! I put your vote above :)
  • @ZenLizard, that's already implemented in 2.8 :)
  • @ZenLizard, basically the way it works is there's a menu where you can choose any other patch to paste into your current patch. So its not limited to individual modules :)
  • Well... that request was easy then. Call it a senior moment.
  • @ZenLizard, 2.8 isn't out yet though! Not a senior moment :)
  • First I was embarrassed because I thought I completely missed something obvious. Now I'm embarrassed because I don't even know what version I'm using. Doh!

    Oh well, I never claimed to be the sharpest tool in the shed ;)
  • Since my other wish was already coming in an update, here are a couple of hopefully minor things to consider:

    I'd like to have the lables on the left side of nodes be right justified, so that they don't get covered by the node. I'd also like to see the vertical order of inputs on sub-patches be determined by their x/y position within the sub-patch or their selected input assignment, rather than the order in which they were created - same thing for the outputs.
  • If by "non-volatile memory" we mean some kind of snapshot system where you can save different states of your patch - e.g. save values of the components that are already the patch like in Reaktor, then I'll use my +1 for that. I actually think that opens up Audulus to a broader range of folks who just want to download others' modular creations, scroll through the presets, and start using them in a song.

    I also think wavetable/granular would be pretty awesome.
  • @SuperNiCd, non-volatile memory is a memory node. I'll put you down for snapshotting :)
  • Sounds good @Taylor. I have no idea what one would use a non-volatile memory node for. But I'll look forward to you building it someday and @JDRaoul showing us the cool stuff you can use it for. ;-)
  • #SuperNiCd
    A memory node will make it possible to save and recall multiple parameters like synth settings or sequencer data.
  • I guess I'm still not quite understanding. Wouldn't snapshotting be easier to use/more powerful? Is it that you can recall different configurations in the non-volatile memory node from another node, e.g. an LFO or some other signal generator? Not trying in any way to diminish this feature request, just trying to increase my own understanding, as I'm definitely in the "still learning" camp.
  • Snapshotting seems like overkill if you only want to save and recall a limited number of values.
    To emulate a hardware synth with a bunch of parameters we need to a way to save a configuration, sort of a patch within a patch.
  • Thanks @JDRaoul. I *think* I understand now. These two things both have a similar purpose/intent, but would be slightly different in how they are accomplished. Snapshotting (presets) would be more powerful/inclusive but doesn't really exist in the hardware realm with modules and patch cables, and a non-volatile memory node would more closely emulate an actual hardware modular unit. Does that sound right?
  • It will be easier to show you what I mean when (if) it comes to pass.
  • @JDRauol, @SuperNiCd,
    JD...if I'm interpreting your non-volatile memory correctly, you would be able to save groups of all of your parameter preset values for a particular patch in the non-volatile memory node within that patch (each group representing a different sound or sequence for that patch) and be able to select any group of those patch parameter presets from within the patch....is that correct?.......if so, that's why I +1'd it....and that may also help SuperNiCd understand your request.

    (Though, note to Taylor...I'm not changing my #1 vote for upsampling/downsampling).
  • I wonder if we should change the rules so you can suggest your own feature AND +1 someone else's?
  • Thanks for the education, here. Based on what I [think I] know now, seems like either snapshotting or non-volatile memory would accomplish roughly the same end. I think either one might help to grow the user base. Part of the magic of, say, Reaktor for me was that I was able to go in and start using it long before I had a clue how to build anything in it, and that was enough to spur my curiosity. So I'll +1 non-volatile memory if you're trying to get something like a popular vote.
  • @Taylor....sounds good to me...two features for the price of one vote!
  • As for a little PR for my own feature suggestion.... (upsampling/downsampling with a good antialiasing filter), the capabilities regarding the amount of unique sounds and effects, the control over those sounds and effects, and the quality of those sounds and effects will improve drastically....that should attract more new users than anything else....even if they're only downloading other peoples patches....(though I don't know yet as to how patch efficiency may suffer...that's Taylor's job....:-) ).
  • @BTL, could we get away with supersampling the entire patch? That would be easy to implement. Having nodes that do the up/downsampling would be much harder.
  • @Taylor,
    You might know better than myself....my thought was to upsample (and perhaps pre-filter) only prior to those portions of the patch in which the mathematics require, post filter, and then down sample....in order to maintain some patch efficiency, though I don't know how efficient you can make the interpolations.
    On the other hand, these patches are likely to be large and complex...I'd be concerned that supersampling the entire patch may significantly hurt patch efficiency.
    You have more insight to your current software and architecture than I ....what do you think?