Feature Request Megathread

feedback
megathread

#1

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.

To vote on features already requested that you want, use the Feature Request Megapoll.

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 :stuck_out_tongue_winking_eye:


Purpose built iOS rack
#3

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!


#4

Bring Windows version into the 21st century!


#5

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.

Do you have some suggestions for particular ones?

That’s in the works right now! :slight_smile:


#6

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.


#7

Sounds great!

The video in that post you linked above is pretty amazing.


#8

Add SVG import to iOS version of Audulus.


#9

Definitely coming at some point :slight_smile:


#10

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


#11

:sunglasses:


#12

It might be nice for Audulus to run on a separate audio device, like how I can choose in Ableton whether I’m using the ES-8 or my Roland i/o.


#13

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.


#14

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?


#15

Multitouch.


#16

The search term you’re looking for is ducking. You might be able to do it automatically with a plugin, but the standard way requires manual editing.


#17

Save as…

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 !


#18

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


#19

Not only that, but duplicating the patch, renaming it, and then moving it is not a good workflow when compared with ‘save as.’


#20

What would the UI here look like? How would it be different or more efficient than just duplicating the patch?

It sounds like you don’t want a Save As so much as maybe a dialogue box that asks if you want to save when you close?


#21

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.