Well, I’m just a user thinking out loud.
That sounds like a good idea. I would suggest that no matter what, it’s possible to use it in realtime.
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):
Scripting and blue:
http://www.csounds.com/stevenyi/blue/userm…ml/ar02s03.html
Why use scripting:
http://www.csounds.com/stevenyi/blue/userm…ml/ar02s02.html
Usage ideas:
http://www.csounds.com/stevenyi/blue/userm…ml/ar02s06.html
NB: Note that blue doesn’t call scripts in realtime, but before playback, somthing like I suggested in 1) above.
Somewhere between +1 and +255 for me!
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.
That could be achieved with
, you’d have the best of both worlds 
But then would one see see the notes actually in the pattern to be able to manipulate them further if need be?
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.
Sort of off-topic, but velocity device->lfo device->lfo device->trackvolpan theoretically does the trick for one channel.
Problem is that velocity device has a small attack time.
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.
On the upside, you’re actually making music.
ducks
Seed = 0 for completely random (using system time as a seed for every probability)
Seed = 1-255 for predefined seed
well, I had the same idea today, I searched and it was already proposed 
… The probability column would rock!!!
I could pull this off with an instrument trigger metadevice as well
YES PLEASE!
Cool idea, sorry for bumping but I just came across this as somebody else bumped it. Isn’t it doable now with a random LFO pointing to either 0.0 dB or -INF dB on a gainer?
edit; I just tried it and my combo of VelTrackers LFOs and Hydras with a gain at the end seem to be much too slow 
- probability selection kind of works, but the whole set of meta devices is to slow to effectively kill a kick before you can hear it sound (short impulses come through). Fun idea though. A probability column would be realllllll cool (but so would pitch control in the retrigger command 
)
here’s the chain though… link
The main complaint is that random lfo won’t trigger an attack. A stack of lfo’s or carefully planned envelopes could work though.
Necro thread: I’m posting in one.
I feel like this issue comes up every 6 months for some reason … Twinbee is so spot on though - generative composition at the editing stage is exactly what you want to do. How much would it suck to be like “hey come listen to this track! … uhh it sounded better the 3rd time I played it when the notes lined up in a certain way. Let me play it a few more times and see if I get lucky.”
Also, editing-stage generative note data is very easy to facilitate with lua scripting. I did a proof of concept a while back where all sample choices, notes data and effects were non-deterministically generated by a script:
http://soundcloud.com/revo11/renoise-algorithmic
Just messing around in this example, but the lua capability is there. ‘Generative’ live performances are a different story, but I still don’t think the probability column is the best way to approach - it’s too blunt of a tool. People are just fixated on that because there was a buzz tracker module that happened to have the feature.
Was there? I’ve seen it in other places personally. The tracker I used to have on the Sony PSP (can’t remember its name) for example and I think LSDJ or similar program on the Gameboy, plus a few other programs usually of the step-sequencer or drum machine variety. Definitely more wide spread than just being seen by people on some Buzz module! And I still think it has a place for use in live playing personally…
It’s pretty vague in my memory cause I haven’t touched buzz in about 10 years, but I remember there being some module that supported it. Don’t think it was the basic tracker module though.
This is one of the interesting features I wish Renoise had, it can be very useful for glitching, evolving arps, etc.
The way Sunvox implements the “note probability” is through effects in the effect column (0020 for random triggering only, or 0021 for random triggering and random volume up to the parameter value percentage) in which the parameter they take is the probability for that note to be played at all.