What's your top feature request for Audulus? :)
  • @Alexander, @JDRaoul, @biminiroad

    Having spectral processing is an interesting option. Instead of having FT and IFT nodes, Audulus could automatically insert the conversions from time to frequency domain, so the user doesn't need to understand FTs, and the interface isn't complicated by having multiple types of signals (time and frequency). On the other hand, that might mean the spectral nodes would have to be very high level, so the user would lack the control required to build a module like the spectral panner, and would have to just rely on a built-in node.
  • I'm sorry if this thread was meant for just one request. In my original post I made a list. Sorry bout that.
    As I've already disobeyed the rules, I may as well post one last request. (I will obey from now on though.)
    On the iPhone, allow for the keyboard to be visible and playable without the rest of the pop menu in the way of the canvas. IE anything above the keys in the pop menu is not shown. As is on my iPhone at least, the menu fills the screen which is nice, but having the option to play the keyboard and view at least some of the patch would be nicer.
  • @DrYes that post is really old - I like to hear everyone's feature requests - often they're things I've brought up with Taylor myself, and he goes, "Eh, I dunno, let's wait and see if other people want it," so if you list more things, chances are you'll hit on something that I want too ;) That said, the RGB node, brought to you by yours truly *doffs cap*

    (well, via Taylor of course hah!)

    I like the idea of the keyboard just kind of "hovering" over the space so that you can still drag around it, but it stays there. Just keep in mind we have lots of little UI tweaks and improvements and each of them takes many hours to implement, so it might be a while, but pretty much every good idea people have that isn't somehow mutually exclusive and is a reasonably achievable thing to do, we can, probably will, and may already even have plans to eventually do - heck, some features that people are requesting already exist in the code of the Audulus version that you have, but are hidden because they need just a little bit more work on the beta end to "pop out" so-to-speak. :)
  • After my first few days with Audulus, here is what I would like to see:

    Most Wanted:

    - I'd really love the 'midi learn' function to respect midi channels (as I mentioned in the Beatstep Pro thread http://forum.audulus.com/discussion/776/beatstep-pro-audulus#Item_12 )

    - More robust ins & outs. I bought Audulus with the intention of developing a live techno patch. I think it will excel at the performance aspects however when recording I'm limited to a single stereo out (unless I'm missing something). I'd love to be able to send different parts of my patch (drums, bass, pads etc..) to different channels in my DAW for mixing and mastering.


    Nice To Haves:

    - I find there is a little too much menu diving. I would imagine this will only get worse as more nodes and modules are added to core. I'd love to see a quick, fuzzy search box similar to what's provided in Max and Reaktor.

    - Wireless patches. The patch cords look terrific in Audulus but I think large patches would benefit from something similar to Max's 'send' and 'receive' nodes.
  • Well here is my list:

    - option to change knobs to sliders
    - scales automatically displayed on knobs and sliders (option), with min, max and some intermediate values
    - objects scalable like knobs, sliders, leds, text,...
    - form nodes: line, square, ellipse, triangle,...

    Cheers
  • @Toy Division

    "- I'd really love the 'midi learn' function to respect midi channels (as I mentioned in the Beatstep Pro thread http://forum.audulus.com/discussion/776/beatstep-pro-audulus#Item_12 )"

    Good suggestion thanks!

    "- More robust ins & outs. I bought Audulus with the intention of developing a live techno patch. I think it will excel at the performance aspects however when recording I'm limited to a single stereo out (unless I'm missing something). I'd love to be able to send different parts of my patch (drums, bass, pads etc..) to different channels in my DAW for mixing and mastering."

    More I/O is coming in 3, just takes time to get working how we want it to. You will be pleased.

    "- I find there is a little too much menu diving. I would imagine this will only get worse as more nodes and modules are added to core. I'd love to see a quick, fuzzy search box similar to what's provided in Max and Reaktor."

    The menu, as is, is a kind of work-in-progress. It was what we could do quickly before release, especially since I had the module library idea way late in the game (actually kind of the reason that all the releases didn't come out at the same time - caused a significant delay, node pun intended). I envision it where you can press a key or do a special click or something and a Pd-like "typing" window comes up that quickly sorts through and narrows down modules as you add more letters. Menu innovation is going to be key to the success of the long-term viability of the program, and we may even have to develop something totally unique as the library grows to 1000+ patches, which will inevitably happen given enough time.

    - Wireless patches. The patch cords look terrific in Audulus but I think large patches would benefit from something similar to Max's 'send' and 'receive' nodes.

    I have requested a feature myself that is what you're talking about - a teleport node, essentially. It would metaphorically work like Bluetooth, how it can have multiple channels that you sync up from end to end, but ultimately meant as a technology to free us from wires. I don't know exactly what @Taylor 's thoughts are on what I requested, but I'm with ya on this one all the way.
  • @Toy Division - To add, the Vias will do what you want, i.e., clean up patches. That's what they're there for (see attached example). I didn't come up with them myself, some other user did - maybe @JDRaoul ? It was so long ago when I first saw someone use it in a design I can't remember - if you want to take responsibility whoever you are, I'll give you credit in the Author section of the metadata because it certainly wasn't my original concept. I had to explain to @Taylor why they're useful - it's hard to get what they do until you see a patch with and without them.

    Vias in electronics are found on circuit boards and they are a way to "teleport" electricity to another part of the board using sandwiched alternating layers of conductive and non-conductive material - they are essential in scientific design where the placement of components sensitive to noise or induction need to be isolated in a certain part of the board that would make regular traces either impossible or require a larger board along with a total redesign (and thus higher cost) https://en.wikipedia.org/wiki/Via_(electronics) If you think about it hard enough, that's pretty much exactly what they do in Audulus, but the "interference" is visual clutter.
    VinitTs Synth.audulus
    581K
  • @biminiroad Thanks for the reply.

    I have just started using vias today to clean up some of my patches and it does make a huge difference.

    One area it doesn't address is communication between sub-patches. This is the area where send and receives really shine in Max. My Audulus patches haven't grown to need this yet (and perhaps it might not be even be necessary)... but food for thought.
  • @toydivision - exactly, that's why we need a teleport node. I should've said vias do half of what you wanted, hah.
  • Whew... lots of ideas here! We should do another tally of the votes so I can prioritize :)
  • Just to explain, my requests are more on the performance and cosmetic side. If you want to attract more users I think you know how graphics are important. That feeling that they're playing with a "real" thing. You've already done a great job when upgrading to 3.0, it's just going further.
  • Are the yellow circled objects the Vias mentioned above?

    My top request would be the planned MIDI out for Audulus and shoring up the MIDI in implementation.
    image.png
    543 x 500 - 70K
  • Yep! Look inside, it's just a subpatch with an input and output that's connected. You can "reverse" the primary signal flow of left to right by editing the UI of the tab and changing the left-to-right order of input and outputs - something that no other modular synth program lets you do. This isn't really necessary unless it's a big patch.

    There are other vias you didn't circle - I call those "tab vias" because they look like soda can tabs - and they're all different kinds for all different purposes. The waveforms are vias as well - you can pass signal through them in exactly the same way with the little ones, it's just like having a "window" on the signal as it flows by. The Via Collection is like the "module library" of the meters. I didn't think it was really that necessary to build module versions (in the "standard" euro-like patch) of the meters because the modules that really need meters to function already have them. You'd have to make a decent case for me to want to make module versions of the Vias (like, who wants a module that's just one blinking light and no controls?), because they would essentially be duplicates.

    If you aren't already, use the Vias to help clarify connections and to illutrate signal flow (if super neat layouts are your thing - it's actually one of my favorite parts of Audulus is finishing a patch and putting everything "just so"). Notice in that patch that I put a Light Via on the gate, but an RGB via on the gate - the RGB node can fade in an out and illustrates that the signal is an envelope, whereas the Light Vias only need to be on/off for gates.
  • The text via is great to label what connections are too. The more explicit you can be about exactly what your patch is doing at every step (especially with new multi-line text node which you can use to add in-app commentary like the tutorials are) - the more explicit you are, the fewer questions you'll need to field in the forum. People will just look at it and get it and pop in and say thanks - speaking of which, I haven't had time to check out all the new patches getting posted, but I will! Thanks guys, you all are obviously startin' to feel the heat of Audulus 3 that I've been simmering on for the last 3 months.
  • Thanks @biminiroad it's great, didn't notice the signal flow was reversed. This can be quite handy for when you want to do patches where there is a circular flow rather than the regular left to right. Will definitely be using them along with the text explanations in modules. If there isn't already a video on this topic, I think it would be helpful to make one as part of the tutorial series.
  • @Paulinko - definitely plan to explain Vias in a video - I actually believe they're one of the most powerful new additions to Audulus for one simple reason: they make designs easier to study (if people use them right!) and that then means you can use these new ideas you discover other people using in your own patches.

    Today I'll be pretty absent from the forums because I'm working on "idiot proofing" (not saying anyone's an idiot but me! haha) the documentation. I want it to be so, SO crystal clear that a middle schooler could read it and understand how to use Audulus, but, without it also being condescending in tone.

    This is meant to be a nod to the fact that we do not have the budget (yet) for proper translations for all our customer's native languages. That will happen eventually, but there's no way we can give a hard date on that yet. It will just be worded simply and have simple sentences and avoid jargon unless it's necessary. It's not my degree or anything, but I took comparative linguistics and I know how to keep explanations "beginner English" without them being torturous to read.
  • I was thinking about something @biminiroad mentioned the other day in this thread, about the tag system being slow. @Taylor Are you adding a database? That would solve the problem pretty easily. I hate making databases, but once they're working they're pretty nifty, and f-a-s-t too. :D

    Grain of salt: I'm just a lowly college student in computer science, so I don't necessarily know what's most efficient or fastest for this kind of project.

    Oh, one more request: Folders for projects. I'm psychotic when it comes to backing up my work, so I accumulate a lot of files in every program I work in. So for me, I'll have Project, Project copy, Project copy copy, Project copy copy copy, Project copy copy copy copy, etc. all on one screen. And that's just one project. Very quickly the file select screen becomes a cesspool of madness.

    Weirdly enough, a lot of iOS apps are guilty of dumping every file into a single list. In fact, it would be easier to count the ones that don't. Not sure what's up with that. Makes me wonder if I'm the crazy one, making so many files, haha. I do know who IS crazy though, and that's the developers that only put in limited numbers of save slots for projects. 76, Interpol, and DXi all spring to mind...
  • @Alexander if you're crazy then I am too with respect to folders and making copies of copies. From it's inception, iOS has gone a different route in terms of traditional file structures and how you organize and setup your work with the idea that the user didn't need to navigate through nested directories to use apps. Perhaps with the increased capabilities and more complex work flows people are coming up with they will reconsider file management on iOS.

    AudioShare is a nice app in that it allows you create your own directories/sub directories and to store all sorts of files there including Audulus files, has open in capability and integrates with Dropbox, etc. You may want to consider organizing your projects on AudioShare and/or some cloud storage so you can get both organized and free up your work space as you go from project to project.

    @Taylor you might want to update the information about the options for how you can get files into Audulus as some of the info on the front page is quite old and misleading now that you can use open in to load Audulus onto your iPad directly from Safari on iOS. It would be very nice to have the option to open in from Audulus 3 so I can save, archive, and organize my work with other apps such as AudioShare. Right now my process is to email my projects to myself and then use open in from the mail program.
  • Any plans to include Ableton's Link?

    https://www.ableton.com/en/link/
  • @ToyDivision @HighTunnels @Paulinko this is the next thing @Taylor is working on now that Audiobus is fixed
  • That's great, LINK really adds some solid sync for iOS and allows people to do things they weren't able to do previously.
  • Ableton link! +1
  • The AudioBus fix is waiting for Apple to review :)
  • Hello, I have a request for a feature:

    The knobs aren't easy to use because we have to zoom first. Because of this, we cannot see the effects on some elements which are not displayed on the screen.
    My proposal is to make appear somewhere on the screen a copy (with biggest size) of the knob (or group of knobs) which has been selected.
  • @jpalluin - this will probably never happen b/c a knob can control thousands of other things if you wanted it to. That said, you *usually* shouldn't have to see what a knob is controlling because it's a sound thing. It's helpful to see what you're controlling when you're changing a max step length or something like that, but the use of what you're asking for is actually pretty limited, sorry :/ it's a cool idea, though. Perhaps I'm reading your suggestion wrong - if you could draw a picture of it and upload that (doen't need to be fancy art, just knobs and boxes, etc) maybe you have hit on a gold idea but i'm just not understanding how it would look.

    I also suggest people use styli with iPad/iPhone, much easier to see what you're doing, especially if you have fat fingers like me. You will also more consistently get a connection because I assume like me some of you have calluses from playing instruments and sometimes the touch screen has a hard time recognizing your fingertips.
  • Using a stylus is a good idea.
    To sketch something and upload it with my iPad is something I just can't.....
    My problem is that It is compulsory to zoom in on the knob if I want to operate it.
    why not to add a square in the control section (like the square for the keyboard or the module selection) for the active knob ( the knob which has been selected with one tap on it)?
    This additional square would display a bigger knob (or a slider).
  • @jpalluin - "My problem is that It is compulsory to zoom in on the knob if I want to operate it." This is not how it worked in 2, but 2 wasn't Apple Compliant, either. The new closing inputs is. However, building my Cogito sequencer with the way it is now on my iPhone with 3 would've taken much longer. I don't think Apple ever envisioned an app like ours when setting those guidelines, so maybe they'll relax them in the future. The locking i/o and knobs does have the added benefit of not accidentally ripping away a connection as you navigate (happened to me in 2 sometimes) or changing a knob value.

    Touch interfaces in general need a lot more work to be what they can be (and, to some extent, what the claim they already are). Ever since iOS9, it's been so hard to just pull up the menu thing with the calculator and flashlight (whatever that's called). It's a software meets hardware issue.
  • They put all this definition into the hardware of the touch screen, then force you to use a huge area as the "minimum input." Don't get it. It would be similar in some ways to buying a huge HD TV, but the company who makes it requires you to watch it with one eye through binoculars in reverse.
  • I've given it some time now and still see a real use for a locked mode that locks everything in place but allows for panning and zooming as well as knob, button control. Not sure about cables as I have had the problem, on my phone especially, of accidentally removing a cable while attempting to pan. Perhaps a 2 function lock icon? One tap shows partially locked icon allowing for pan and zoom and another tap for full lock as is now?
  • @DrYes thanks, keep these ideas coming, we're working on a radical redesign of the UI for iOS based on all this feedback we're getting.
  • @binimiroad, I never asked someone to do impossible things. I do believe that you and M.Taylor hare talentuous people who do their best. Anyway, thank you for your time and efforts.
  • @jpalluin - didn't say you were, just explaining why things are the way they are in 3, sorry if that came off poorly! not my intention.
  • I had to jump back into Max today and it reminded me of one of it's strengths for on-boarding new users.

    If you click on a node and ask for help it'll open a new patch with a commented, working example.

    It enables you to quickly see (and hear if applicable) what the node does, and you can easily copy and paste the example back into your existing project.

    Perhaps this is a better solution than linking to the docs website?
  • @DrYes my experience with the difficulties of playing patches on iOS is similar to yours and I too would enjoy a mode with more lock options so you can zoom around but not break the patches accidently in the process.

    @ToyDivision perhaps it might be possible to setup some sort of Wiki type site where forum members could contribute patches and experiences with nodes and I'd say expand it to modules so there is support beyond just nodes and what Taylor and Mark have time available to do?
  • To clarify, the advantages of Max's help is that it's interactive and you never have to leave the patching environment. It simply opens inside your patch, you read, copy & paste anything that's helpful and then continue.

    I don't think this would require too much effort on Taylor's part as it could simply mirror the existing docs.
  • @Paulinko, @ToyDivision

    That's a great idea. If you'd like to build some patches for interactive documentation, that would be great. I'll put them in the docs repository (https://github.com/audulus/docs ... you can submit a pull request if you're ok with using git) and integrate it into the app. Probably the OS X version first because it's easier.
  • :-) OS X: Although gesture is fantastically integrated, I still like to use a mouse for certain things. My suggestion: When you press the spacebar. A "hand" icon appear instead of the mouse cursor and you get to navigate around the "canvas". Exactly like in Photoshop.
  • OS X: Command +F : toggle fullscreen mode.
  • @silkynight - word, i agree, would be nice - i often forget to work in FS mode! crazy to waste that valuable screen real estate
  • +1 for sampling.

    + .5 for FFT. The Max ~pfft object is a pretty user friendly implementation.

    sorry last thing. I think it would be cool to be able to pack unlimited lists into a poly wire. Right now you can only pack 4. But what if you could pack lists into lists so that 2 MonoToQuad containing data could then be run into another MonoToQuad and the value node would read something like ((1 1 1 1) (1 1 1 1)).
    list packing.audulus
    561K
  • @Drewyeah - does FFT have to be a node, or can it be a module? Also, that's what I was talking about in the other thread about having an arbitrary number of inputs and outputs - it's coming :) - (i.e. unlimited lists in a poly wire.)
  • @biminiroad- It would probably have to be a node like similar to the sub-patch node. In Max it works like a special type of sub-patch that gives you control over the frequency domain of the audio signal that is passed into it. It looks and behaves like one sub-patch but it's actually a number of sub-patches slicing the audio up over the frequency spectrum. If there are 200 slices there are actually 200 sub-patches each affecting a different frequency. Anything you can do to the time domain (ie amplitude) you can do to the frequency domain.
  • @DrewYeah no, I get it, I mean, but does it have to be something that Taylor programs or can you or someone else make it with the ingredients you've been given? IMHO, Taylor should only make a new node when it's something that's purely impossible or really inefficient to do with what's already there - like, for example, we'll eventually have a vector draw node (who knows when), and that's just impossible to make with what you've been given.

    Or like the new RGB LED - you couldn't have possibly made that on your own. That's what nodes are for - elemental stuff. I might be wrong, but I mean, even if you don't want this thing to be "module sized" per se, it can still be a part of the library, and be smaller like one of the Vias.

    This sounds really cool - would love any video info people think is a good thing to check out!
  • Background Audio in Os X version when working with Audulus "Stand Alone".
  • On the topic of Vias, there's a concept that has always seemed very rational from the early modular synths called "Normals". If you look at the way an ARP2600 or Korg MS-20 are wired internally, a bunch of what would be considered normal connections are already made and don't require patch cables. So a normal signal flow would connect an oscillator to an envelope generator to a filter to an amp, and if you don't add any cables, this signal flow exists. The magic happens when you want a different signal flow, and the various patch points will break the normal connection when you plug in a patch cable, and use the patched route instead. So you get the best of both worlds: a rationally pre-routed synth, with the trivial ability to re-route at will using the patch points if you so desire. From a complexity standpoint, the Normals serve to clean up the interface because they're internal to the modules, so you don't see them, and they allow you to provide a working modular synth for the rookie without wires running everywhere.

    In the context of Audulus, it would be cool to be able to mark a connection as Normal, then have a global option to Hide/Show Normals. Logic at the In/Outs would have to determine whether to use or override the Normal connection if the user adds a different path. Especially as you move to more standard modules, you could actually piece together a Minimoog, ARP, whatever with pre-built routing and intelligently selected patch points, while maintaining a clean interface.
  • @JohnInBoston yes they're electrically called normalized switching jacks - Taylor and I have wondered about how to implement this for a while. Nice suggestion! Will powwow with Taylor about this - it also has to do with the problem of releasing CPU when its not necessary to keep evaluating a point (say a 0 value off an expression node). Tough to pull off but good to know Im not the only one out there than wants normalization.
  • My main request at the moment is a bigger keyboard with more option. The one in ios Thor is a perfect exemple.
  • @shogun5000, that's good feedback. Thanks!