Device structure

[aquapixs]

Hello everyone,

I have quite an intense feature idea and I would love to gather some opinions from other users, as well as Coolux staff if this would also make sense in your eyes.

Kill the entire device structure!

Here is the idea for a easier workflow for programming. No more devices with Layers and Tracks. Only leave the local device which would have 2 layers as default. And it should also be toggeled into preview.
Right mouse click would allow to add more layers, tracks, lights, cameras. (Ideally we also get rid of video and grafic layers - make the all the same)
Now the entire composeting work will happen in this section and can be done without knowing what type of system you will have at the end.

To send your composition to a connected device, you now add the devices connected to the manager into your system. But the client device actually has only the output which is assigned to a certain pixel area in the composition.

This workflow would kill a lot of useless pain like:

- virtual site
- clone device (a long pointed feature wish)
- every anoiing message "node cannot connect due to incompatibility"
- weird camera and output settings
- double work due to same content in different devices
- issues when changing clients from STD to PRO (did you ever tried to take a show from Quad Broadcast Pro to Quad Server Pro? Same features on both, the only difference is the hardware. But you need to rebuild the whole layer structure from scratch. Bloody Nightmare)
- toggle preview of single devices (I had a show with 50 players, it takes forever to toggle them all into preview)
- share layer texture thru different devices (another feature wish)

Plus a few general benefits:

- taking same timeline programming to different client setups
- simple backup setup
- more flexibility
- easier to understand the programming structure
- easier to be explained in trainings
- very straight forward programming

I know that this would kill the whole thing with LT, STD and PRO decices. But I do see this as a benefit as it is much easier to explain this to clients and people planing setups.

So, all your thoughts and ideas are higly appreciated.

Thanks

Patrick

[JustynR]

Love it!

[lucken]

+1

[AViefhues]

Hi,

I agree with Patrick.
There are a lot oft things that are realy inconvenient.
I like the idea to seperae the programming/compositing from the cameras/outputs.
On the other hand I'm always happy to have easy and clear way to control the performance of the sites.
In moste cases it is not a good idea to load/render all contents on all machines.

Alex

[aquapixs]

I agree with Alex on the performance issue, but if It is done smart the system would automatically only render the chop of content needed.
Or you use the checkboxes to determine which machine renders which file. Same like right now for the virtual sites. But I like the automatic idea more as it would be much more straight forward.

Cheers

Patrick

[AViefhues]

It would be great if there is an automatic solution, but I think thats not possible, especially if you are working with active parameters.
In this case the system could not know witch content is needed on witch machine.
But maybe there is a smart way to route layers to cameras.
I think with the new structure it could be better to tell a camera, witch layer is needed, instead of telling a layer in witch camera it should be rendered.
Or is it better to put the cameras in the programming part and only separate the outputs?!?!

I really think this would be a huge work-flow improvement.

Alex

[plbrunet]

+1000
I couldn't agree more with you Patrick!!

I've been wanting to start a thread about this myself so I'm glad you bring this up and feel this way as well.

This device concept is one of the reason why programming in Pandoras Box can be very time consuming and way more complicated than it should be.
Changing this would greatly reduce the amount of programming time and number of headaches.

[Dennis Kuypers]

Hello Patrick,

Here is my personal opinion on the subject:

I love the philosophy behind Pandoras Box where you get control over as many aspects of the system as possible and you can do things that the developers didn't plan for before. This gives you a lot of power and flexibility, but makes it harder to fully embrace all the features.

