From the original SynthMaker forum (2004–2014), with its members’ names and dates.
gregh ·
here are some random number generators for three standard distributions and a little routine to get the derivative of a float array.
this one is no good **** see update message below
http://stashbox.org/22077/distributions.osm
here's the good one
http://stashbox.org/22102/distributions_2.osm
but go to http://stashbox.org/22195/betaDistrib.osm
for a more useful beta distrib
Would be great if someone tested the distributions as I am not completely confident in the beta distribution
Greg
infuzion ·
I wish I knew exactly what I was looking for... I don't know the heavy heady math :/
gregh ·
The algorithms look fine to me but I haven't found a good stats package to graph the output up in so that i can check the distribution under a range of parameters.
the beta is a good one because it gives such a range of shapes
me being lazy really
gregh ·
okay, the beta disribution seems completely wrong
here is the algorithm from dodge and jerse "computer music"
so i've done something wrong, if anyone can correct this it would be great
gregh ·
more on this (below) - i have now implemented this three different ways and had the same result using the rweb online stats graphing mechanism, so I am a little confused as to what is going wrong. Basically I do not get the u-shaped distribution with a,b < 1.
Any help appreciated as this is a very handy distribution
gregh wrote: okay, the beta disribution seems completely wrong
here is the algorithm from dodge and jerse "computer music"
so i've done something wrong, if anyone can correct this it would be great
oddson ·
Hey Greg... the beta function math is completely over my head and I have no idea what the 'while' condition has to do with anything in this.
I found lot of stuff on the beta function on the web but I don't have the math background to work it out from scratch and there seems to be something wrong this this way of putting things.
The keyword 'while' implies an exit condition for a loop... but I don't see how that's relevant to this.
gregh ·
hi oddson - there is an implied loop in that i am generating a sequence of random numbers as seed to the beta distrib function. You are right about the "while " - when sum>1 the value is output,otherwise don't, keep reading in random numbers and wait until the next time sum is greater than 1
I probably should have written
if sum > 1 etc
but i have found another description so will try that as well
It's been so long since i did programming that I am not communicating it as well as I should
off to work now though 🙁
gregh ·
okay, here are the working distributions - apologies for the stuff ups
I've commented the code now so that those who deserve the credit get it and if there are any (more) errors I, quite rightly, get the credit for those
http://stashbox.org/22102/distributions_2.osm
- I've fixed the beta distribution, which is a very handy one as it gives that nice U shape as well as the standard ones
oddson ·
You still need to implement some kind of conditional loop so that the beta distribution keeps trying until it gets a result that meets the condition.
gregh ·
Hi oddson - the way to work the beta distribution is feed a trigger in until a number pops out. This applies to the other ones as well, althought they don't need so many triggers per output.
Clearly I need to explain myself better when I submit things, I'm sorry for any time I've wasted by not being more explicit
oddson ·
Well then you need a trigger loop mechanism as users will expect a new value to pop out with every trigger. 🙂
gregh ·
damn users - all they want is something useful 🙂
oddson ·
A "While" primitive would be nice for stuff like this...
i've made something using a gated ticker, but do you know how much cpu a ticker uses - it seems an inefficient method that i've used as it has the ticker going constantly
and yes, a 'while' primitive would be great, or at least a ticker with start and stop (which I think is different to a loop)
oddson ·
A 'While' module for the meanwhile...
while.osm
In the 'old days' you could have green event feedback loops but the devs have nixed this to avoid users seizing up their systems.
gregh ·
thanks
gregh ·
well it could just be that i'm not that good at making components or it could be a higher quest for perfection driving me to repair the sins of my past -regardless, here is a more usefull version of the beta distribution
http://stashbox.org/22195/betaDistrib.osm
infuzion ·
I don't think you need the Bool Or. I'm not sure, but my instinct says to make the Trigger Switch to be the last thing connected to the Float Less.
What is the big reason for these things anyhow? I'm still trying to understand...
gregh ·
thanks for the advice - i'll try that out
there is no big reason - just that these sorts of distributions are used a lot in algorithmic composition and S|M only provides a uniform distribution.
If you don't do that sort of thing then this is of little use - and has taken up more forum space than is sensible because I'm only starting and struggling a bit.
This might even go down to the level of sound design, but I'm not familiar enough with S|M yet - for example if I wanted to vary the attack time of an ADSR envelope would I do that with green data or stream data?
infuzion ·
"algorithmic composition" ah, that makes more sense to me. That way, you can herd the bulk of the numbers into a sub-range, while having a few numbers jump out of the pack.
gregh wrote: ...if I wanted to vary the attack time of an ADSR envelope would I do that with green data or stream data?
Yes:
1) Green for occasional changes (perhaps a few times a second)
2) Stream for constant changes (connecting a LFO (oscillators are already stream, no reason to switch back & forth) to the Attack)
If you're not sure, you'll have to test:
1) In SM: with the internal CPU & Window's CPU meter
2) In a host or 2 or 3; better if the host has a CPU meter also
gregh ·
infuzion wrote: "algorithmic composition" ah, that makes more sense to me. That way, you can herd the bulk of the numbers into a sub-range, while having a few numbers jump out of the pack.
gregh wrote: ...if I wanted to vary the attack time of an ADSR envelope would I do that with green data or stream data?
Yes:
1) Green for occasional changes (perhaps a few times a second)
2) Stream for constant changes (connecting a LFO (oscillators are already stream, no reason to switch back & forth) to the Attack)
If you're not sure, you'll have to test:
1) In SM: with the internal CPU & Window's CPU meter
2) In a host or 2 or 3; better if the host has a CPU meter also
great, it only gets better 🙂
Wrote something here? To have a post removed or your name hidden, write to [email protected].