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..

      Excellent, please keep the updates coming.

      Remork sure dude. if you say so πŸ™‚

      I know the feeling well...

      sounds like a lot of progress anyhow, which ...

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

      justifies the quick escalation from v0.1 to v1.0 !

      hahaha - i know
      well, v0.2 is up on patchstorage now.
      with the fix for this remark:

      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?

      then i started work on that log/lin/exp control for a possible v0.3.
      but having separate times was just too juicy an idea, so that exploded fast.
      i think i squeezed enough of a difference and extra functionality into it to warrant a version change πŸ™‚

      I would love to give it a spin! I'm currently travelling but will be back with my modular case in the new year and will definitely try it out then and let you know how I get on.

      Show and tell πŸ™‚
      straight to stereo, warts and all.
      thoroughly enjoying the modulation possibilities here.
      would've liked a fatter bass sound, but was out of oscillators. meh.

      I guess my abstraction capabilities and Eurorack knowledge are pretty limited hence I am not sure I understand how the sounds / maths seen above give the sounds heard in this last recording. I enjoyed it, though!

      well.. think of it this way: most everything you hear changing over time, with every step of the rhythm, all those changes are driven by the pd patch. remember it doesn’t make any sounds, just cv’s.

      only the changing bass notes come from a keyboard arpeggiator. the opening koto-like melody is based off that, but is built using changing intervals on the bass line. deciding those intervals: kollatz main output. PWM aka timbre shifts in bass notes and the lead synth: kollatz binaries. the volume swells on that lead synth: binary. the filter moving on the bass: binary.

      make sense?

      makes sense. It was just much more straightforward with the earlier example that here it's several layers of abstractions away πŸ™‚

      oh absolutely.
      one of the main problems of modular is that it’s so awfully modular πŸ™‚ makes it hard to hear what is the what of the which.

      this example’s closer to an actual real life situation though πŸ™‚