PCO Integration Improvements

[schplay]

This PR contains several improvements/additions to the PCO integration. These updates are important for users coming from ProPresenter as they are hugely important for those that heavily utilize Planning Center Services across multiple service types as well as depend on the PCO "live" timing. My church falls into that category and the lack of these features has prevented us from even being able to seriously consider switching to FreeShow. I hope that these will also help other users be able to make the switch.

• New PCO Timer type allowing live PCO service time sync.
• Updated wording for countdown "overflow" to make it easier to understand.
• Added PusherJS to support PCO "live" events for new PCO Timer.
• New PCO Service type selection in the PCO config to allow customization of which service types/folders are auto-synced. This also fixes PCO import for all accounts with service type and folder structures that don't match the default assumption the app previously made which in some cases made the feature unusable.
• New ability when manually creating a Project to select any upcoming PCO service that would not have otherwise gotten synced and created.
• New manual refresh button when viewing a PCO Project to force re-syncing to get updates from online.

These were tested and are working well on Windows.

[vassbo]

Awesome! This is great.
Can we instead of having it as a "Timer", we should just have it as a dynamic value.

[vassbo]

Also we should use Socket.IO instead of PusherJS because that's already being used in the app.

[schplay]

@vassbo concerning "Timer" vs a dynamic value I'm not 100% sure that I understand. Do you mean to have it be a "Variable" under the "Functions"? I honestly think having it as a "Timer" makes the most sense for users since that's essentially what it is; it's just controlled by an external service instead of logic within FreeShow. Furthermore if we were to change it to being a "Variable" then I don't currently see a way to display those on the Stage Display and we would need to find the best way to add that (presumably an entirely new "Item" type).

Unfortunately the existing Socket.io implementation isn't compatible with the Pusher events used by PCO so unless I'm mistaken there's not a way to replace one with the other.

[vassbo]

Right click any textbox and you'll find "Dynamic values" - timers and variables are here as well.
Because it does not need to be controlled, we just need it as text and not as an interface.

[schplay]

@vassbo I see, I wasn't aware of that feature. After looking at it I have some questions about how you suggest I would make that change. For instance, would it be a new dynamic value under the "Project" group or would it make sense to be a new "PCO" group? Also, if making this change from a "Timer" then how would we configure the early warning and overflow settings that are native to "Timers" but presumably don't exist for text?

[vassbo]

I guess if it needs many values it can be it's own "PCO" section, if not it can be put in the "Project" section, you can choose.

Textboxes and dynamic values work well with "Conditions" where you can show/hide certain textboxes based on the value of a dynamic value. So it's up to the user to configure multiple textboxes with different colors here, you can just leave it as plain text.

[vassbo]

I guess the condition would need an update to allow setting "is above"/"is below" if the dynamic value can be parsed into a number.

[schplay]

I'm going to be honest, that sounds like a lot of work just to duplicate existing functionality that EVERY single person that uses this PCO timer will want. I think having it available as a Dynamic Value is a good idea but in the current implementation it already is since it's a timer. I also think new "is above" and "is below" modes for the conditional logic are good ideas but I think requiring every user to build their own logic there just to get the existing timer functionality is bad UX.

[vassbo]

Then we should just make a default PCO timer stage display (and/or template) that is created when the user connects with Planning Center, that can also be used as an example.

[schplay]

I don't see any concept of a template for the display layout or display items so presumably your preference would be to have the application programmatically create a new PCO stage display for the user when they initially connect the PCO integration?

[vassbo]

Correct.

[schplay]

@vassbo the PCO timer has options that change how the countdown is calculated: "End Item On Time", "Full Item Length", and "End Service On Time". If rebuilding the Timer using Dynamic Values and Conditions, how would you suggest we handle those options? This is something that may need to be changed on a regular basis by operators and the more we flesh out this solution of building logic blocks the more of a nightmare that sounds for regular volunteers that would need to use this.

[vassbo]

I think we can just have seperate dynamic values for each of them all live at once.

[schplay]

I'm just thinking about the perspective of a regular user/volunteer. If they're told to update a timer mid-service to display "Full Item Length" for a specific moment/time during service and then change it back to "End Item On Time" afterwards, having that be a simple dropdown item on an actual Timer that is named "PCO Timer" is simple and easy to understand/remember. With what you're proposing, instead they have to edit a stage display, be trained on and understand Dynamic Values, and then manually change out those values while being careful not to make any typos or other mistakes that affect the stage display. That's going to be difficult for some people to grasp and remember let alone carry out quickly and without mistakes.

I just don't understand how this is a better solution or what we gain by changing this timer from being an actual Timer. There is already a concept of different types of timers in the application and there's a reason that they were built in the way that they are instead of all being built like you're suggesting we do for this one.

[vassbo]

I think if it's a Timer, or a Dynamic value I would create seperate Stage displays for the different timers and use actions to automate changing between those so that should not matter in the use. Only difference is in the setup.

[vassbo]

In my mind since those timers "already exists", it makes more sense that they are a dynamic value rather than you having to "create" a new timer that already is running somewhere.

[schplay]

I think if it's a Timer, or a Dynamic value I would create seperate Stage displays for the different timers and use actions to automate changing between those so that should not matter in the use. Only difference is in the setup.

I think that could work for some people in some situations but it doesn't cover all scenarios and carries it's own drawbacks. For example, that would require editing multiple stage displays anytime you need to update one.

In my mind since those timers "already exists", it makes more sense that they are a dynamic value rather than you having to "create" a new timer that already is running somewhere.

This is where we fundamentally differ. While the instructions for the timer (IE the amount of time being counted down) are coming from an external source, the application is still handling the actual counting down of time. In that sense it's identical to the other "Timer"s. The difference is that instead of manually entering an amount of time to count down, you select a PCO Service which will dynamically update the amount of time that the application should count down as you progress through a service. The way that the user thinks of it, interacts with it, etc is just like the other "Timer"s and is also how other presentation software treats it. While I think the Dynamic Value, Condition, and Action features in FreeShow are great I also think that trying to use them instead of a "Timer" to implement a timer doesn't make much sense.

[vassbo]

With a bit more setup you can actually use just one stage display, with for example three different textbox timer items, and create toggles with Variables to turn them on/off via Conditions. So it's not an issue if the person setting it up knows what he is doing.

But okay, about Timers it sounds like you would need to update the timer for each new PCO service? That sounds unnecessary.

With dynamic values it would make sense they would just change automatically based on the opened project so you don't need to change it.