Update multicamMatchFrame to use new clipboard/plist API

[randomeizer]

No description provided.

[latenitefilms]

I only just realised that when you API-ified selectClipInAngle(multicamAngle) you're now just selecting the clip, rather than clicking the preview audio and video buttons.

This is fine for "Reveal Multicam in Browser", however, I feel like selecting the preview audio and video buttons is handy for "Reveal Multicam in Angle Editor". Reckon you could add these preview buttons to your API so that we can trigger them if "Reveal Multicam in Angle Editor" is triggered?

[randomeizer]

I've added selecting the video preview. The main challenge with the audio monitoring button is that unlike video, it's a toggle, and clicking it may actually turn audio monitoring off. Also, personally, I'm not sure I would want or expect audio monitoring to change automatically - I often have my audio from an independent source, and switching that would be annoying. It's a tricky one.

[latenitefilms]

Ah right - no worries. I didn't notice that the audio monitoring button is a toggle!

You could use the "Angle Switch Dropdown" (as opposed to the buttons) - as it has a "Monitor Audio" switch.

However, very good point - we probably don't want to toggle audio monitoring by default. Maybe we should have a menubar preference?

[latenitefilms]

FYI: Monitor Audio Switch:

[randomeizer]

Yeah, thought of using the dropdown. I'm still not sure what the 'correct' setting to use would be though anyway. The other thing is, when you enable 'Monitor Audio', it doesn't disable 'Monitor Audio' on other angles. In general, it's pretty unpredictable.

[randomeizer]

The other thing that happens currently is, if I'm in the project timeline and have a multicam selected, but the playhead is not over that clip, then activate our 'multicamMatchFrame', it's possible that the playhead in the Angle viewer is not over a valid clip in the active angle from the clip. When that happens, it will open in the Angle Viewer, then pop up a dialog box complaining that it can't 'Reveal in Browser' (which is true, since there is nothing to reveal).

I'm not sure if that's the most user-friendly response. Dialog boxes are kind of a pain, but on the other hand they do actually tell the user why something didn't happen.

So basically, its working as it should, I'm just not sure it's the best user experience. Thoughts?

[latenitefilms]

Yeah, thought of using the dropdown. I'm still not sure what the 'correct' setting to use would be though anyway. The other thing is, when you enable 'Monitor Audio', it doesn't disable 'Monitor Audio' on other angles. In general, it's pretty unpredictable.

Ah, right. Yeah - let's just ignore audio monitoring switching then for now.

So basically, its working as it should, I'm just not sure it's the best user experience. Thoughts?

I agree that dialog boxes are a pain - really we should only ever use them when there's an unpredictable error (which is most errors at this early stage of development!) or when we need a user response.

Can we just go back to how it was originally, and check to see if the "Reveal in Browser" exists in the menubar (in all the different languages)? Either that or add some detection to make sure if a clip is selected that the timeline playhead is "over" it?

Maybe what we should do is re-work the menubar script and create a menumap.json for each language, or now that we're pretty good at reading plists, we could just read all the language plists and cache them in hs.settings?

Either way, yes, I think if "Reveal in Browser" isn't available in the menubar, then if someone presses a FCPX Hacks shortcut that relies on "Reveal in Browser", it should fail silently (i.e no dialog box - just an error message in the console).

[randomeizer]

We can easily ignore the case where 'Reveal in Browser' is disabled - we explicitly display the dialog now if it doesn't. We just have to remove the error message code from the function.

…

On Wed, 11 Jan 2017 at 2:43 pm, Chris Hocking ***@***.***> wrote: Yeah, thought of using the dropdown. I'm still not sure what the 'correct' setting to use would be though anyway. The other thing is, when you enable 'Monitor Audio', it doesn't disable 'Monitor Audio' on other angles. In general, it's pretty unpredictable. Ah, right. Yeah - let's just ignore audio monitoring switching then for now. So basically, its working as it should, I'm just not sure it's the best user experience. Thoughts? I agree that dialog boxes are a pain - really we should only ever use them when there's an unpredictable error (which is most errors at this early stage of development!) or when we need a user response. Can we just go back to how it was originally, and check to see if the "Reveal in Browser" exists in the menubar (in all the different languages)? Either that or add some detection to make sure if a clip is selected that the timeline playhead is "over" it? Maybe what we should do is re-work the menubar script and create a menumap.json for each language, or now that we're pretty good at reading plists, we could just read all the language plists and cache them in hs.settings? Either way, yes, I think if "Reveal in Browser" isn't available in the menubar, then if someone presses a FCPX Hacks shortcut that relies on "Reveal in Browser", it should fail silently (i.e no dialog box - just an error message in the console). — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#190 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADbEw0RXMn0xOzeehVZv04DIbdqvod3aks5rRF4LgaJpZM4LdtP3> .