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 🙂

          giuliomoro 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?

          you were totally right - it wasn't. and it should be!
          well spotted sir.

          easy fix though. will upload corrected version 0.2 to patchstorage.

          and i really like your suggestion of a log/lin/exp control for the slew.
          was thinking about how to implement that - my first idea was to use a [pow] on the [line~] output, since that would change the response within the 0 - 1 range. i guess that could work on the binary outputs, since they always want to hit 0 or 1. but for the main output, it changes the output value itself more than the curve of the movement towards that value, if that makes sense.
          will need to take some time to figure out a way that works.

          found this, https://forum.pdpatchrepo.info/topic/13084/xline-logarithmic-line-object
          which seems interesting, but not sure if it's the right way forward.