server
server copied to clipboard
CasparCG
Ember+ Integration
Hi all,
I just wanted to bring up a discussion about an integration of Ember+ Protocol from Lawo. It could be a good addition to the existing OSC Protocol, especially for Broadcast use. https://github.com/Lawo/ember-plus
Let me know what you think about this.
Regards Phil
Hi Phil.
Sure, it would be awesome. We have discussed this already with several broadcasters. One approach is to have CasparCG Clients which talk AMCP and still maintain control over CasparCG. However, some features of CasparCG could perhaps be directly controlled by Ember+? Is this what you are thinking? Du you have any idea on which features you would like to control over Ember+, directly or via a middleware/client?
Hi Jesper I think AMCP is a good way of controlling Caspar, so my thought was to either use Ember+ as an additioal protocol or as a substituion for OSC. In this case I would suggest that it should be implemented directly in the server instead of a middleware. I was thinking about translating OSC to Ember+ in a middleware but if there is an option to support it natively it would be better. Regarding the features I would say as a first step to only have read-only values supported. Something like frame-postition, infos about the layer, media etc.
Phil
After working with Ember+ integrations for the last week, I really see how it would fit CasparCG well. However, I struggle to see obvious benefits over the current OSC functionality. Do you see anything better in Ember+ other than interoperability with other broadcast-centric equipment?
Interoperability with other broadcast equipment and control systems could be a good feature to Caspar, especially since Ember+ was integrated by many manufacturers as well. I guess there could be three options for this:
-
using a translation service OSC <> Ember+ this could be done in the client as well, but personally I would prefer a separate service for that
-
adding Ember+ as an addition to OSC into the server this might be more interesting to people who do not use the standard client
-
only using Ember+ instead of OSC this will lead to compatibility issues with current clients, so might not the best solution to start with...
As I said in the beginning, this is a topic which needs further discussion and investigation. looking forward to hear your thoughts.
@5opr4ni I think that ember+ belongs in the client, firstly.
I agree. I'm not sure how this would fit into the server it-self. I'm really trying to find another perspective on this but I really don't see it yet.
I'm not sure how this would fit into the server it-self. I'm really trying to find another perspective on this but I really don't see it yet.
Not going to go on a rant here but have you tried to do a full implementation of OSC client sided yet? Over 2.0.7, 2.1.0 and 2.2.0 we've changed the structure of the paths just as many times. Then there's the wonky client/server set up, where the amcp client becomes the osc server. Causing multiple amcp connections from the same machine to not be able to use osc at the same time. And let's not forget that it sends out static information at the channel frame rate, which is fine but rather obnoxious.
I guess what I want to say is that a new native protocol would be a good start for discussion of how to properly implement sending state information from CasparCG.
@baltedewit Not going to go on a rant
Feel free! 😄
I can agree about OSC paths having been changed, most notably between 2.1.0 and 2.2.0 and that OSC is not the "quickest" thing to work with, I understand that. But I'm still skeptical about this (or neutral) but that can have to do with my lack of not working with Ember+ that much. I'm just trying to get new picture on this and understand how it would fit into the server! :bowtie:
I guess what I want to say is that a new native protocol would be a good start for discussion of how to properly implement sending state information from CasparCG.
I'm not trying to hold this back, I'm all open for it but is Ember+ the right choice or are there better alternatives for this purpose? I don't know. Nether less what protocol is used (or implemented) decision needs to be taken to do it the right way and stay that way to be consistent.
I think something worth discussing for some distant future release is could ember+ (or something else) replace amcp too? Not doing to do in a hurry, as I too don't know enough about ember+ or other protocols to know what would fit best.
My reasoning for this is that the amcp parsing code can sometimes get confused (play 1-10 loop) or some commands arent very easy to understand unless you know exactly what order the params have to be in (cg 1-10 play 0 lt_demo 1). Having something more structured with each parameter named (eg json/xml) would help with both of these
If someone wants to develop an OSC<>Ember+ middleware, it could be relatively easy with npm . Effectively you could find to pieces for this with https://github.com/evs-broadcast/node-emberplus and https://github.com/colinbdclark/osc.js
@dewiweb thanks for the input, it does look interesting. Personally I am not that good with JS, since I do mostly .NET. But from my point of view the main discussion should be about using Ember+ in the server, probably instead of OSC. I think @baltedewit has some good points. OSC has some limitations and Ember+ could come in handy here.
Just so that you know, we use OSC fifty times a second and we consume these packages in different applications.
Olle, you are right, I use OSC in different applications myself and it would be a pain to rewrite everything, so if Ember+ will be integrated in the sever OSC should stay for backwards compatibility. When you state 50 times a second, the valuable information which is transported is a lot less. The server sends OSC messages regardless if they are new or static information. Ember+ could help here since it would not update those. In the longterm, it might be worth switching to Ember+. happy to hear your thoughts.
Just so that you know, we use OSC fifty times a second and we consume these packages in different applications.
@Phil403, as @5opr4ni says it's heavily used and removing OSC or replacing it with something else is not an option. However an additional protocol could be added in the future (such as Ember+) giving developers the option what to use instead of having one. But before any protocol is added in addition to OSC, maintenance needs to be taken into consideration and the amount of work keeping those up to date.
:)
/Armin
However an additional protocol could be added in the future (such as Ember+) giving developers the option what to use instead of having one.
a config option for either using OSC or any other protocol, or any combination would be great. Only downside will be to maintain multiple protocols at the same time, as they are identical in their usecase.
Regarding AMCP:
I think something worth discussing for some distant future release is could ember+ (or something else) replace amcp too?
I dont think that Ember+ can be used as a way to control the server, but using json within AMCP might be interesting as @Julusian suggested. Maybe worth a closer look.
Only downside will be to maintain multiple protocols at the same time, as they are identical in their usecase.
This has to be down in a smart way meaning minimal effort to maintain both.
