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.

                    well.. that lin/log/exp exercise turns out to be quite a bit more complex than i thought 🙂

                    orignally i thought i'd take the generated numbers (near the output, where they are already mapped to 0-1) and run them through a [pow], as you would to convert lin behaviour to log or exp.
                    but this just shifts the position of the output numbers on the slider, which i don't want. i was quite happy with the mapping i had, distributing the generated results evenly. so that needs to stay the same.
                    what needs to change is the speed at which i travel from one number to the next. and this needs to be a flexible curve.

                    so here's what i think might work.
                    when a new number (target value) comes in:
                    1. check what value we're currently at on the output.
                    2. calculate the difference we need to bridge (=distance between this current value and target value.)
                    3. we would then need to add this difference to the current value over time, at a flexible rate.

                    to determine the wanted curve, the [pow] trick on a [line] output will still work if the line goes from 0 to 1.
                    so we have the correct curve going from 0 to 1..
                    if we then multiply the difference-to-be-bridged with this curve, we're going from 0 to the full difference over time, with the wanted slope.
                    then we can add this to the current value to end up at the target value.

                    phew.

                    hope i can get something like that to work reliably..

                    edit:
                    well, i cooked something up. the only thing that i couldn't get to work at first was a realtime update of the curve.
                    it worked fine when waiting for the curve to end, and then have the new one with the new response.
                    (kinda like the ramp time earlier, hah.)

                    the problem is that you would either:
                    - have a jump in value when changing the [pow] factor in realtime (matching the same x position on the new, different curve will yield a different y value), so changing the control would cause skips and not feel smooth.
                    - have to start a new curve when changing anything (input value, ramp time, or curve response.) this does not cause skips or jumps, because it starts off from the current value, but it causes a whole new ramp to start when you touch a knob. which might be undesirable, especially with longer curves.
                    - have to start from the current position, and only use the remainder of the ramp time for a new ramp with the new response. this would involve a timer to keep track of how much of the ramp has passed, and i feel it would lead me way too far.

                    will see where it takes me. for now the reasoning behind the system seems to be correct, so that's that already.

                    the timer solutions seems to be the best one - haven't tested on Pepper though.

                    while this might work for the main output, will have to wrap my head around getting this to work for the eight binary outputs. more soon, hopefully.

                    right, so i think i have everything smoothed out.. for the binaries as well..
                    when switching from slewed binaries to gates, the outputs necessarily jump to 0 or 1.
                    but that's always the direction the slew was already traveling in, so that seems okay.
                    when switching back from gates/triggers to slewed mode, the slew now starts cleanly from its respective 0 or 1.
                    that was quite the rewrite there 🙂 but it seems to work (at least on the laptop.)

                    while i'm at it, i'm now really considering having separate slew times for main and binary outputs, as that would allow far more flexibility. this version would then add three pots:
                    - log/lin/exp control for the main output
                    - ramp time for the binaries
                    - log/lin/exp control for the binaries.

                    i'm thinking it would be logical to be able to assign either of the ramp times to the internal clocking.
                    this would mean, for example, that if you used the binary clock to drive the internal stepping, you could set the main slew time to 0 and have discrete jumps there.
                    or, on the other hand, driving the internal stepping with the main ramp time, and setting an even longer slew time on the binaries, so they never really land on 0 or 1.
                    it's nothing that can't be done with an external clock, but i think it would be very easy to implement at this stage.

                    QUESTION
                    i could put 'which ramp time to follow for clock modes 3 & 4' on the last pot left.
                    or i could add clock modes 5 & 6 to the existing four, so it reads

                    1. external clock, one shot
                    2. main ramp time clock, one shot
                    3. bin ramp time clock, one shot
                    4. external clock, autosample
                    5. main ramp time clock, autosample
                    6. bin ramp time clock, autosample

                    or a similar grouping.
                    would that still be user-friendly for a module with no real readout?

                      Remork i think it would be very easy to implement at this stage.

                      sure dude. if you say so 🙂

                      in the end, i implemented all of the above. separate slew times, separate curve shapes. 2 new modes for running off the binary slew clock.
                      all of this had major implications i hadn't though of, mostly when switching modes - if you change to the other clock, should it already have clocked the next step? if not, when should it? so that part of the patch blew up in no time 😱

                      and of course, it all worked beautifully on the laptop, but it pushed Pepper into the red. peaks of 85% CPU and tons of dropouts.
                      then i realised i was calculating the curve for each output (with a timer, a [line~] and a [pow~] each, not the lightest objects), while the 7 binary outs could of course share a single calculated ramp. duh.
                      so after staring blankly at the screen for about ten minutes, another major optimising rewrite.
                      i think it still works as it should, and the 85% dropped to about 45% when pushed.

                      will do some more testing, hoping this thing will be ready for its v1.0 release soon!
                      keep you posted..