The "weird" Output Setup you talk about got incredibly flexible in the last few revisions. You can now work around so many limitations of what was impossible before. Actually the Output settings are a good example to explain why I like it the way it is. (Or at least why it's a good baseline to improve)

Users that simply want to see a video file on the output don't have to bother with the settings at all. Everything (should have/) has sensible defaults and (should) work out of the (Pandoras) Box.
If you want more, for example a keystone, geometry or blending then you put a mesh on it or use the keystone in combination with the soft edge.
If you need even more then you can dig into the Inspector settings and render engine configuration. For even more complex situations you can dig deeper into the ways it works until you finally realise that the output is actually just some kind of a Graphic Layer that Shares the Texture from the assigned camera, has preassigned keystone and soft edge effects and lives in a secondary render pass/composition. What do you do with that information? It's up to you. I used it a couple of times to cut down the requirements by one output or just to be able to blend layers in a smart/fancy way. (Remember the Advanced training with the 3D Planets Rotation Scene? You can render the stars-background with native resolution into the output pass by using the fill mode in conjunction with the "alpha backbuffer on output pass" to have it in the background of all of the planets.)


A "automatic layer to server mapping depending on output viewport" would probably hurt a lot of people. By being very explicit about where you are putting content you are actively thinking about the ways the system works. Because we are doing everything in realtime and users do use active values there is no good way to automagically "validate" if a show can run like this without performance problems.
Even now when users have to be very explicit about where videos go they get surprised by performance. If you were to abstract a lot of that away that would be more like a Black Box and it gets pretty hard to troubleshoot where the problems are (and even harder to solve them!). It's never a good idea for a system to assume that you are doing stuff in one specific way, there should always be a switch that lets you override behavior. (That is my theory, even though I make it sound like it is the one universal truth)


I understand that there are things that can be improved upon and in the past we have shown that we add features to ease workflows (Startup Screen, Show Configuration Defaults, Playlists, Player license stacking, Opacity defaults to 100%, additions to the Inspector Tab, extended Text Assets, slightly relaxed Virtual Site license limitations...).


I think that the current system with all its complexity allows for awesome setups that you just can not do with a "3 buttons and a fader"-type interface. Currently Pandoras Box is probably on the bleeding edge when it comes to features and flexibility. It is a complex system that, once mastered, allows you to bring your creativity to the screens (and that usually in 10 different kind of ways).

I started almost all the sentences with "I", mostly because I am not a creative writer and also because this is my personal opinion.

Please also take into account any downsides that such a system would bring with it.

Dennis

[Dennis Kuypers]

Hello guys,

I have a couple of questions for you. I'd appreciate if you find the time to respond. (Especially Patrick, you wrote the most of the text, sorry )

Patrick

Kill the entire device structure! [...] Here is the idea for a easier workflow for programming. No more devices with Layers and Tracks.
Only leave the local device which would have 2 layers as default. [...] Right mouse click would allow to add more layers, tracks, lights, cameras.[...]To send your composition to a connected device, you now add the devices connected to the manager into your system. But the client device actually has only the output which is assigned to a certain pixel area in the composition.

You are not killing the device structure and you are also not abandoning the devices/layers at all. You are just restructuring them to something that is practically a supercharged virtual site. What is your opinion on having multiple of those "local devices" for example if you have two different rooms controlled from one manager. Then it would be more complicated to separate them by routing instead of just having two "local devices".

- share layer texture thru different devices (another feature wish)

That is what a virtual site should allow you to do. I commented in my previous post on why a "magic" feature that allows inter-site-sharing would be a bad idea. (Hiding what is going on, etc.)

(Ideally we also get rid of video and grafic layers - make the all the same)

The number of layers is currently an integral part of the different licenses. This allows you to get a cheaper license with less video layers. Graphic layers on the other hand are "free".
I don't see a problem there, its more like you have added benefit from the separation of Video and Graphic layers, why do you want to get rid of this? Can you elaborate on what exactly the problem is? On a Server Pro you can use the unlimited video layers, then you don't have to use the graphic layers.

[...] can be done without knowing what type of system you will have at the end.

If you don't know what kind of system you'll have, how do you determine which features you can use?

- every anoiing message "node cannot connect due to incompatibility"

We are always happy to take suggestions for different formulation of our error messages. They tend to be technical, because programmers write them.

- clone device (a long pointed feature wish)
- issues when changing clients from STD to PRO (did you ever tried to take a show from Quad Broadcast Pro to Quad Server Pro? Same features on both, the only difference is the hardware. But you need to rebuild the whole layer structure from scratch. Bloody Nightmare)
- taking same timeline programming to different client setups
- simple backup setup
- more flexibility

I understand the issue there, do you have any suggestions on how we could solve this in the current Pandoras Box system?

- weird camera and output settings

What is weird about them?

- toggle preview of single devices (I had a show with 50 players, it takes forever to toggle them all into preview)

You could solve that with a View right now. But it still is a good idea to allow multi select toggle preview.

I know that this would kill the whole thing with LT, STD and PRO decices. But I do see this as a benefit as it is much easier to explain this to clients and people planing setups.

If we remove the lt/std/pro differences then we remove flexibility regarding budget of different customers. If you prioritise the ease of explaining to clients and people planning setups then you can probably offer them a Server PRO only solution, then they don't have to think about all the other possibilities.


Justin & Luc

Love it!

+1

Why so? What exactly do you like? Did I forget about anything in the list at the end of the post?


Alex

I agree with Patrick. There are a lot oft things that are realy inconvenient.

What things do you mean? I would love to hear about them (if not already reported)

I like the idea to seperae the programming/compositing from the cameras/outputs.

You can use two sequences to split them up. Do you see any added benefit in not having the camera & output setup in the sequence? What parts do you think should be excluded from the sequence then?

I think with the new structure it could be better to tell a camera, witch layer is needed, instead of telling a layer in witch camera it should be rendered.

So you are wishing for a layer checkbox in the camera inspector as well? Apart from that it doesn't sound like the two ways differ.


Pierre-Luc

+1000
I couldn't agree more with you Patrick!!
[...]
This device concept is one of the reason why programming in Pandoras Box can be very time consuming and way more complicated than it should be.
Changing this would greatly reduce the amount of programming time and number of headaches.

What exactly is the problem with the devices? Can you elaborate on this if your feature requests are not mentioned in the list below?


Summary / Feature requests

• more flexible manifestation of nodes on sites
• less technical words, so let me try the first one again: allow pro/std/lt to be used interchangeably
• clone sites
• site multi selection + toggle preview
• make output settings less weird
• allow device routing selection in camera inspector
• Virtual Site: add new sites after creation
• any more?

Regards
Dennis

[lucken]

Hi Dennis,

This what i like to see solved/changed:
- clone device
- issues when changing clients from STD to PRO,.....

[Dennis Kuypers]

- issues when changing clients from STD to PRO,.....

I would love that as well. How do you think we can solve this? I have a couple of ideas, but I first want to see what you have.

Regards
Dennis

[lucken]

For example:
- Exchanging products between different manager versions: it should open the project, without any error, but offcourse just respecting the numbver of sequences available in the license.
- Exchanging projects between different versions of players/servers, same as with the managers, but respecting the number of video layers. This means that there is no difference between a Dual server and a Dual broadcast server.

[JustynR]

I agree...

Changing between STD & PRO and PRO and PRO would be nice... for example..

I have started programming a show on a 2 Player PROs with 1 dongle each. And OOPs, now I need to put 2 dongles in 1 machine...

Cloning 1 or 2 machines to another type would be great.

I've had another show that I programmed on a Server STD in the office.
I had to move to 2 different machines on 2 different shows.
I had 1 show with a Server PRO - shouldn't be a problem right? There are clearly enough layers - but I still had to spend over an hour getting the layer structure built and everything copied over on multiple timelines.
The other show had a Quad Server STD - also shouldn't have been a problem... just 2 extra outputs... but had to do the same thing.

As well - the Managers.
Going from a LT to a STD works - but we get an error about the local node not being compatible every time we start the program.

I used to fix it by removing and re-adding the "Local Node" - the warning went away. Now we can't remove the Local Node because of the Preview.

=================================================================================

As for 'killing the device structure':
I agree that performance could suffer if every machine played every video.
I think everyone will agree, the LAST thing we need are more tabs with more checkboxes to select which sites render and which don't!

This would just add more programming and even more complexity to an already very complex process. Not to mention the time it'd add to already tight schedules.


After working with another system for a little while (not by choice) a few ideas came to mind:

Perhaps the option to make a layer "dynamic" or not.
If it's only going to be displayed on 1 output, only render on that 1 computer.

If it is a 'dynamic' or 'interactive' layer that may go to another output, have that layer(s) render on all machines.

The upside to PB over the other system is that the content is already on the hard drive of every machine by default, and even if you're in free-run, it'll run in sync - and it will only have to load the video, not spread too.
In PB I don't think I remember even 1 time when loading a video not at the beginning it didn't snap to the correct part in the video and play in sync with the other machines (like when a node comes back online after a reboot).

I think to mitigate performance issues, by default the layers only render on the output that they appear on, then an option to turn on a "dynamic mode" or have the video automatically render on other sites when the Scale or Position attributes are activated.


=========================================================================================================

Pandoras Box is still very intimidating to most people who aren't pros at it.

There are other systems that aren't as capable, but the GUI looks pretty and the features have nice names.

Because of these 'nice names' and pretty interfaces, these systems are winning out over PB on shows that used to use PB.

One show in particular has been using 8 Server PROs for a few years.
This year the client chose a different system because of a specific feature that it has.

It is a feature that PB has been able to do for a few years now but they haven't been able to achieve with it because of the learning curve associated with it in PB.


Cheers,

[malkuth23]

Ok... If we are totally redesigning then here is my idea:

Rather than a site you should be able to create a "space" (or scene, stage etc... some friendly sounding word).
Each client has cameras available. You can drag these cameras into a space. Then whatever plays in the one site will only be seen by the cameras in the space created.

Whenever you add a video layer to a space you deduct one video layer from the client layer count (adding layers should be super easy - just a series of + buttons that quickly add different types of layers).
Each client shows a running count of how many video layers it still has available. This way it is like the license buys you a bank of video layers and does not force you into a structure that might not work for you.

for example:
If you have a Dual Player Pro and you make 2 spaces each with 1 camera/output and add 3 video layers to the first space you would still have 5 video layers left for the second space.
If you have 2 single Player Pros you can do the exact same thing!
If you put a camera from 2 different clients into 1 space and then add a layer it will deduct 1 video layer from each client's layer count.
You could even mix Servers and Players, but the effect list would go to the lowest common denominator.

This way you could essentially create virtual sites or break clients into individual spaces without the user having to think about the technical details.
Friendlier terms is good for sales team and new users.
Greater flexibility is better for power users.

Hooray!

[aquapixs]

Hi everyone,

Good to see that this started the conversation I wanted to see. Many nice ideas and in overall a feedback which shows that the current structure does not apply to everyone needs. And it also brings up a couple of issues to a lot of people.

But let me first answer Dennis questions and then I will add a few comments and ideas.

You are not killing the device structure and you are also not abandoning the devices/layers at all. You are just restructuring them to something that is practically a supercharged virtual site. What is your opinion on having multiple of those "local devices" for example if you have two different rooms controlled from one manager. Then it would be more complicated to separate them by routing instead of just having two "local devices".

Maybe I'm not killing the decice structure, but I would like to see the strict connection between layers, cameras and outputs to be killed. Right know with the option to add new cameras the structure is half way killed anyway. But the fact that a layer is always connected to a certain output is limiting the felxibility if you work with multiple machines. If you only have one client the whole thing works quite good, but as soon as you add more clients or change the client licences you can be screeded up very easy. As a lot of people mentioned the main issue is that you might get a different licencse setup between programming and the show. Or you do need ro programm a show before you even know the final license.

I do not agree that routing will get more complicated. All your layers live in 3D world (or half 3D world on players) in your working canvas (or whatever nice name you find) the camera determines which part of that layer is send to the output and the output adjusts the camera image to the needed setup (keystone, SE eg) So far this is actually how PB works right now, but with the downside that Layer 1 on Client 1 cannot be seen from Camera 1 on Client 2, which in my opinion does not make much sense. And the Layer 1 is also connecte to the license of Client 1. So call it Supercharged Virtual Site or whatever.
Think of a Advanced Training and the way how complicated it is to explain how Layer, Camera and output work together. Now add a second decice to the explanation and make the people understand why the content which you like to see on all 4 outputs need to be on Layer 1 on client 1 and on layer 1 on client 2. It would be much easier to explain the the content lives on Layer 1 and that you position the cameras on Layer 1 to determine which output shows the content.

That is what a virtual site should allow you to do. I commented in my previous post on why a "magic" feature that allows inter-site-sharing would be a bad idea. (Hiding what is going on, etc.)

How do you build a virtual site out of Players and Servers? At least now you cann combine dual and quad into one virtual site, but no way to combine different devices together. And here again we need the device structure to be killed.

The number of layers is currently an integral part of the different licenses. This allows you to get a cheaper license with less video layers. Graphic layers on the other hand are "free".
I don't see a problem there, its more like you have added benefit from the separation of Video and Graphic layers, why do you want to get rid of this? Can you elaborate on what exactly the problem is? On a Server Pro you can use the unlimited video layers, then you don't have to use the graphic layers.

Just to simplify things. Projects with a lot of layers, and it is not unusuyl to end up with about a hundred layers, can get very confusing. And it is also adding a unneeded limitation. Why can't a layer be a layer?
I do agree with the fact that this would screw up the licencse model, but in my eyes this is anyway way to complicated to undertsand. I just spend half a day to explain this structure to a video planing guid to be able to spec what is needed for his show. Most of the people anyway work with players already as you only need server features on 5% of the shows.
If the structures needs to stay you can also work out the layer count idea Matt brought up. That would also work very nice.

If you don't know what kind of system you'll have, how do you determine which features you can use?

As I said before, 95% of the shows can be done with Player features. I don't know how often other use certain features, but this is what I need (just looking at the difference between Players and Servers):
- color adjust FX (and I think I did ask for a real color adjustment FX already / please look at Lightroom and make all these settings possible in one FX)
- share layer texture (really one of the reasons to use a Server, so most of the time I work around that)
- Text Engine

To be honest, I havent touched particle fx, render history fx or anything like that since I left Coolux.

We are always happy to take suggestions for different formulation of our error messages. They tend to be technical, because programmers write them.

I is not the wording which bothers me, it is the fact that this message comes up so often.
Justyn already pointed out the issue when you swap manager licences and the inconsistent local node. This is anoying like hell and I would actually point this out as a bug. Why is the local node different from manager to manager license?
Everytime I preprogramm a show on an offline manager I need to rebuild the structure on the local node. And if you are running several audio tracks on the manager, which I do in 90% of my setups this takes ages. Du to this I actually moved over to use a Player just for audio playback. This computer just sits next to the manager and drives an audio card. But it is quite hard to explain you client why he needs to spend money for that.

I understand the issue there, do you have any suggestions on how we could solve this in the current Pandoras Box system?

Here are my ideas:

Clone device / change license:
more or less the same thing like copy paste fx structure, but copy paste a decice with all its settings. Imagine you did run a show on a Quad Broadcast Pro and everything is programmed with quite a complex sub camera setup to be able to color correct seperate pieces of the content due to different LED screens. So there are about 30 Layers and 10 Cameras. Each Layer has a different setting regarding where it is rendered and who the routing is. Now you do the same show half a year later but this time there is a Quad Pro instead of the Broadcast Pro. This causes to rebuild the whole structure including routing, FX, Cameras and Croppings. Took me about 2 hours.......
Now you add antoher Quad Server Pro which should to the exact same thing the like the first one. Just because the added another set of LED walls. No chance to clone the first device, you need to rebuild the structure again.
If you like I can provide the showfile for this setup or invite to the TV studio, next show is confirmed in March

Development wise it cant be that hard to offer a copy or clone device. Just setu another device with the excat same settings. And it also cannot be such an issue to change the license type of a same working decive like Quad Pro or Broadcast Pro. On Software side there is not a single difference in between these to clients .

Simple Backup setup:

easiest idea: main and backup IP adress in the inspector.
I don't want to setup a virtual site or a seperate decice just to have a backup machine to do the same thing like the main.
With the IP setting I could simply hook up a backup client into the main one with just a click.

Weird camera setup:

it gets very weird if you need to work with different cameras to send different chops of content to LED screens.
Same TV show like mentioned before:
Content is 3648 pixels by 600 pixels. A total of 6 outputs to different screens, but due to the setup I need to be able to colour adjust more chops of content that I have outputs. But I cannot cut the content down or drop onto different layers as I also need to adjust colour on the full content. The whole thing works with sub cameras and cropped sub layers, but as I cannot route multiple cameras into one output I need to route the camera back to a layer and combine these layers with another camera to be send to the output. Again, I'm happy to provide the showfile.

Toggle preview:

Yes, I can solve that with a view, but I would need to build several views to which takes a lot of time.

I do agree with Justyn. A lot of things in Pandoras Box are very complex, which is good on the one hand as it offers a lot of options. But it also kicks us out of a lot of shows as people do not undertsand how to work with it. There are a couple of higly skilled pros which are able to do almost evrything with PB, but the wide range of people are overwhelmed by the amount of options and the can get lost very fast. The problem is that in this case PB did not run the show as expected and most of the time the system will be blamed as this is the easiest part. And the more this happens the more jobs will move to other systems. And this is something to be very carefull with, if we all want to continue working a lot with PB.

It is not the first time that I point this out, but the users out there need more feature to simplify their life. Do not add more stuff people don't need or which are only used on a very few shows. Add features which improve the workflow and which are increasing programming speed on PB. This is the most important thing for a great future of a great product.

Cheers

Patrick