Feature Request Megathread



Oh, what i meant is: I know you guys care about it, but sometimes, when you know your way
around too much it’s easy to forget that people don’t !

And yes, i get that redundancy is a waste of time for you and more confusion for the users


This would be a significant improvement and be consistent with the way most users have used apps and programs for the last several decades. For new users it’s particularly upsetting to be working on something and to lose work.

In the case of Audulus, a new user can load in a patch from the forum, try to understand it, alter some of the patch, become totally confused, and just want to cancel and start over. When they do that now, they’ll discover they have to go back and download the original patch again.

There are enough new things in Audulus to get used to without alienating people by having non-standard file saving options.

People who are used to programming might find the current procedure annoying though not a deal breaker whereas people who are dipping their toes into programming will be more significantly impacted by it.

Adding these save options would be a good investment in and part of widening the base of Audulus users.


By losing work, do you mean just overworking a patch you had sounding nice and then not being able to get it back to that point, or losing the file?

The Files functionality that we integrated to Audulus is new to iOS 11, so it’s new for everyone, too. It would be more familiar if Files had been out for years and you’d seen it integrated into more apps.

I’ll talk to Taylor about it on Monday.

Also just so we’re all on the same page, any feature request you make that is accepted will probably have to wait until Audulus 4.

After working on MIDI out and a few other minor things here and there, we need to switch over to start working on developing features for 4 so it can roll out sometime before the end of the year (hopefully).

That said, Audulus 3 will still have plenty of updates between now and then just through the Module Library alone, as well as online documentation.

This is all to say, @nomak and others who want this feature on iOS, you should start using the Duplicate + Rename function now because I’m not sure this is something we can just drop this feature into 3 with a couple hours of work.


The file handling in Audulus is largely managed by the operating system. The Audulus app itself actually does very little of the work. For both iOS and macOS, Apple moved away from the earlier “open, save, save as” paradigm several years ago for a number of reasons. On iOS an app is “backgrounded” when the home button is pressed. The expectation is that when the user reopens the app, it will be in the same state. However while the app is in the background the OS can terminate it at any time if the OS is low on resources. If this occurs the app has no opportunity to interact with the user. With the traditional file handling approach what action should the app take? Save the open file or discard it? What about when the unit shuts down because of a low battery? The introduction of cloud storage and the possibility that multiple devices might access the same file made this problem even more complex. The file handling methodology used by Audulus is similar to that used by most iOS applications. Since macOS applications are not as tightly controlled you will find a wider variety of approaches, but Apple’s own apps follow this same approach. In order for Audulus to be available in the App Store for iOS it must be approved by Apple and one of the factors used to make this determination is adherence to Apple’s Human Interface Guidelines. From the current revision:

" Instill confidence that work is always preserved unless canceled or deleted. In general, don’t make people explicitly save files. Instead, save changes automatically at regular intervals, when opening and closing files, and when switching to another app. In some cases, such as while editing an existing file, save and cancel options may still make sense for the sake of confirming when the edits are actually captured."

Taylor could potentially add a Save/Cancel option when closing a patch and remain consistent with the guidelines. In this case Cancel would still exit the patch but would roll back the changes made since it was opened whereas Save would commit the current version. To make make a more drastic change than this would involve considerable work and would risk App Store approval.


As @stschoen mentions, iOS handles the auto-save. I’ll add that it’s hard (perhaps impossible) to get iOS to do manual saving while still using their convenient document infrastructure. Even Revert is difficult because the auto-save can happen before the document is closed.

Implementation constraints aside, I think auto-save is actually the right way to go, but we need something on top of it like presets/snapshots.


Yeah, you need presets. Part of the fun of sharing a synth design is having other intelligent enthusiasts make a preset bank. I would definitely put snapshots ahead in priority of overhauling the graphics.


What graphics overhaul are you referring to? If you’re referring to the icons, that’s not done in the code - I’ll be adding them in the patches themselves.


Would love to see ‘Save As’ come back to Audulus… When inspiration strikes the last thing I want to think about is file management…


Maybe a “snapshot” button that creates a state within the file that you can go back to? Would both act like a preset and an anchor point: you have your patch sounding great, you snap shot it, keep working on it but then overwork it a little, bam, you’re back at your good starting point.


I like the idea of a pop-up when you are about to exit a patch regardless as it safeguards accidentally exiting a patch during life performance.


Personally I would like to see both a “save as…” type option implemented as well as a preset bank type menu. But I suspect this is challenging to do because in reaktor blocks it is easy to accidentally save a snapshot of one module but not save a master snap of the whole patch. People have been complaining about the reaktor snapshot system for years.

At the same time it is nice to be able to bundle presets with single modules when you share them. I do think that many people, given the option, would choose to take snaps of their patches as they work, knowing they wouldn’t have to worry about loosing something good. Also, if you are playing live and you get mixed up, potentially you could just use a snap to quickly regain a patch.


Audulus wouldn’t distinguish between a module and a patch. I’m assuming this snapshotting feature would snapshot the entire patch file, not a portion of it.

So the Save As is actually more of a problem than doing the snapshot/preset navigation because of the way the iOS file system works, as Taylor explained above.


Well if you can do snaps, then probably the “save as” on iOS isn’t that crucial at all. I have to say, I really appreciate this app and the people involved and I hope that the suggestions I make are not taken the wrong way. Everyone has done a fantastic job and I am totally impressed with what I see, and have felt quite welcomed around here. The new forum is really nice and I look forward to watching it all develop.


What Paulinko said. :slight_smile:
AND, OR, XOR, Shift (left/right, number of steps), Rotate (left/right, number of steps)

While I would be happy with unsigned bytes and words (of maybe 16-64 bits), maybe others would like signed numbers as well, in which case you would need to distinguish between logical and arithmetic shifts.


I’ve been interested in this kind of thing for a while but never really known where to start. What do these bit shift operations let you do to the sound? Is it simply distortion or can other things like filters be done, I have noticed these used in some DSP code written in C but all this is entering the realms of comp science of which I am not too familiar, if anyone has any pointers or links to further reading that would be useful


Another feature I would like to see are tooltips for controls, so if you hover over a dial or button some text pops up explaining the control…

Personally I find a lot of the bundled library quite inaccessible because of the time it takes to figure out the UI’s… it all looks very nice and I respect the vast amount of effort it that has been put into it, however the controls can appear somewhat cryptic… tooltips would solve this for me.

(another factor is that I zero experience with eurorack so perhaps that doesn’t help either)


We’re working on a feature where you’ll be able to tap the module and go to “info” and it will show the module in the http://docs.audulus.com/modules page.

Also, the icons will eventually be standardized so they all just mean one thing rather than being a little vague.


Wow, I missed this, I have some catching up to do!


Tooltips on UI elements would be pretty cool, but not very practical on iOS. You could add a button next to the lock button which would show them all at once. Language would be another problem.


I think the new library is mostly free of eurorack clones. The most exciting things in the new library is the building section and the modulation section.

Maybe @biminiroad could do a live stream on some of the more unique modules?