David Clements

I've created a probability gate. Feed it a list of 20 floats into the left inlet, then put data into the right inlet and it will come out of the 20 gate outlets at the probability set.

In the patch below, the only bit you really need is [p probability_gate], the rest of it is just fluff to test its workings.

I'm also interested in anyone making improvements, i'm sure there's plenty of you that can improve on what i've done. Because of [urn], the maximum total of probabilities is 409.6, that could be improved on, and maybe just the mechanics of it generally.

Also the "clear" on the urn acts strangely. In the tester patch, banging the uzi the first time gets exactly the right probability output, it should then clear based on the [urn] fullfilling all its numbers, and do exactly the same on second bang of the uzi. But it doesn't, it's very slightly off. This doesn't really matter in normal usage, but it would be nice to get it perfect .

Probably (hehe) there is already a patch that does this better, but what the hell, i had fun making it!

toggle

loadbang

button

loadmess

metro

message

number

split

outlet

zl.rev

zl.filter

comment

gate

unpack

pack

zl.sum

inlet

zl.mth

zl.sort

random

prepend

incdec

flonum

counter

Hi Max users.

I've created a probability gate. Feed it a list of 20 floats into the left inlet, then put data into the right inlet and it will come out of the 20 gate outlets at the probability set.

In the patch below, the only bit you really need is [p probability_gate], the rest of it is just fluff to test its workings. 

I'm also interested in anyone making improvements, i'm sure there's plenty of you that can improve on what i've done. Because of [urn], the maximum total of probabilities is 409.6, that could be improved on, and maybe just the mechanics of it generally.
Also the "clear" on the urn acts strangely. In the tester patch, banging the uzi the first time gets exactly the right probability output, it should then clear based on the [urn] fullfilling all its numbers, and do exactly the same on second bang of the uzi. But it doesn't, it's very slightly off. This doesn't really matter in normal usage, but it would be nice to get it perfect .

Hi Max users.

I've created a probability gate. Feed it a list of 20 floats into the left inlet, then put data into the right inlet and it w

probability-gate-1

Here is a much simpler solution using whole numbers.

Also you should check out the [prob] object.

You can have state based probability with this object to create interesting sequences.

I.e. the probability of state 1 going to state 2 or 3 etc. This is called a first-order Marcov chain.

Also you should check out the [prob] object. 

You can have state based probability with this object to create interesting sequences. 

Ok, I see. This first one is a bit different to mine as it's constantly changing output regardless of input, rather than changing *when* it gets input data.

That is the nature of a gate, it has a state (open OR closed), once that state is established any amount of data can be sent thorough it. Maybe you are thinking of routing which can be used to address data to different channels. Either way it can behave exactly as yours using a trigger or join object. Here are both in action side by side, and an example of using route instead of gate.

Oh yes. good point. I see what you mean, it's more of a "probability route". Very elegant patching too. 

Oh yes. good point. I see what you mean, it's more of a "probability route". Very elegant patching too. 
Thanks!

I've tweaked it very slightly to input and output any type of data. 

Am i right in thinking that there's no limit to how long the list of integers could be. So long as you make an extra output for the route, it works right? So it could be expanded to 40 possibilities etc?

I've tweaked it very slightly to input and output any type of data. 


Am i right in thinking that there's no limit to how long the list of integers could be. So long as you make an extra output for the route, it works right? So it could be expanded to 40 possibilities etc? 

Nice work. Love it. I just tried making a route of 1000 outputs and it worked so.... yes in theory.

Actually, upon further testing, this isn't quite working. Two issues.

1, the amount of data going in doubles upon output?

2, Probabilities of zero are still firing a small amount. If it's zero, they really need to not happen ever. For some reason output 2 set to zero doesn't occur, but output 1 does. Weird.

See patch which demonstrates below. Maybe i messed it up with my tweaking, but something's going wrong here.

Update on this. It's only when you feed it bangs that it doubles the output. If you send an integer, list or symbol it sends a single output. Still trying to figure out why... And also not sure about the weird behaviour of output1

Further update. I think it's just that the [<= 0] actually needed to be [< 0] That seems to fix the weird behaviour of outlet1, but i'm still testing.

Actually, upon further testing, this isn't quite working. Two issues.

