hello PD-brain..

i have this strange problem i can't figure out, maybe i just don't get it or this is one of the quirks of PD...

i'm working on a step sequencer. the sequencing bit is working as i want it to. no problem.
it has two settings, normal counting and random counting ... 1, 2, 3, 4, 1, 2, 3, 4, etc. and random (in the range of 4). i have a switch between them to select which to run. easy.

my problem is, the hratio that i put in to illustrate which of the steps are active, only works on one of the two settings.

i tried putting in a hratio for each of the settings and that works fine, but it'd be silly to have two hratios when i can have one.

i have a feeling i'm overlooking something really simple. does anyone have an idea?

https://pastie.iem.at/view/b0fa1761

buggy_step_sequencing.pd

thanks in advance,
BOB

Wouldn't it be straightforward to select the branch by the value of the radio?

working.pd

hah.. you people are amazing!

...and since you are so amazing, i have a quick follow-up question: how would i do so, in random mode, that it doesn't pick the same number twice in a row?

@NOISEBOB The first number is selected from four possible numbers, so [random 4]. After that, only one out of three possible numbers can be chosen, so [random 3].

To the result of [random] the previous chosen number + 1 is added and this is taken modulo 4 to spread the range to four numbers while avoiding the previous chosen number.

Another explanation: We have one number and we chose the following number as a starting point for our random number modulo 4. Since we only add 2 as maximum, the previously selected number cannot be reached again.

Result: No number is selected twice in a row and all numbers 0, 1, 2, 3 are statistically equally distributed.

working.pd

neat! there's also [urn] in zexy library... just another idea...

@toxonic But [urn] has a different functionality, as it never repeats a number until the urn is empty

@ingox said:

working.pd

very cool...

i see you changed pipe to delay.. is there any difference?
i mean, they both delay.

i'm not sure why i used pipe in the first place., tho..

@NOISEBOB You used [pipe] because it was receiving floats (numbers). [delay] is for bangs.
As the output goes to [0( it is transformed to "0" whether it is a number or a bang..... so it doesn't matter which you use......
David.

yeah, but this patch doesn't work like the one with [pipe] since the output of the radiobutton sets the delaytime of [del] (which are values between 0 and 3). you'd need to put a [bang( between it in order to get the desired delaytime of 300 ms.

yeh, i figured it out and set it back to pipe. it's a part of a much bigger project/hack.

http://pd.noiselove.net/PELLE8001-1.6.2.pd

@toxonic Yes. I should have looked at @ingox patch before commenting.
A bang inserted before [delay] would fix that if you want to use [delay] instead of [pipe].... in earlier vanilla where it didn't exist if I remember correctly.
David.

@toxonic That's true, i should have used [t f b]: working.pd

yes, this one works as expectetd. i thought, [urn] was, what @NOISEBOB was looking for... but to avoid direct repetitition of numbers, here's another approach... didn't think about statistics, but i guess, it does the job in most cases... working.2.pd

PS: Don't care about the $1, i once put that structure into an abstraction and just copied and pasted from there....

@toxonic The chance to get the following number should be higher than the other numbers

@ingox correct.