Feature request: reversing keyframes edit touch mode  

I'll try to implement the "stay awake" function in the following app updates.

For the keyframe situation, with "edit" you mean overwriting the current keyframe?
There is also the regular edit option via the button that will show all the position values for each motor and keyframe.

Yes, I meant that it would be more handy (and probably also aligned to general iOS best practices) to have the single touch to move the motor to the selected keyframe, while the touch/hold to overwrite it.

Sorry, my mistake. The Edit function is alright as it is now.

Best

L.

Hi Lorenzo,

The "Keep screen on" feature has been added in the last iOS app update.

Patrick

Hi Patrick,

after I updated the firmware to my Pine I noticed the app automatically keeps my iOS device awake, I'm on 3.0.6. but that didn't happen before...

If this setting is already in (and it looks like it's enabled) I cannot find it...

I also tried setting some keyframes up in video mode. I set up different times pre and post the keyframe (hence different speeds); I noticed that when the carriage gets to one keyframed position (we are talking about the slide motor) it stops and then immediately starts again at the different speed; it would be nice if it could smoothly transition from one speed to the other instead of stopping.

I haven't tried with pan and tilt motors, but I guess it is the same. 

Can you confirm the behavior? Or is it something with the motors I'm using (regular Nema 17)?

Thanx

Hi Lorenzo,

Regarding the "keep screen on" option, this has been added in iOS V3.0.6. However this setting cannot be turned off. It is active now always. Meaning, whenever the PINE App is active, the screen will never turn off automatically (unless the user turns the screen off of course or the app goes into the background).

Regarding the keyframes in video mode, this is the usual behavior. When setting more than 2 keyframes, the movement will come to a complete (very short) stop, before ramping up again going to the next keyframe. When you remove the entire ramping (ease in & out) the motors will not come to a stop but the speed will go from one speed to the next speed rapidly. I don't think it will be possible for me to achieve a smooth speed transition between multiple keyframes without messing up the overall timing of the entire movement. I'll keep this in mind and see if I can improve this in the future.

All the best,
Patrick

Hi Patrick, no problems with the screen shut off, it's OK like it is now.

As for the ramping between keyframes, I'll try that and see if that works, my only concern with that is if I lower the ease for that motor to zero it will start and stop abruptly at the corresponding keyframes, isn't it? Unless a dedicated ramping parameter is introduced for the intermediate keyframes, and that can be set different than the main one.

Thanx

L.

Please, also consider reversing the touch functionality of the keyframes to Tap>move to keyframe, Tap/Hold >overwrite keyframe, as I wrote, I think it's more intuitive and in line with iOS behaviour and best practices (like when you want to move or delete an app from an iOS device, the gesture is tap/hold, while the single tap operates/launches the app).

Best

L.

Hi Lorenzo,

for the keyframes you are right. When you set the ease values to zero, the movement might be too abrupt. And also ease values are global for all keyframes. So you can't change that for individual keyframes.

We have been thinking about the Tap>move to keyframe, Tap/Hold >overwrite keyframe situation. Even though we mostly implement things our users recommend, we might have to pass on this one. Let me explain:

• Changing this behavior will result in us having to change this in all other areas of the app, both for Android and iOS
• It will be confusing to all other users when we change the behavior all of a sudden. As I'm sure most people are used to the way it currently is.
• Currently, a single tap on a set keyframe will show a pop-up dialog and only confirming it will overwrite the keyframe. Holding a keyframe will not show a pop-up and the action will be taken right away. Here I'm just thinking about accidental taps that can happen. Single taps can happen more often by accident compared to long-taps (holding). If a single tap happens by accident, the user can then just cancel the pop-up compared to having the motors start moving right away to a random keyframe.

I hope this all makes sense.

All the best,
Patrick

Hi Patrick,

I see what you mean. Coming from an app development background (as a product manager) I'm used to the other way around, single tap, executes, tap/hold, enables modification, but I understand what that would men in terms of coding and user feedback.

Hopefully you'll keep this into your list of suggestions and possibly implement it for a v.4 of the app...

Since we are on topic, I may have a few other things I'd like to see implemented; not because I like to annoy or make you waste your time, but because I'm actually using the Pine/app with my rig for shooting work and I come across some things that I think could help smooth out the workflow.

In this case I think that in the Live mode a nice addition would be to actually be able to set the time of the move between scenes in seconds instead of speed percentage: sometimes timing a movement to an actor product is key, and getting it spot on means having the possibility to nail the right time.

What do you think?

Best

Hi Lorenzo,

That sounds like a good feature addition to the Live Mode. I will implement it in one of the coming updates.
We never knew that the Live Mode is being used much by our users, but it's nice to hear that it is actually being used productively. 

All the best,
Patrick

Hi Patrick, 

cool!

I think the live mode is useful when doing timed product shots where you decide a an A pose and a B pose and want to toggle between the with a simple tap. Being able to time the move precisely will be an added plus.

Speaking about that, I think I may have a couple more things to discuss (still have some issues with the position sliders not being responsive, and motor movement sequence), but being those not strictly related to what we are taking about, should I open a dedicated topic?

Best

L.