Feature Request Megathread

It would be useful to have the ability to have more lock options.

Feature Description Icon Lock
all no changes to patch all unlock
freeze items do not move freeze unlock
resize items do not resize resize unlock
wires wire connections
do not change
wires lock
subpatch remain on top
patch level
subpatch unlock
knob knobs will
not move
knob unlock
trigger trigger will
not change
trigger unlock
keyboard keyboard will
not receive MIDI
keyboard unlock
MIDI disable all
MIDI input
midi unlock

Can you explain this a little more? Are you proposing lock modes for each feature? If so, why a lock for keyboard?

The locks are for all combinations of user input. The all would be if you have a patch that you don’t want changed at all. For the keyboard you may have a setup where you want the Audulus patch loaded but due to an issue, you may not want to have it receive MIDI until you’re ready to switch to it because you’re playing another instrument or app with the MIDI source. For knobs and/or triggers you could have a situation where you have the settings exactly how you want them for a particular setup (e.g. an effect patch for a track on a song) and you don’t want them to change. For wires, you’ve got a complex patch and want to use multiple controls but don’t want to disconnect anything.

I’ll also add MIDI, freeze, and resize to the table above so you don’t inadvertently resize the patch elements or move them around when you don’t want to.

You’d also have the option to save specify your lock settings in a patch, subpatch, or for a patch file. Once again this is to give the user more control over inadvertently changing things they don’t want to change.

1 Like

MIDI support for rotary encoders. Most send CC with 127 for up and CC with 0 for down. At the moment there’s no way to capture this. Of course if we get a general purpose MIDI node it would be easy to build something


I would love to have a knob and trigger that could be adjusted with an input. The current knob can be overridden by a modulation input, but not adjusted. The trigger can’t be modulated at all (other than by MIDI). If you had a way to set the value of a knob or trigger you would be closer to implementing a preset system.


Well no really convenient if i’m making a new patch from a preexisting one
the duplicate option that load a copy can be really confusing and make Audulus bug
if the original patch is CPU heavy


Just regular save and save as. That’s what I and probably many others are used to. Save and save as have worked well for literally my entire life. There is no upside to reinventing the wheel.


I guess what I’m asking is what would Save As do for you that Duplicate isn’t already able to do? Duplicate is basically Save As except if you want to rename it, you just have to do that in a separate operation.

Are you saying if you duplicate the patch while it’s not open? I think perhaps you might be confusing copy/pasting the entire patch within the patch as what I mean by duplicating. I mean the Duplicate function that comes up in the file browser after a long press on the patch file.


Sure, but what does Audulus do then when you close the patch? If it didn’t auto-save, if it or the iPad crashed, you’d lose your work.

Where would the menu go?

What function isn’t being fulfilled by Duplicate + Rename that Save As would correct?

Asks if you want to save, I rather liked that about the PC version.

I think the common solution is that the patch autosaves to a temp file. Like with the digitakt or korg gadget, it will save whatever I’m working on when I turn it off or close the app, but I have to actively save the file before it overwrites the previous version.

A corner.

It’s what I prefer, that’s why this is a request. Having to ‘duplicate’, ‘rename’, and usually also ‘move,’ is many steps when it should be one, which I think is why ‘save as’ is so common.

1 Like

I can see this being a good feature add - I’ve actually accidentally exited patches when not meaning to by pressing the button in the upper corner. Especially during a performance, having a dialogue box that comes up and asks Save & Exit or Cancel would be handy.

But so imagine we have a Save As function. It would take the same number of taps as Duplicate + Rename.

Proposed Save As

  1. Tap on File Menu you’re proposing
  2. Tap Save As
  3. Rename File, then save

Current Duplicate + Rename

  1. Exit patch you’re working on.
  2. Long press and select duplicate.
  3. Long press new file, Rename

When you’re saving as to a new location, you’d have to make as many taps to do move in that menu as you would in the current menu.

So at best it’s a wash for number of taps. It might be marginally faster since you don’t have to long press, but the question ultimately is this: is it worth the dev time that could be spent on something else?

1 Like

That’s a bacon-saver!

on my desktop, there is considerable lag between the separate menu options, since renaming and moving both take a few seconds to load.

That I don’t have an answer to, I don’t know how long it would take to change things. But obviously this isn’t a deal-breaker for me, not even a pet peeve. This is something I find quirky in a not so great way.

1 Like

Exactly what i had in mind, that’s one of the reason why the workflow in Ableton feels so natural,
Temp files are here to save your modification but if you dislike what you just did you can simply close the patch
but if Audulus crashes, then you got a new ‘untilted’ project that appears when you re-start audulus
and then you can decide to save it or not, nor save it as… another version

it’s simple, easy and allows you to have a total control over your patches


1 like @robertsyrett is saying, there’s just no way to do that live
2 even in a studio mode, it kinda ‘take you off the vibe’ you’re into


i dunno but even if i’m not a programmer, i’d be surprised that
there’s no pre-built libraries that allows you to implement that very quickly


It sounds like a better feature you’d want is to

  • Bring back infinite undo. The history is currently cleared when you exit a patch. This had to be done to solve a significant problem with the files, but it might be able to make a comeback when Taylor has more time to work on it.
  • Have a history browser, rather than needing to press undo. It could be a slider that would step backwards/forwards through states as you browse. That way you could get it back to the state you want.

The thing about feature adds is that for Taylor to want to work on them, in my experience, they usually have to meet these two criteria

  1. It should be unique. If there’s a suitable workaround that’s not too onerous, then the likelihood of it changes going down. For example, there are building elements that could be more CPU efficient if they were turned into nodes, but Taylor’s not so interested in adding nodes if you can already do their function by combining other nodes.
  2. The balance of easy to do vs. the value it brings to Audulus. @Nomak - there’s rarely ever a drag ‘n’ drop solution with code with Audulus unfortunately. Even if Taylor makes a new node with some open source code it takes days to add it into Audulus.

I understand that the ‘creative’ part of the software should be unique. And it already is
but basic functionalities is really what make (especially new) users feel comfortable
and with the plethora of tools out there, the user experience is really not to be underestimated imo

like @robertsyrett was saying, when it comes to basic patch
management there’s really no need to reinvent the wheel

You and Taylor know the software upside down
and i’m afraid you’re sometimes forgetting to have the end user in mind
will the ‘duplicate’ option make sense to a new comer ? i’m not sure of that.

1 Like

I see your point - I’ll talk to Taylor about this at our Monday meeting.

Perhaps the solution is not a separate menu but when you go to exit a patch you have these options:

  • Exit and save
  • Save as
  • Exit without saving
  • Cancel

In my defense though, we do have the users in mind always - that’s why this thread exists after all to get feedback. It’s just that every feature request requires time, and usually a lot more time than you’d expect.

It’s got to be understandable too if there’s already a way to do something then adding an alternate way to do the same thing has to have a good reason right? The thing that convinced me that this would be a good idea is not that people are used to Save As, but that you could save as you work without exiting the patch, which is a convenience.

Interesting, why not “Exit without saving” on top of that ?

1 Like

Yeah I meant to add that, good catch!