This is the Feature Request Megathread. If you don’t want to start your own topic about a specific feature request you have, then just add it in the comments below.
READ THIS BEFORE YOU POST
First, do a quick search in the thread and make sure your request hasn’t already been made. There is no need to +1 suggestions already made - that just adds to the clutter of the thread.
If your comment isn’t a unique feature request, or doesn’t add on to someone’s existing feature request, I will delete it. This is for my sanity when looking back through this thread and trying to actually implement the features you +1 so much
Binary! Simple and efficient nodes and/or operators to do bitwise manipulation. I know some people have implemented things like this using existing math and patching, but it’s not practical. And it would be so easy to add some operators to the expression node. Thanks for listening!
We’re exploring this for version 4. For example, the button is sampled as if it were a floating point 32-bit number, when all it really needs to be sampled as is 0 or 1.
Gates from logic and clock modules are also 0 or 1 except for the edge case of a gate height as it enters an envelope, which allows for dynamics.
In short, this is certainly doable and something we’d love to roll out sometime during Audulus 4.
Some deep analysis of one-line music programs I would like to have these bitwise operators for stack based music creation. The operators would be: &, %, |, <<, >>, and !. I’m not positive if those are all bit wise operators but apps like BitWiz on iOS use them and are based on the original work posted in the link above. Using these equations in a stack and outputting them allows you to create complex wave form patterns. It would be awesome to create a module to accomplish similar synthesis in Audulus.
It wasn’t really practical until iOS adopted the Files app and allowed more open access to the underlying file system. Now that it’s possible to browse SVG import shouldn’t be too difficult
It’s my understanding that when Taylor took out the ability to do that in an earlier version of Audulus 3, it made the code much simpler and easier to maintain.
In the future, once Apple fixes the bug with aggregate devices, you could set up alterate aggregates if you want to use these or those inputs with Audulus.
In the longer future, the ADC-DAC nodes won’t be limited to just using 1-16 - they’ll have access to all your I/O for plugged in devices, so you can select them from within Audulus.
Yeah, that aggregate device bug is a bummer. Fortunately I was able to change my soundcard to something better recently and I’m a lot less bothered by my current screen recording set up. But I can make it work all thanks to Ableton’s device management.
This is a little off topic but do you know if final cut pro allows you to sidechain voice over to background sounds?
sometimes i like to play around with my patches and end up ruining them for good
please allow us to ‘save as’ and also maybe disable automatic saving, it really is a pain in the butt
and a unnecessary constrain, it should only be an option !
Auto-save is actually a feature of iOS and macOS rather than something that is Audulus specific. Like you, I sometimes find it frustrating. I’ve gotten in the habit of using the duplicate file option before I edit a patch. That way I don’t overwrite the original. On iOS select the file in the file browser and hold until the context menu appears. Duplicate is one of the options. On macOS it’s in the File menu. While it would be technically possible to go back to the "Save As approach, it wouldn’t be following Apple’s guidelines. Don’t forget that Audulus maintains a pretty good multi-step undo list. On macOS there is also a Revert option in the File menu
The fundamental premise behind Apple’s current approach is that saving a file is a redundant operation. If you change something it should stay changed. Its a different mindset than the more traditional “load a file into memory, edit it and save it”. It does take some gettting used to but I don’t think it’s any less efficient in the long run. I will admit that sometimes I forget to duplicate a file before editing it, but that’s becoming less common in my case. I would like it if Audulus didn’t flag a file as edited as soon as you open it. It would be much better if the edited flag (and modification date) changes only when you actually made a change. Could be difficult since scrolling or changing magnification levels currently constitutes a change.