randomness can still be musical if its controlled in the right way, although if its to emulate human feel/variation on grooves there’s a problem because the sound of a real high hat is not randomly different as such.
however aesthetic issues aside i can see how it would be useful. but i’m not sure if a pattern effect command would be the best way or not, because next you’ll want random timing aswell, random pitch, random note. surely it’d be better to have all these things and more in an instrument, no?
or maybe it could be done with an effect which controls amplitude in theory, like an LFO but with:
reset [x] on/off [x]
mute probability [-------I----]
delay probability [----I-------]
amount delay [—I--------]
so you switch it on and trigger it when you reach a note you might not want and set a value for probability. but if it works on amplitude long notes or notes close together would bleed together. maybe that would sound cool though.
probability column? you must be kidding…
how about a ‘free improvisation’ column that plays a random note matching the harmonies present at the same pattern row?
Well, the probability thing could be done with a random lfo attached to gain plus a noise gate that removed everything below a user-defined threshold, unless that’s the second thing you said you didn’t want?
I dunno, I’m just rewiring to Live which already has a couple of aleatoric things built into it (a random midi device and a way to set clips to trigger according to user-defined probablities). It is a useful feature (though I don’t know how I would use it in Renoise which has a much more linear workflow): I use it to trigger related sonic material randomly under certain musical parameters (e.g. randomly skipping through a string sample every 16th note), and then I go back and chop out the bits that are useful to my composition.
If you wanted to get an analogous feature in Renoise, it would be a pattern randomizer (which Renoise may already have for all I know…)
I’d prefer to have more control than that. Assigning a simple probability of triggering a note would allow you to define complex sub-melodies in advance.
I should point out right now: I’m not talking about randomly choosing pitch. Simple whether or not a note you’ve placed gets triggered.
To me this is a can of worms. I’m really into algorithmic composition, even live I perform with a home-brewn chuck based system that makes all kinds of guided decisions.
I cannot see any sleek way to start integrating that kind of extreme flexibility this ultimately can lead to into renoise except this: Make it possible to have a column be generated from a command line call. Both calls on each line (with line number as argument to the external tool) and calls on every new iteration of the pattern would be cool. There probably needs to be a “call X ms before the result is needed in renoise” option to compensate for slow computing from the commandline tool.
I would personally write a python script for generating columns, starting simple, build a library of tools and end up with something generic that could be used (by or others) for just about anything.
I realize my proposal is quite geeky and some (most?) people wouldn’t know what to do with, but I think it’s the ultimate flexible solution that doesn’t clutter up renoise with stuff that can’t be generalized in the first place.
I hope the general outline of my proposal is clear enough to derive a few comments
wasn’t there something mentioned about using scripts in Renoise for a future update long time ago (in a thread about a renoise api)? It was mentioned that it is basically already implemented for bug-hunting alpha testers, but public implemenation could open all kinds of possibilities, including the stochastic pattern generation discussed here. searches board
I think he was thinking that it would be an aleatoric song generation tool rather than something that works in real time.
It’s not necessary to have a command-line interface for that; you could use any tool that can automate the UI (AutoHotKey springs to mind) to randomly enter information into a pattern.
Because you’re worried that the external tool doesn’t make it in time before the result is needed in renoise? I (of course) agree that this could become a problem. Possible solutions:
Don’t actually generate in realtime but call the scripts before starting playback. This could lead to a small wait between starting the playback and the playback actually starts, but it could be acceptable.
Have the column contain normal music information, and only use the result of the script when it’s done. The static content could be thought of as “backup” information. This could lead to problems for instance with the scripts information kicking in before a note off so a not would hang. Combined with the “call script X ms before it’s output is needed” this could work out. Also it could be possible to add s switch (renoise gui) that would use the whole of the static column data if the external tool doesn’t make it on time.
The worst case response time of a script is by nature not possible to predict, for instance someone might write an eternal loop. But with some clever handling of these cases (some ideas mentioned above) I think this is acceptable. The open ended nature of this opens endless possibilities, including some dangerous ones.
Absolutely nothing. I just extrapolated the idea. My initial thought when reading your post was that a lot more stuff besides probability would be interesting, (can of worms) and implementing all the feature requests in a clean way would be mess if done ad hoc, and a huge/impossible task if we should foresee all cool possibilities beforehand.
Just for the reference, I probably mention all this because I’ve been working alot in Blue (graphical environment for the text based mother-of-softsynths Csound). Since csound is entirely text based people soon got tired of entering text for every note in their compositions, so various score generators were written. Blue allows score to be generated in various ways, I mostly use the embedded python engine. See for instance (from the blue manual):
If we are going to have randomness, I think it would be nicer at the editing stage, rather than on playback (I already moaned how indeterministic VST instruments can be sometimes). In other words, a column, or selection may be filled on request in a random manner. This means one can get to ‘cherry pick’ the best one and keep it when/if it turns up.
Well, you would - if the probabilities were light up or greyed out, depending on if that probability triggers at that position or not. So when you change the seed, you’d more or less instantly see how the pattern changes.
But then you would get exactly the same resulting playback each time a sequence is repeated in a live set rather than subtle differences caused by the probabilities you have set.
