It would be useful to have the ability to have more lock options.
| Feature | Description | Icon | Lock |
|---|---|---|---|
| all | no changes to patch |  |
 |
| freeze | items do not move |  |
|
| resize | items do not resize |  |
|
| wires | wire connections do not change |
 |
 |
| subpatch | remain on top patch level |
 |
|
| knob | knobs will not move |
 |
|
| trigger | trigger will not change |
 |
|
| keyboard | keyboard will not receive MIDI |
 |
|
| MIDI | disable all MIDI input |
 |
|
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.
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.
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.
Save AsSave AsDuplicate + RenameRenameWhen 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?
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.
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
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
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.
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:
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 ?
Yeah I meant to add that, good catch!