new patch i hope some of you might like..
https://patchstorage.com/kollatz-0-1/

this one is based on the Collatz conjecture.
basically: if a positive number n is even, divide it by two.
if it is odd, then 3n+1.
iterate until n=1.

let me illustrate that:
for n = 6, you get 6 3 10 5 16 8 4 2 1.
for n = 7, you get 7 22 11 34 17 52 26 13 40 20 10 5 16 8 4 2 1.
for n = 8, you just get 8 4 2 1.

for n = 27, you get the lovely series 27 82 41 124 62 31 94 47 142 71 214 107 322 161 484 242 121 364 182 91 274 137 412 206 103 310 155 466 233 700 350 175 526 263 790 395 1186 593 1780 890 445 1336 668 334 167 502 251 754 377 1132 566 283 850 425 1276 638 319 958 479 1438 719 2158 1079 3238 1619 4858 2429 7288 3644 1822 911 2734 1367 4102 2051 6154 3077 9232 4616 2308 1154 577 1732 866 433 1300 650 325 976 488 244 122 61 184 92 46 23 70 35 106 53 160 80 40 20 10 5 16 8 4 2 1. ๐Ÿ˜ƒ

you see that for different starting values, this gives number strings of unexpected length, with values wavering up and down but always moving towards 1 in the end.

now bear with me here... LOTS of info coming up. ๐Ÿ’ฏ ๐Ÿ˜„
drumroll.. the connections!

input 0: voltage to be sampled.
0-10v input mapped to n=1 to n=250.
(this gives a maximum output number in some strings of 9232, so plenty of range.)

button 1/ trigger input 6: samples the 1-250 value. so press or trigger this to load n.
button 2/ trigger input 7: clock. iterates the value once.

output 0: master output, where Collatz output values 1 - 9232 are mapped to 0 - 1 (=full voltage.)
outputs 2-7: parallel binary outputs. the same Collatz value is remapped from 0 to 127, then translated to 7-bit binary. with every tick, values here read either 0 or 1.

then, the fun bits.
input 1: ramp time. this will not only slew the master output (think portamento between calculated values),
but can also slew the binary outputs.

input 2: clock mode. divides pot rotation over 4 possible modes:

  1. expects external clock (or pushing the button.) outputs move to their values over ramp time.
    note that when ramp time is slower than clock, outputs will not reach their target values, so e.g. the binaries can also be used as unpredictable envelopes, not quite reaching 0 or 1.

  2. same as 1, but when collatz value reaches 1, patch auto-samples the input so a new number series is automatically started.
    when using an LFO or noise as input, this will be a new number string.
    when using a steady DC voltage as input, you will get the same string, so repeated strings are possible.

  3. values move over ramp time, and end of ramp triggers new clock tick.
    clock speed and ramp time are no longer independent, but there is no more need for an external clock.
    ramp time can still reach 0, but retrigger minimum is set to 30ms so as not to cause underruns/dropouts.

  4. same as 3, but when collatz value reaches 1, patch auto-samples the input so a new number series is started.
    in both 3 and 4, external clock will still step the string, so it gets added to the end-of-ramp ticks.

input 3: binary output modes.
divides pot rotation over 3 possible modes:

  1. binaries slewed w/ ramp time.
  2. binaries set to gate outputs. high as long as value is 1.
  3. binaries set to trigger outputs. 20ms triggers when value is 1.

this makes for a nice pseudo-random rhythm generator.
if you want repeatable patterns, same rule applies i guess: you could resample a fixed DC voltage every 8 or 16 steps to restart the same sequence.

i think the results and possible applications are somewhat similar to those of a turing machine, for example,
but hopefully different enough to be it's own thing. please try and let me know what you think.
download from the link above and rename _main.pd as usual.

with minimal effort, i guess it could easily be adapted for Salt users (4 CV ins, 2 trigger ins, should be ok, no?).
only the binary outputs would need a compromise - but they already were in the first place, since you would need 14 bit to represent 9232.. and even that value was a conscious limitation.

fun thing to try would be negative input numbers - these can generate different loops in the strings than the 1-4-2-1 end loop, so every now and then you might hit an unexpected LFO ๐Ÿ™‚

anyway
i had a lot of fun patching this, hope you like it.

@mods: if this should go in show and tell, please move.

Veritasium video on the conjecture - after the first 5 minutes it should be clear why i felt this would make a cool CV generator.

