Video Shuttle Support via API?

[funkelodeon]

I'm working on a Panel application for Premiere Pro where the user reviews metadata about a clip while the clip plays. We need to enable keyboard shortcuts for a lot of the same functionality that the program pane has (step forward/back 1 frame, play/stop, etc). Because of the limitations of keyboard shortcuts and panel focus, my panel application must handle these playback shortcuts explicitly.

The interactions I'm having trouble finding support for in the API is shuttle forward/back, increasing the speed of shuttle, etc.

I haven't been able to find anything using the Data Browser that looks like it might do this. The nearest thing I can think to do is to call setPlayerPosition() on an interval, making the playhead jump at approximately the correct rate. This seems overly complicated, and wouldn't have sound playback either, so it seems like a poor approximation.

Has anyone had experience with this?

Thanks,

-Nick

[Bruce Bullis]

What makes relying on PPro's own transport controls an untenable solution?

[sberic]

Bruce Bullis wrote

What makes relying on PPro's own transport controls an untenable solution?

Going out on a limb here but I would expect that they expect preview functionality while their extension panel is focused. As there is no fast way to switch between panels​​ (including OS-standard window-switching controls like [CMD+`] in macOS), it only makes sense that they would want to drive other features - think of it like a specialized, custom control deck for Premiere Pro.

Without this, the user experience looks like this:

1. Click custom extension for focus.
2. Trigger commands.
3. Move mouse to appropriate native panel and click.
4. Trigger commands.
5. Move mouse back to extension and click for focus.

That's a lot of mouse movement, simply to switch contexts. My guess is that funkelodeon​ is simply looking for a way to simplify life for their user.

Or... I'm way off the mark 😜

[Bruce Bullis]

Isn't that user experience exactly what happens when people work with (for example, review & approval) markers, using the source/program monitor, and the marker panel?

I'm not suggesting panel developers shouldn't want a transport control API; I'm just trying to understand the motivation, and what makes "how it works today" unworkable.

[sberic]

Bruce Bullis wrote

I'm not suggesting panel developers shouldn't want a transport control API; I'm just trying to understand the motivation, and what makes "how it works today" unworkable.

My point wasn't to say "this is necessary because it doesn't work otherwise." My point was to highlight the pain that such a lack implies for your users.

What I'm trying to point out is 100% analogous to the "lack of Premiere Pro API documentation" issue. To your point, this lack has not stopped people from creating extensions. That doesn't, however, imply that said lack isn't a significant source of pain for everyone who sets out to create an extension.

The motivation is simple: make life easier for users by simplifying workflow and reducing frustration!

[e_d_]

https://forums.adobe.com/people/Bruce+Bullis  schrieb

Isn't that user experience exactly what happens when people work with (for example, review & approval) markers, using the source/program monitor, and the marker panel?

Yep, and I guess they don't like it.

I'm not suggesting panel developers shouldn't want a transport control API; I'm just trying to understand the motivation, and what makes "how it works today" unworkable.

I could also imagine the metadata is coming from another system and not necessarily in the Premiere project...

I don't get the OP's concept as well, too much room for speculation, and to me it feels like PPro is being used for a process that's not really in its original scope.

[Bruce Bullis · Accepted solution]

"...being used for a process that's not really in its original scope."

Since our original scope was editing and outputting 160x120 .avi files using the Indeo codec, the Premiere team call situations like that, "weekdays".  

I can't make any specific commitments, but we're investigating exposing more/better transport controls.

[e_d_]

You said it, editing and outputting... I wonder why to perform review & approval in a craft editing app. My guess is "because".

[sberic]

e.d.  wrote

You said it, editing and outputting... I wonder why to perform review & approval in a craft editing app. My guess is "because".

This is a little unfair, I think. To be sure, "review & approval" is part of the editing process, right? Some people may be lucky enough to have a director sit down with them and go over what they want as they work with the edit. Others must work remotely and are building workflows to support that approach. It is natural to want to respond to feedback directly within an application like this.

Think of it this way: Adobe provides the Greatest Common Denominator of editing features to cover most of the bases, and then provides extensibility to allow users to enhance their workflow (as the OP is doing) by building off of a sturdy foundation.

[e_d_]

sberic : Others must work remotely and are building workflows to support that approach.

Which is exactly why almost all vendors of MAM-ish solutions have contributed their share to the "hundreds of panels out there", many of which allow for the workflow described because it is common not only nowadays but has been so for quite a few years. No need to re-invent the wheel, but choose carefully. If anyone's existing, proof-of-whatever solution is so unique, I wonder how long they can support it in the long run. If they start from scratch, they better plan to make their system so good they can sell it to others for many years, because otherwise it's not worth the effort. Everything is eventually deprecated, which we have seen over and over in the fundamental changes in the last 15-20 years of this industry.

It is natural to want to respond to feedback directly within an application like this.

I beg to differ from your opinion. My criterion for differentiation is this: If someone needs to edit clip-related metadata which shall afterwards be available for all users accessing the associated media files, using Premiere as primary frontend might be an approach of little use, because you can have that cheaper and more reliable in a browser. This is the scenario funkelodeon​ has described (my guess based on the use of "clips" instead of "edits" or "sequences"). The probable limitation not mentioned could be, for instance, they do not want to use proxies but need to look at the original hi-res and/or they need to output to a (broadcast) video monitor.

Now, if the need is to review sequences, this boils down to the same thing because even though there are MAMs which can represent a Premiere sequence exactly as you have it in the app, they currently have no means of rendering effects and advanced transitions in the browser (or on the server and then stream it to the browser), which is why the editor will have to render the sequence to a clip.

Sidenote:

Yes, Adobe provides the GCD, which is why I would prefer they start fixing issues which are (not only) IMHO more important, instead of blaming it on, for example, the video card vendors. It is a foundation, and yet sturdiness is what I'm still waiting for (quality is an individual definition, that's okay, but there is something like "professional/industry standard", which ... I will stop here because continuing would quickly be off topic, and I've already discussed this with Bruce Bullis​ and others from Adobe, some of them years ago, and basically we're going in circles.)

[Bruce Bullis]

Specifically, what issues are we "blaming on video card vendors"?

[funkelodeon]

Ideally, I wouldn't have to handle playback controls at all, and those keystrokes would just be passed along to the program monitor by default. Spacebar does this now; the others (j/k/l/left arrow/right arrow) do not.

[funkelodeon]

It's not so much that I don't like the in-built system, it's that our use case requires capturing metadata changes made by the user and pushing them back to a 3rd party system.

Here's the user's workflow:

1. User receives time-based event metadata for clip from external database via panel.
2. User reviews clip, confirming/assessing metadata, making changes to metadata as necessary
3. User creates new event metadata as necessary
4. Upon completion of task, user publishes metadata changes back to database

Metadata events are presented to the users as markers. Because Premiere cannot (at least, as far as I know) fire events when markers are created or modified, the most straightforward way to keep markers and metadata associated is to manage the relationship in the panel. Therefore, playback support is also needed for the panel, otherwise the user is having to switch focus back and forth between the panel and program monitor.

There are other reasons why we wouldn't want to use the standard marker panels in Premiere, such as limiting user inputs in certain situations, etc.

[funkelodeon]

@sberic That's pretty much exactly what's going on