Feature Request Megathread


My buchaudulas patches are more than one MB each. It would be nice if presets weren’t just copies of the whole file. I agree that it is tough to come up with a scheme that survives major architectural changes.

I think there could be a strategy of being able to designate for individual knobs, sample/holds, trigger toggles and input/outputs that they be presettable. There may be some elements you would choose not to be presettable. As long as Audulus stores unique ids for elements, I’d think it would be able make such presets immune to minor architectural changes.

1 Like

You could certainly capture the state of the knobs and toggles etc. An Audulus patch file is actually a JSON formatted text file and every element of the patch already has a unique ID assigned. What is missing is a way to capture the state at a given point and then recall it. I suppose you could simply leave new controls that weren’t saved as part of the preset unaltered and ignore controls saved in the preset that were no longer present.I think that rather than trying to capture the state of every S&H node, we need some form of persistent storage other than knobs ad toggles. Something that can be written to. Preferably an array of some type.


Maybe I was too incomplete in my earlier comment. What I am suggesting is that saving a preset saves the states of the items you’ve made presettable and stores them as a data collection accessible through a “preset” widget that would let you recall presets that you’ve stored. Perhaps the widget has an input that takes a number of a preset to recall. Ideally, one could also give a preset a name, too.


I would say that the “snapshot” style is super important but is simply a matter of front end presentation. Audulus patch files are small, so it would just be a matter of generating copy’s of present state saves without overwriting. Then you hide the files so that they are bundled with the patch and can be accessed inside the patch.

You open a patch, you get a bunch of presets/snapshots in the menu. In synth culture, having someone write up a dozen presets for the patch you designed is always a nice compliment and definitely missing here.


Not all Audulus patches are small. Many of my Buchaudulus files are over a megabyte. My current library of 65 ‘presets’ (i.e. the files that I have saved so that I can use them as-is) is 40 megabytes and growing. I imagine that a real preset mechanism would use an order (or orders) of magnitude less storage.


New MIDI node type: Pad
This would have assignable MIDI note, channel, and velocity.

1 Like

I would love two random related features:

  • A Random node with a seed of -1 or maybe would use a random seed. I use Random a lot in little modules and find that I often need to change the seeds in copies to make sure the output values aren’t co-ordinated.

  • Would love for there to be a rand function available in expression nodes.

1 Like

You don’t need to use negative values for random seeds - they’re all as random as one another, and going negative wouldn’t be more random.

The solution I came up for the future is to have a date/time node that you can plug into a seed input of the random node. That way no matter when you open it up, it’ll have a new seed.

However, there are situations where you want something to be random yet repeatable, so I don’t know if it’d be desireable to randomly assign seeds to all random nodes whenever you open a patch.

This would be nice - perhaps we could just get rid of the random node and make the expression rand(x) where x = the seed.

1 Like

Hi Mark,

I must not have been clear in what I was suggesting about random seeds. I was proposing a new convention by which -1 as a seed is treated as a magic value that means: choose a unique random seed value at start up. That way, you could set the seed value to -1 for any Random nodes that you wanted to be guaranteed a unique seed value.

I was suggesting -1 as a possibly useful token since it wouldn’t be normally used as a seed value. But 0 would work, too. It is just a convention meaning ‘I’m not specifying a seed value, please seed yourself uniquely’.

The problem with using datetime values for seeding is that depending on how things were initialized you might still end up with random nodes seeded by the same datetime. I often have 20 or more random nodes in patch that I want to be uncoordinated.

You mention that there are times you want random yet repeatable seeds. Understood. That would still be possible with my suggestion. You would use a normal seed value as you do today. You’d only use the ‘magic seed’ when you want to guarantee unique seeds.

Another possibility would be random nodes with no seed specified, using their unique id to generate their seed.

If one has rand(x) where x is the seed, it would be nice if there were a way to easily generate a unique x for the cases where you want to guarantee that you are using a unique seed value.

Anyway, just some food for thought.


That would be super cool!

There are a couple of workarounds for this. I find using sine functions with coprime angular frequencies to create derivative random values to be effective most of the time. That way I only have to set one seed per module and the rest sorts itself out.

one random becomes eight randoms.audulus (16.5 KB)

Another approach is to use inputs from hardware devices and use the sine function again to fold the signal into noise.


@robertsyrett: i use that clever technique you came up with for simulating multiple seeds – but that only works in patches where the random nodes are in the same module. I have a lot of little randomizing sub-patches scattered throughout some of my big patches and it isn’t feasible to use that method.


That’s a neat idea! I didn’t understand that at first you’re right.


I like that idea!

1 Like

Related to that idea–the random node generates uniformly distributed random values. How about a built-in function to simulate a normal distribution, such as the Box-Muller algorithm, as implemented by stschoen in his normal distribution module.

1 Like

I think Taylor might be less inclined to implement that since it’s something you can do with the Audulus nodes you’re given and wouldn’t be much more efficient if it were to be implemented at a lower level. The other stuff is something that wouldn’t be user-buildable with the nodes available. Good thought - just don’t want to explode the number of functions you can do in the expression node past a certain point - you’ll start to get into cryptic Max/Pd ~abbreviatedCommands


Had this idea today. Sometimes I want to copy groups of patches to a certain multiplicity. Instead of copy/pasting manually, which is tedious, I have three ideas:

  1. A copy menu option with a number input (not sure how the input would work)


  1. a special Copy Node with an output where you set the multiplicity (default 1) and connect its output to any input of a patch you want to copy. It copies and disconnects immediately.


  1. A button as part of the interface. You can change the number on the button. Select what you want to copy, then tap the button.

Have you tried copy, paste, move, group, copy, paste? You can get an exponential number going pretty quickly. I suggested to Taylor a while back a method for creating knobs and lights where you could create them in groups by dragging them in rows/columns to make an array. Can you give me an example of what you’re copy/pasting so I can visualize what you’re doing?


That’s what I do usually. Unless I need a power of 2 I have to use extra brain power to figure out what to group. Its not overly difficult but could be easier. If I could get 12 copies at once in a neat column I think thats considerably easier.

1 Like

Please please please (if it isn’t too difficult), make there a way to make patches read-only. Sometimes I just want to open a patch to view or identify what it does. Then I lose track of where I was or what I was doing due to distractions, and when I come back, sometimes I have ended up wiping the slate clean to start a new patch over what was a experiment that started in the one and only copy I had of certain patches I had not shared (there is no backup in these cases). So by the time I realize I have patched over what should be a hard copy, I am unable to ‘undo’ the changes made to revert back to the blank slate and then bring back the copy I didn’t mean to kill. I think that would be useful, and I know it would save me from myself, quite a bit. Thanks! :slight_smile:


I would second that. I’ve gotten in the habit of duplicating patches before I start editing them and then working on the copy.