Forums > Jitter

using jitter matrix as a buffer for lfos

March 1, 2009 | 11:47 pm

So, I have six lfos controlling rotation and position of an object in 3d. I want to create a buffer so that I could scrub back through the past few seconds of motion. I figured I could use jit.fill and jit.spill with a six-plane one-dimensional matrix, but the results are not working out quite like I imagined. One thing I’m not sure of is how jit.fill behaves once the length I specify for the matrix has been exceeded. Does it stop filling or just rewrite from the beginning? Any suggestions would be appreciated. Here is what I have so far:

– Pasted Max Patch, click to expand. –

March 2, 2009 | 1:23 am

you dont need jit.fill/spill for what you describe. look at this…
but if you use jit.fill you have to send all cell values at once as a list (Not just a single integer like you did). you cant set single cells – which isnt necessary anyway because you can do it directly with jit.matrix

p

– Pasted Max Patch, click to expand. –

zach wrote on Sun, 01 March 2009 16:47So, I have six lfos controlling rotation and position of an object in 3d. I want to create a buffer so that I could scrub back through the past few seconds of motion. I figured I could use jit.fill and jit.spill with a six-plane one-dimensional matrix, but the results are not working out quite like I imagined. One thing I’m not sure of is how jit.fill behaves once the length I specify for the matrix has been exceeded. Does it stop filling or just rewrite from the beginning? Any suggestions would be appreciated. Here is what I have so far:

– Pasted Max Patch, click to expand. –

March 5, 2009 | 1:31 am

Ah, thanks. Do you have any idea why this isn’t working for the last three values? I’m posting both the buffer and the lfos.

Also, you’ll notice I’m repeating a lot of code here. Is there a simpler way to do this? I’m unsure about using poly~ because everything is running simultaneously and I wouldn’t know how to time the target messages.

– Pasted Max Patch, click to expand. –

– Pasted Max Patch, click to expand. –

March 5, 2009 | 4:49 am

you patch would be easier to read if you would adapt it a bit more…

zach wrote on Wed, 04 March 2009 18:31
Ah, thanks. Do you have any idea why this isn’t working for the last three values?

because your [pack]s work with integers by default and you are sending floats. you have to change them to [pack 0. 0] .

Quote:
I’m posting both the buffer and the lfos.

just out of interest – you are using the sync~ to build your lfos? thats very weird to say the least… but i dont know the bigger context of the patch.

Quote:
Also, you’ll notice I’m repeating a lot of code here. Is there a simpler way to do this? I’m unsure about using poly~ because everything is running simultaneously and I wouldn’t know how to time the target messages.

you could have just encapsulated the first [float]->[zl rev]-chain and reuse it five times by only changing the parameter of the receive and the messagebox. any elegant technique for making these two paramters variable inside the subpatcher (like patcherargs) would be more effort than time saving i guess.
i wouldnt use poly~ for something like 6 copies but thats more personal taste i think.

one more thing: you send bangs to both inlets of the [float] which doesnt make any sense afaic see.

p


March 6, 2009 | 1:48 am

Thanks again!

The double bangs were a mistake; no doubt the result of the spaghetti code.

I’m not sure what you mean by adapting my patch. Are you referring to the layout, because I could certainly use some work on that to make all my patches more legible.

I agree that any elegant solution to the duplicated code would ultimately be a waste of time and possibly complicate things further. That’s one of the few aspects in which I would prefer text coding to graphical.

Finally, I used sync~ because I wanted to change the tempo of each lfo individually. I suppose I could have just used phasor~ and rate~, but I originally wanted to use tap-tempo, which I couldn’t get to work for some reason. I don’t see any difference, but I have little experience with MSP, so I could very well be missing something.

-zach


March 6, 2009 | 5:12 am
Quote:
I’m not sure what you mean by adapting my patch. Are you referring to the layout, because I could certainly use some work on that to make all my patches more legible.

what i mean is adapting for posting it here. i cant use your patch immediately. first i have figure out where to add some bangs and numbers here and there to just find out what doesnt work for you.

Quote:
Finally, I used sync~ because I wanted to change the tempo of each lfo individually. I suppose I could have just used phasor~ and rate~, but I originally wanted to use tap-tempo, which I couldn’t get to work for some reason. I don’t see any difference, but I have little experience with MSP, so I could very well be missing something.

but you are modulating some GL coordinate stuff, no? so why use any msp objects at all (there can be reasons to do so but not if you are just diving into max in general right now). you could just build your LFO for linear modulations with metro->counter (learning to add sine-or-whatever movement is a nice exercise btw). in this case it could be good to have just one (master)metro running at a high speed and then just grab each nth bang for different speeds for different LFOs. the easiest way to do this is "lnth" from peter elsea´s Lobjects…
DTMS?
HTH!

p


March 7, 2009 | 2:39 am

I’ve actually been looking for an object like lnth for quite a while now! I think I’ll stick with sync~ for this project as I like the variety of inputs it can take, but I’m definitely using lnth in a video scrubber I’ve been building. Thanks!


Viewing 7 posts - 1 through 7 (of 7 total)