[function] - loops : changing values in same time when reading
Hello,
Can someone help me :
situation : with [function] I change positions of a stepper motor. X120(sec), Y 40000(positions of motor). Works well. loops of 2 minutes.
what I want : with slider (simulating a joystick) I want to change the dots of the curve simultaneously while reading the loop. In the end, I should not even look at the screen, but continuously adapt the curve with the joystick until the motor is moving conveniently. The correction is of course always executed for the next turn of the loop, that's ok for me. After a few turns, the motor follows my requested move ... and I can do the same game on the next of the 20 motors.
my problem : the correction does not erase the previous dots but adds the new ones keeping the old ones. How can I kick off the not wanted dot-value of the curve (but not CLEAR the whole curve) ?
If anyone has a solution, I'd be very happy, many thanks in advance, pad
Hi padrut
fast answer/ideas:
imho an external logic, 2 steps :recording many points is not a problem with function, than edit and simplify with your rules : values or time regularity ?
dump and erase points within a minimum delta, or
dump to a coll with a counter index, and treat the data, i.e. if you need points at regular timing, or
more complex, scale your values and dump to a buffer~, use the tools of buffer~/waveform to edit your datas, and peek~ the values to your function, or
dump to a multislider, so you can edit by hand
surely other solutions, scaling to MIDI, seq etc.
hth
michel
Here's my take with [multislider] instead of [function]:
You can invert the connections after the [t i i] to make your changes being read only when the next cycle starts
interested question for me: ( never used stepper motor ) : X 120'000 msec for Y 40'000 : is a time of 3 msec regular ? Are the datas only + 1, 0, -1 ? Multislider can accept 32'767 sliders ( fun!)
joystick : like the latch or relative function, mixing in an audio sequencer ? With a mid-neutral position ?
sorry if OT, oups
michel
120 seconds is 120 seconds, and 40000 seems to be the resolution of the motor, not the frequency at which its position is updated. OP did not provide info about how frequently the motor angle should be updated, but I am assuming they use [line] with the default 20ms time grain. I guess as long as the motor is fast enough to reach the next step, it should be fine. 120 seconds in 20ms steps represents a total of 6000 steps, so [multislider] is still enough :) Otherwise, a [coll] or [array] could do the trick without much modification.
I did a (-1., +1.) slider for the sake of simulating a joystick axis, but the stepper motor will probably take an angle in degrees instead, or more complex signal depending on the electronics involved.
joystick : like the latch or relative function, mixing in an audio sequencer ? With a mid-neutral position ?
I would say the joystick drives the distance to travel in each step (ie: speed) , not the position itself. So if you release the joystick the motor will stop at whatever position it is. At least this is how I would do it.
Yes, i should go too with multislider... Thinking function, if i want only a certain number of points, the goal is to modify the next point, or the curve between. My interest here is how to think timetagged datas like an image, vectorial vs bitmap ? Maybe a Jitter way..? oups :-)
michel
Hello MIZU and TFL,
thank you for your answers and the patcher. I'll test and adapt to my motors early next week and give feedback then.
40000 steps is in fact the real positions of motor, not angle. the art-project is to move a string-puppet with about 20 stepper motors, positioning the puppet from being in the air to standing, to sitting and finally lying on the floor. The positions of the motors are transmitted to the puppet by the strings. So I consider the 40000 Y-values as the real vertical position of each articulation, the X-value is the regular timeline shared identically by all motors together. The angle on [function] indicates me the delta-velocity (flat horizontal = no position changed, vertical = going quickly to new position).
A loop of 120 seconds is a time that allows me to construct a moving and get at the end on the original beginning point, so I can safely construct one moving of a motor, test it, then get to the next motor, align it to the first or alter following intuition and so on for all the motors.
Once a 120sec-loop is fixed, I continue and the general idea over next years is to construct a library of moves so that I could either use it on improvisation (together with dancer), or fix an automated "only puppet" show of about 45 minutes.
the size of the puppet is just about 30 cm <250 gr with stepper motors <1Nm force. Once the program-structure is sure and is not changed anymore, I'll transfer it to the life-tall 50kg puppet with stepper motors 5...11 Nm. This puppet worked since 2022 on 2 technicians multi-joystick controlled 20 DCmotors until now, and I'll only start equip the project, when I'm sure about programming, troubleshooting with the small one.
PS I hesitate between [multislider] and [function]...tried the two of them, must also consider the fact, that 20 (or still more) of motors asking for data can be a lot of real-time calculation, and I should have minimum of time-delay.
fast answer on first tests :
probably joystick is finally not the good tool, because I must intervene on parts of the curve to change without looking at the screen.
So I'll try the idea of gear-changing on formula-1 cars on driving-wheel : two buttons one up one down, so I'll be able to push the dots on [function] a little up or a little down of their initial position.
that'll be safer action (even if slower changing results), because a mistake of joystick can have huge destructive issues.
:-)
Padrut
You can use joystick as up/down pusher.
more distance to mid position, faster steps.
for fun: made some adds : bline to smooth and hover to reset the slider to 64. Made the scale 0 128 to have a real 0. ( joysticks and interfere in a flux of datas is my actual obsession :-)
hth
mz
but bad news. :-(
I cannot have the range of [multislider] I'd like ! X 100000, Y 0 to 40000. AI wants me to do it with buffer and plot.
I never even opened it. doesn't seem to be easy. I'll try...
You can use [table] to store/retrieve data, and if you want a UI, [itable] to visualize and edit with the mouse.
hey, this is unexpected help. I tried it shortly.
helps me a lot to avoid sleepless nights.
many thanks, my friends !
p
made that fast for curiosity. Buffer~and peek~works without audio on, and no limit in samples. But maybe need to go to float 0.-1.. Is it precise enough ? The tools on waveform can be useful to edit fine inside. hth mz
Hello TFL, hth, MIZU, SOURCE AUDIO,
I continued and tested yesterday testB (based on[itable]) and its command-patcher - seems to me quite nice... on the command-patcher I put joystick-command and up-down-buttons (which I prefer).
Joysticksender is the main command-module. Pink color 1) and 2) should make work the loop. All the rest are automatics and options.
testB is a messy to-understand-version of going through : As soon as tested with motors, I'll put it to backup and clean all unnecessary control-objects before creating the 20 motor-version...
Handicap : Program-speed on its max is faster then motor-response (max 5 ms/pulse) : until now I had constant pulse following (that occurs stop-and-go moves), I made now a loop from delta-positions to pulse-[cold in metro] : when motor is lagging and delaying the curve, it speeds the pulses [metro] up to its max of 5ms/pulse (200Hz), and slows down to 165ms/pulse (6Hz) when the delta is small. This, because the stop-and-go effect on the puppet is very ugly, compared with hand-playing...
testB has now already installed the to-the-interface-and-driver-motor part of program.
tests with motors will be Monday and next week
@ MIZU : [buffer] interesting object ! thanks. But is always the same difficulty to me : my brain is not quick enough to spread over all possibilities maxmsp in same time. So I'll work [buffer], once Igot through with [itable]. I must be able to understand what I do, for object [panic] is not option when 1 week before being on stage...
Later I'd like to record on hard-disc automatically and continuously (for example at each end of a loop) the state of curve, but something with adressing message {write data} on [itable] refused to cooperate.
have a nice evening
p
I have no time to deeply dive into the patch.
and I don't really know what you send to the motor.
The way I used to work with stepper motors is a bit different.
much simpler.
take motor max speed per step, calculating all parameters,
and send stream of values without repeating values to position the motor.
If you know where motor is currently located, you know how fast it can go to next
position.
But few points are very clear, you can not downscale 0 10000 0 100
to output ints without inserting change object.
otherwise you get many repetitions that get sent.
check all parts to limit the speed of messages to your motor limits.
bpatchers are missing so one can't really see what gets sent.
here is test patch with joystick as stepper.
slider range is -1. ~ 1.
you can adjust that to your joystick range
Hello SOURCE AUDIO,
thank you for your message and help -
I''ll try to get out of my mess - but need to continue being in front of the motors next week to see my errors on the real moves. I'll work through your advice.
I shared too quickly sketch work and also too much in disorder on forum, beg your pardon. My maxmsp-knowledge is mostly self-made experience, I have to pass often through every possible error... my computer hates me profoundly for this not logical approach...
On one hand I'm disappointed on what digital-motor-moves offer compared with human intuitive action - but on the other hand, what I already discovered by stepper-moved expression is too beautiful to reject : so I insist.
p