ForumsSoftware ← Random patch generator

I was sharing a patch with a friend today and seeing the "guts" of the patch in such a simple manner made me want to make a random generator. I've never made a program, but I feel like learning and this seems like it would be pretty simple, useful and fun.

I'm looking for some tips on where to start. What programs to use and so forth. I have taken classes on programming, but we used teaching software that is limited to learning concepts, but not building an application and also a tiny bit of c++.

The biggest hurdle will be coming up with an interface that isn't slower to use than Aalto itself. I'm making some sketches now, but I haven't seen many examples to get inspiration from. Is there anything people would want to see? That's relatively simple, of course ;)

How to even go about creating a gui is also what I'm most unsure about. Should I use Apples own x-code tools or is there something easier?

Here's what I plan on doing more specifically:

A gui where you can check off which aspects are randomized to "grow" your sound. If everything was random that would sound bad more often than not. Often you wouldn't even want to change many of the dials especially level and pitch. The randomization limited to a few aspects at once and loading in patches you already like to start should produce interesting results.

I would build the option to constrain the changes to further sculpt the sound. That is you could set pitch to only link to specific dials or release to change between 5 and 10 and so forth.

The only other task I'd realistically undertake I'm not even sure is possible within the frame works of aalto/osx. I'd like to be able to automatically copy and paste the patch into and out of Aalto. I have some ideas like sending specific randomized changes at certain intervals.

I like the idea of making a semi- abstract gui that lets you be expressive, but that would take a lot more planing. One step at a time. :)

Most of what I'm seeing in the text file is pretty easy to figure out. Only thing I am confused by so far is the patcher_input. There are 27 variables and I guess those are the various patch points? I'm just making really simple patches and comparing them now to figure it out.

Thanks in advance to anyone that can offer advice. Gonna go get familiar with xcode now.

Well that's a super cool idea!

Since you just want to make a text file as your output, I wouldn't necessarily go with Apple's XCode tools unless you really want to learn them or improve your C++. You can use an interpreted language that will be easier to work with. Javascript, Python and Ruby are all good examples. And you could turn any of these into a web app really easily.

You could also use Aalto inside of Max/MSP using the audiounit~ object. Some other folks are doing this, and I hear it works, within reason. This way you could make a Max patch that did the randomizing.

I hope other people will have more ideas, there are a lot of ways to do this.

The patch connections format is just as simple as it looks. No surprises.

I'm making progress and have built a few parts. I have a few questions. They aren't holding me back from building, but if you get a spare moment I would be interested to know what's going on. Thanks.

1) For some settings Aalto will allow a different input than is possible from the main gui. For example osc_waveshape maxes out at 0.899999976 but I can set it to 1. Sonically is there a difference? I can't hear one.... And of course I'd like the random numbers that go into Aalto to actually change the sound. :)

2) Aalto seems to do some rounding to decimal numbers that go into it. Do you mind sharing the rules Aalto is using? I want to keep things as random as possible, and not input values that will be changed to something else.

3) In general in Aalto values are 9 digits total, but there are exceptions for really small numbers. Is this correct?

I didn't know pitch could be any value. :)

I really underestimated all the different rules I would have to setup for the random number generators! It's overwhelming.

For anyone else that wants to experiment with Aalto's patch data, I made a text file that has all the options semi-organized and (hopefully) easier to parse. I tried to determine the min/max values, I named the patcher inputs and I printed the directory tree of the scales to text for easy access too. "-" for range and "," for unique values. I might put the info into a spreadsheet in googledocs eventually, but who knows.
http://www.mediafire.com/?b1fodznhs4vz01k

Hi,

Think of Aalto's synthesizer and its UI as two different things. They are actually two completely separate pieces of code---when you have Logic's generic view running, for example, you are not running the Aalto interface at all.

The values you see in the XML are the ones stored in the synthesizer, that Aalto is really using. The values you see in the interface are rounded so you can manipulate them easily. But Aalto saves the internal values.

This may get confusing because of floating-point vs. decimal inaccuracies. Most decimal values do not have an exact floating-point representation. 1.01 for example is 1.009999... in floating point.

There shouldn't be a lot of rules to set up-- every parameter has a minimum and a maximum value, just make a random value somewhere in between and you should be fine. Again they are all floating-point internally, it's just that the display is different to make the UI most useful for each parameter.

I agree: This is a great idea.

But you seem to have dreamed up a really complex method for random patch generation that might take a while to fully realize. In the mean time, you might consider a pure random approach. Your GUI would just have a button and text output for the patch. Each value would have the full range (whatever that may be). Once you get this working (assuming you don't already have something basic like this), then you can start getting fancy.

As for the ultimate version, you might want to think about having classes of parameters, so that you don't have to treat every parameter completely separately. Each class would have a specific range and a particular kind of GUI to set the randomness. Once you have these basic building blocks, you can put together a GUI that allows fine control over the randomness of each parameter.

However, I tend to believe that 90% of the utility of random patches can be served by purely random values. Not that there isn't a great deal of utility to having a finely-tuned engine for creating controlled random values, but sometimes it's easier to click a button several times to skip past dud patches until something useful comes along. Then you can use the Aalto GUI to fine-tune the patch from the purely random starting point. In other words, why spend a lot of time on generating a controlled random patch when you can quickly jump through lots of wildly random patches until something sounds interesting. I tend to learn more from wildly random patches anyway, because they incorporate elements that I would not have thought of if I were trying to control the process in detail.

Another idea would be to put intelligence into your random generator. If a particular 'amount' knob has a random value, but no modulator is assigned to the input for that knob, then it's kinda pointless. So, perhaps some understanding in the random number generator about the interaction between modulation cables and modulation amounts might help create a higher percentage of useful patches. I think this might end up tying in with the classes of objects that I mentioned above.

Keep us posted on your progress, and feel free to continue with questions and ideas.