Cuz then there’s this one that didn’t sync well, I assume because the speed was changing, though the change in speed did match the speed on screen. So I guess animations with a constant speed and full stroke length work with any toy basically.
by working perfectly, i’m assuming that you found an action speed that produces a sweet spot within the overall control loop where it matches the overall response time lag and the machine’s inertia to give you the perfect thrust when telling the machine to do 0-100-0 power loops. But that obviously is quite lucky, while my approach tries to normalize scripts systematically so that you’re actually sending the correct motor speed percentage to your machine all the time. IMO that should be the right approach for stuff like this, although it’s not perfect, you will never have full synchronization without a way to complete the control feedback loop (i.e. getting the actual position of the machine at any given time). Hence why i’m now much more interested in getting a fully linear drive machine, where i don’t need to care about this conversion at all.
Also unrelated, but if you use my tool, when creating your machine profile for the hismith it’s better to give it speed commands via the intiface server, rather than relying on their hardwired remote. I found that the remote has a weird deadzone until about 10% on the dial, so i don’t trust their stated percentage when doing measurements.
Idk exactly how it worked, but I’m assuming from my experience using the script with my machine and now seeing it on OFS, the bottom point isn’t 0 and the top point isn’t 100, but rather the line in between them is what determines the speed. So the orange line is just a constant speed and then it switches to the red line which is a different constant speed. So the distance between each point is what determines the speed not the points themselves. So it wasn’t jittery or at 0 or 100 (unless red is 100) but swapping between two speeds, and it seemed like MFP smoothed the transition so it didn’t jitter between speeds which might be what caused the scene and script desynchronization.
That’s my take on the script that didn’t work.
For the script that did work, I assume that was crazy luck since (I assume MFP) smoothing the crests and troughs would’ve desynchronized it but the change in speed to smooth the wave coincided with the slight decrease in speed in the animation as the model also smoothly transitioned between upward and downward movements. So that means the script itself would be bad for a stroker though because it doesn’t account for the position where the model smoothly transitions between movements right? Like if it’s for a stroker it should’ve had a curve rather than an angle on the crests and troughs.