1, the amount of data going in doubles upon output?
2, Probabilities of zero are still firing a small amount. If it's zero, they really need to not happen ever. For some reason output 2 set to zero doesn't occur, but output 1 does. Weird.  

See patch which demonstrates below. Maybe i messed it up with my tweaking, but something's going wrong here. 

 Update on this. It's only when you feed it bangs that it doubles the output. If you send an integer, list or symbol it sends a single output. Still trying to figure out why... And also not sure about the weird behaviour of output1

Further update. I think it's just that the [<= 0] actually needed to be [< 0] That seems to fix the weird behaviour of outlet1, but i'm still testing. 

Yeah, that's fixed it. You can test its perfection by temporarily exchanging [random] for [urn], as that will not repeat any of the random numbers until they've all been used up, at which point you have to clear the [urn], but it demonstrates that the exact same probabilities entered are what gets output. So if you make probabilities (1 2 3 4 5 6 7 8 9) you get exactly those amounts out of the route, which shows that the system is working.

Still trying to figure out why bangs make it output twice though...

Good job. I am only getting one message out for each time I send a list to the patcher... are you sending the list and then banging? The patcher does not require a bang, just a list.

Hey Just for funsies I built a 1st Order Macov chain version where each of the route numbers has probability for the next state. You can build probabilistic sequencers with it.... fun!

it seems like [join] outputs if it recieves a bang, even at its cold inlet. That's just the behaviour of it. And that's what causes the double output when the "data" is a bang. 

Personally i don't want to send bangs to it anyway, so i don't care, but it could always be fixed with a [tosymbol] and [from symbol] at input/output if necessary.

I will check out the macov chain today :) 

Update: Checked it out. It sounds and seems very cool, but i honestly don't understand quite what's happening here. I've been doing something perhaps similar by data tagging the outputs, then using that to change the probability before the next "bit'' comes in. Any chance you could break it down a bit more? Cheers

it seems like [join] outputs if it recieves a bang, even at its cold inlet. That's just the behaviour of it. And that's what causes the double output when the "data" is a bang. 

Personally i don't want to send bangs to it anyway, so i don't care, but it could always be fixed with a [tosymbol] and [from symbol] at input/output if necessary.

I will check out the macov chain today :)  
Update: Checked it out. It sounds and seems very cool, but i honestly don't understand quite what's happening here. I've been doing something perhaps similar by data tagging the outputs, then using that to change the probability before the next "bit'' comes in.  Any chance you could break it down a bit more? Cheers

Join takes the argument 'set' to set an input without output so that would probably be the best way to stop bangs, you could also just select any bangs...

Every state of the route has its own list that denotes the probability of the next state.

Each route will have a list of 4 numbers that represent the probability of the next state in relation to the 4 possible states.

So if I save state 1 the list (0 100 0 0), then 100% of the time the next state will be 2.

Then I save state 2 the list (0 0 100 0), then 100% of the time the next state will be 3.

Then I save state 3 the list (0 0 0 100), then 100% of the time the next state will be 4.

Then I save state 4 the list (100 0 0 0), then 100% of the time the next state will be 1.

I then recall state 1, and receive 2, recall 2 and receive 3, recall 3... get 4, 1, 2, 3, 4, 1, 2, 3, 4....

So I have built a looped forward sequence using probability.

You need to store probabilities for each state so the total length of any full set is the number of states to the power of 2. So with these 4 states of 4 probabilities each I store a table of 16 numbers. I just used a table to store recall and edit this data, and represent the data on a multislider focused to the current state one is editing.

Here is an example of 5 preset sequences including the above forward sequencer...

Every state of the route has its own list that denotes the probability of the next state. 

Practical example:
I have 4 routes
Each route will have a list of 4 numbers that represent the probability of the next state in relation to the 4 possible states.
So if I save state 1 the list (0 100 0 0), then 100% of the time the next state will be 2.
Then I save state 2 the list (0 0 100 0), then 100% of the time the next state will be 3.
Then I save state 3 the list (0 0 0 100), then 100% of the time the next state will be 4.
Then I save state 4 the list (100 0 0 0), then 100% of the time the next state will be 1.

 So I have built a looped forward sequence using probability.

P.S. to kick it into gear just move the numbox below the metro....

Probability Gate