Submitted by Inco on Sun, 08/15/2010 - 19:30
Posted in
Hello
I think that could be interesting to allow the om to tigger more than 1 action per keyframe
for example
I´m moving 3 motors and I want that the 3 motors begins a up ramp at shot 50 and that the 3 motors begins a down ramp at shot 240
now I must use 6 keyframes and 6 actions to do that.
I dont know if is easy or difficult, It's only a sugesstion.
Best regards
Inco.
It's just a matter of memory
It's just a matter of memory right now, mainly it takes 3x as much memory to support 3 actions vs. one, and, of course, 4x for 4, 5x for 5, and so on =)
It may be a better choice to have global motor actions, for cases like this -- i.e. ramp all motors down, turn all motors on, etc. What do you think? Do you just want to control all motors, or do you see the need to, say, take three completely different actions at one keyframe? (e.g.: double exposure, half interval time, and turn motor on.)
!c
I think that 15 actions is
I think that 15 actions is enougth. I like the idea of globlal motor actions. This option covers a lot of needs.
Other way to do that whithout using more memory may be using the high nible of db5 or db6 (of motor action) to indicate by some way that this action must ocurr at same time than other (I know 4 bits -> 7 options if the 0 option means nothing). Then execute, for example, action 2 and review all the other high's nibble of db5 actions to see if there is another action that must be executed at same time ?
Or use this 4 bits to indicate to which motors it must be aplied ?
Inco.
It would be possible to do
It would be possible to do this (apply one action to multiple motors) by removing the on/off flag that's included in every motor action and add it as a specific action target. That would free up 2 bits, which could be added to the 2bits for the motor identifier to create a 4-bit array of single bit flags, for "which motor this applies to."
I mention modifying this, as it's the 32-bit value of the action its self that determines how it's applied (see OM_Keyframing.pde, starting at line 190) - then the serial protocol would simply change to suit the needs. All-in-all, it would be a fairly simple change. I'll add it to the 1.0 wishlist, but I think we can find a way to sneak it in there when the two outstanding changesets get merged in (serial object, async motor control).
!c