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.


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.


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.


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.


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!


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.


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