Faders as a fluid

leemorgan's icon

Hi - can I get some advice about this idea?

I've got a row of faders, that ripple (when you move the first) to create a wave in the faders.

To make it more like fluid wave: what approach can anyone suggest to make it even more like a fluid, such that when you raise (or lower) a middle fader, it ripples both left and right - and even, should it meet a wave coming in the opposite direction, cancels it out?

I'm guessing gain~ faders and pipe delays isn't going to cut it: so how can I do it without studying fluid dynamics...

Thanks,

Lee

Max Patch
Copy patch and select New From Clipboard in Max.

Roman Thilenius's icon

for single events you should be fine with [pipe] & amplitude.

to avoid more complicated physics calculation, one could try to accumulate the results of multiple forces from the first slider. it might be that you needed parallel delay lines for that.

in case the input from the force is a steady, fixed rate data stream, you can also roughly mimic "weight" of the other sliders using [slide]

leemorgan's icon

Thanks Roman: I guess I'm after multiple events - by parallel do you mean having delays going in both directions along the faders with some logic to determine that, if (say) a middle fader is moved, all data to the left and right of that fader is allowed though - so, some kind of gate arrangement? Now I've written that down, I see it makes no sense....

TFL's icon

Funny exercice.

What do you want to do with this? What do you want to control?

I would go with jit.matrix to store the state of each slider, jit.gen to do the fluid calculation, and why not using multislider or [matrixctl @dialmode 2] to display the result and interact with?

Here is an example with multislider. The physic here is very naive, just to show that for proper fluid-like behavior, you actually need some fluid dynamic basics.

Max Patch
Copy patch and select New From Clipboard in Max.

EDIT: my example is a very bad one, a lot of calculation in the jit.gen makes no sense, I basically just apply some kind of gravity to each slider.
But the idea is to sample the matrix using nearestpix to get value from nearby cells and move the cell accordingly. To get proper physics calculation, I assume you might need to store the speed and acceleration of each fader, either in separate matrices or in separate planes.

leemorgan's icon

Hi TFL - thanks, that's really interesting: and though the patch is not what I described, it's still a great way to control a line of faders in a naturally dynamic way... I'll take this and see where it leads. Storing speed and acceleration data? OK, matrices and planes it is.....

TFL's icon

Got hooked by the exercise. Here is another attempt, based on this Processing implementation found through this video.

Max Patch
Copy patch and select New From Clipboard in Max.

Enregistrement de l’écran 2024-08-31 à 12.31.08.mov


leemorgan's icon

'Attempt' isn't the word: this is delightful. I don't know what to say: you've done something very special here. What a beautifully elegant solution. I was deep in matrix hell, and wherever it was heading it wasn't here - this really IS water. Thanks so much TFL.

Roman Thilenius's icon

re:multiple

what i meant with "multiple" is when state changes of the first fader will lead to movement of the others which are overlapping each other. in physics, you would at least have to accumulate the velocites, but one can always try to find simpler workarounds for similar results.

i´ve always wanted to do a custom pmpd using basic max objects, but it is too much effort and CPU use for what it does.