it sounds like fun, thanks for sharing. Do you have an example video of the patch in use ?

no, not yet.. i'm not terribly good at documenting and/or video editing, i'm afraid.
will see if i can cook something up, but i'm reluctant to promise you guys more videos.. still haven't got one on the keyboard either ๐Ÿ˜ญ

sure, I said that because for me it's a bit complicated to tell from the description what the outcomes sounds like, but I surely don't want you to commit to anything ๐Ÿ™‚

hah. ๐Ÿ™‚
the patch just generates CV's, so it doesn't necessarily sound like anything.
ba-da-djinggg

5 days later

longish video, but i think it covers everything.
it actually has some sounds ๐Ÿ™‚ though in retrospect it might have sounded more musical modulating filters instead of VCO freq. it does illustrate what is going on quite well though.
the dancy stuff is all the way at the end!

OMG this is so great, I didn't want the video to end! Well done, I like the attention to details such as the crossfade of the LEDs on the LED bar. I guess it would be great to have options for log/linear/exponential slew (maybe with a continuous "shape" control) and also it seems to me at one point in the video that the slew rate is fixed once the new "number" starts, while I expected it to follow the slew pot throughout its duration, but this are just my considerations and I haven't tried it and I have very little hands-on modular experience!

thanks ever so kindly! happy with it, but already considering some possible addons/modifications..
seperate slew times for main and binary outputs, for one. which would alliow to control pitch in discrete steps with the main while morphing with the binaries etc.
slew response control is a very nice idea as well!

using more pots would lead to even less compatability with salt, though. (which i donโ€™t own, but itโ€™s always nice for other users.) so maybe further versions will be pepper only. like i said, salt would need a redesign of the binaries anyway.

btw, your impression about fixing slew time at the moment of sampling is false - might be the video editing playing tricks ๐Ÿ™‚ you can totally speed it up or slow it down mid-sequence.

    Remork e at the moment of sampling is false -

    sorry I meant at the moment the step starts. Say that a step starts while the rate is high, so it takes a while to reach the target value: is the current step affected if you change the rate pot? Most analog ADSRs work like that (i.e.: if you modify the release time while you are in the release stage, the effective time will increase/decrease accordingly), but at one point in the video it seemed like it wasn't the case.

      Remork using more pots would lead to even less compatability with salt, though. (which i donโ€™t own, but itโ€™s always nice for other users.)

      Not sure there's much to be worried about there ... For the patch as it is to perform the same on Salt you'd need both Salt and Salt+ (because you are using all 8 analog outputs), therefore the user would already have all the pots available. Also I think the number of Peppers in circulation is > 3x that of the Salts...

        took me a while to fully understand your ramp time remark. not sure if the [line~] is restarted for every timing change, or only after every calculation. will check the patch. constant refresh definitely would make more sense - but i might have overlooked that, with line~ timing being a passive input in pd.
        if i overlooked it, definitely worth a fix for v0.2 ๐Ÿ™‚

        giuliomoro because you are using all 8 analog outputs

        thatโ€™s what i meant by having to redesign the binary outputs - basically reduce the number of outputs there.

        the fun thing would of course be if everyone adapts the patch to their own needs. ๐Ÿ™‚

        Wow, that's great! Thanks so much for taking the time to make this video, really lets the patch shine. It would be amazing to do a post on the blog about this in the new year if you'd be up for that. With the video and your description above there is definitely plenty of material for the post. We'd just need an artist photo and bio (sent to robert(at)bela.io). Maybe we could also feature a shot that great looking keyboard from a few years back :-D.

          bela_robert
          hah, sounds good!
          could give a slightly more detailed technical explainer as well if needed.
          not that thereโ€™s anything too difficult going on.

          as for that keyboard: i actually have too much video footage from its last presentation. still havenโ€™t gotten round to editing that down to a manageable size.. but iโ€™m starting to see the fun in it, although something tells me that thereโ€™s better editors out there than iMovie. something for the coming long winter nights, i hope!

          Sounds great! More detailed explanation would also be very welcome if you have the time. Looking forward to when the keyboard video comes out.

          For video editors I can't recommend Davinci Resolve enough. All the last Bela videos have been done with it โ€“ it's super powerful and free to use.

          so i just checked Davinci Resolve. looks impressive.
          i'll just add another learning curve to the to do list, then ๐Ÿ™‚