Help testing my first module: Memory Pad

Hello! I’ve been developing my first module and am getting close to releasing it. I would really appreciate anyone who’s willing to test it and let me know if they run into issues or have feedback. I developed it in macOS and have no access to win/linux machines, so I would especially appreciate testing there.

The plugin is available here: Release Release v2.0.1 · epadilla/patina · GitHub

The module is called Memory Pad and it is an XY touchpad that records a drag on it and repeats it, outputting to 2 outputs. It is meant to be a performable LFO, of sorts. Just drag your mouse on the touchpad and it’ll start replaying the path. You can pick a path direction, speed, set to unipolar or bipolar output, and attenuate. No inputs for now–I decided to keep it simple.

Let me know any issues or feedback. Thanks in advance!

23 Likes

Love it, works great for me on Windows 11, VCV Rack Pro 2.4.1

Only one issue I had is that it doesn’t save the motion, so if I close and reopen Rack I have to redraw it.

4 Likes

I recorded its output with Entrian’s CV sequencer. Great fun !

Mac Mini M1. Monterey 12.2.

1 Like

Thanks for testing – love to see it in action! Glad to hear it’s working on Windows. I did implement saving of the path, and it does work for me on my Mac. Quitting and relaunching Rack should preserve the path. Perhaps this is a Windows bug – I’ll look into it. Thank you!

Just watched DanT’s video sounds good, could it be made into a Chaos pad by patching it to fxs and filters. That would be a wonderful thing in my eyes. :star_struck:

1 Like

Hmmm, I just tried it again and at first it did not remember the path, but then on the 2nd try it did… now I can’t get it to fail. So not really sure why it didn’t work at first, if I had realised I should have checked the autosave patch.json

I can see this in there now so looks like your module is working fine

      "data": {
        "RECORDED_X_PATH_KEY": [
          0.48074448108673096,
          0.48074448108673096,
          0.48074448108673096,
          0.48074448108673096,
          ...

edit: I notice in my autosave patch.json that PPW saves 2048 rows of values in there, like so:

        "fram_data": [
          -1590029344,
          0,
          200,
          251658496,
          251723875,
          65635,
          0,
          704668431,
          25359,
          838886159,
          25359,
          1677746959,
          25359,
          -285187313,
          25359,
          -285187313,
          1677746959,
          25359,
          25359,
          16802575,
          25359,
          6491904,
etc...

A while back I asked about the amount of data that is acceptable to store in the json file:

I believe this is due to the latency of writing more than 100kb to a file between frames, but that might not be accurate, anyway, I thought this was interesting…

Your module didn’t save anywhere near 100kb of data for the path, but is there a max length to the recording?

2nd edit: that makes me wonder, would it be possible to create some preset paths that the module could load? That might be fun, if you could load a preset of a circle, or other predefined paths that would be difficult to accurately draw in by hand (or mouse in my case :wink: )

3rd edit: just had another idea: might be cool if in the right click menu there were options to do some transformations on the path, like flip it vertically, or mirror the left side to the right side, maybe even a quantise options or something like that?

1 Like

Do you mean KAOSS PAD?

I’ve always wanted one of these, never got around to buying one… might have to go trawl ebay and reverb for a bit :money_mouth_face:

That would be Nysthis’s Quad Panner (patch 5 or 10v into the input)

2 Likes

From the source, 10K values

const unsigned long RECORDED_PATH_MAX = 10000;

1 Like

that many floats? those are 4 bytes each, so… 40kb?

4 bytes each for the binary representation - but aren’t they saved as json? (compressed I suppose)

1 Like

oh, right. JSON makes it bigger, compression makes it smaller. Still I don’t think I’d want to make a module that saved out so much stuff so often…

Works great for me on Windows 7. It also save the motion. Really great.

1 Like

close to the vector mixer

3 Likes

Thanks for looking into the saving. Def need to make sure I’m not writing too much, but having the path preserved across launches does seem like a good convenience to have.

Saving paths or having presets would def be cool. That one of the things I may try to tackle in a future version. And I love the idea around having flipping or other operations! I’m gonna think about that.

Yeah that’s a good call. I will look into just how much ends up being written (esp. with longer paths). Not sure that I have a great alternative other than saving all those floats in order to preserve the path though (unless i switch to module patch storage).

Yup that’s the critter, I can’t spell chaos with a K! But that would be something wonderful. There is a Vst out there by GSI, if I recall right called Shake pad.

1 Like

you could reduce the sample rate to like 100hz and save a huge amount of space. Or something…

2 Likes

The path recording happens in onDragHover() since that’s where I can get the mouse position which I believe occurs more on the order of 60Hz already.

Everything in the UI (events and rendering) happens at the actual frame rate, rather than the nominal frame rate setting, so in a loaded rack, the resolution of mouse tracking can drop. Rack wasn’t designed for drawing.

2 Likes