ross

hi i've been trying to get control over a bouncing pixel in an LCD

this is the simplest, stripped down version of the various attempts I've made. it uses 2 counters that count up to 200 and then back to 0. I've also tried the "add new coordinate offset which reverses by being multiplied by -1 when outside the range of the LCD" approach - but the patch is too messy to post and suffers from the same problem, which is, if you change the trajectory, you also change the speed. I also had a try at using trig equations which I think may be the way to go - but i failed.

in this patch I can vary the angle by changing either of the 2 metros but this changes the speed also

what I'd like to be able to do is control both the angle and the speed independently.

separate-control-over-speed-and-direction-of-a-bouncing-pixel

I think I figured it out. You need to calculate the angle as a ratio and then maintain that ratio when you want to change the speed-- this is done using msp but you can adapt it to using counter & metro too if you want:

Been looking at this. The obvious thing is to use one number as the speed in one axis and then multiply (or divide) in the other to give the angle. Pythagoras intervenes to make either the speed or angle exponential but that's easily fixed via SQR or SQRT function.

Big problem is that lineto is the wrong function in that it is to an absolute coordinate. It does have the great advantage in that it wraps around the LCD space but to use it to calculate angle you'd need it to output the current coordinate which LCD doesn't do.

The right function is line which will draw a vector relative to the current coordinate. However, line doesn't seem to wraparound and just falls off the edge.

Max seems to be operating in a bit of a quantum world here. Heisenberg etc. Position and velocity uncertainty product.

This a far more than a three pipe problem

lovely patch Terry! and it gives me an opportunity to get my head around a little bit of MSP.

I won't need to convert this into max as I'm using it to design nice trajectories to be sent to a wall of speakers - it's absolutely perfect for my needs - control over speed and angle separately. (I've also got scalable shapes and hand drawn trajectories that save and playback through colls)

One thing though - when you change the angle in your patch, the speed still changes. Do you think you've got the ratio calculation slightly wrong? of course it's no biggie as there is the separate speed control.

I wonder if faders with some kind of exponential settings to inversely change the speed and angle together will fix it? i'll have a go ...

... or maybe we do have tonewheels uncertainty principle to live with!

lovely patch Terry! and it gives me an opportunity to get my head around a little bit of MSP.
I won't need to convert this into max as I'm using it to design nice trajectories to be sent to a wall of speakers - it's absolutely perfect for my needs - control over speed and angle separately. (I've also got scalable shapes and hand drawn trajectories that save and playback through colls)

One thing though - when you change the angle in your patch, the speed still changes. Do you think you've got the ratio calculation slightly wrong? of course it's no biggie as there is the separate speed control.
I wonder if faders with some kind of exponential settings to inversely change the speed and angle together will fix it? i'll have a go ...

...  or maybe we do have tonewheels uncertainty principle to live with!


I am, of course, talking absolute bollocks. The lineto function is the right one and, since it points to absolute position, will limit itself to the confines of the counters and stay on the LCD. Line is relative and thus goes haring off into the distance. I blame the lateness of the hour and the embrace of Bacchus.

Terry's patch is, indeed, a thing of beauty. I'm just wondering if there's a way of doing it without the trig functions, saving processor cycles on the way, by manipulating the metros.

OK I really did figure it out this time... had to get out a pencil & paper to do it though...

.....and here's the smart (as distinct from nerdulous) way of doing it using poltocar:

separate control over speed and direction of a bouncing pixel