Page 2 of 2

Re: Device structure

PostPosted: Sat Dec 12, 2015 2:22 am
by AViefhues
Hi together,

I really like the discussion here, I thing this could really improve the tool we all love to work with.

Fist I want to aswer Dennis questions:

Dennis Kuypers wrote:
AViefhues wrote: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)


As Patrick already said, its very painful to switch from one device type to another, after programming a show. And in my case this happend frequently.
The same problem you have if you want a second device run as hot backup, you have to set up all layers manually...


Dennis Kuypers wrote:
AViefhues wrote: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?

AViefhues wrote: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.



I think it is absolutly necessary to have the parameters of cameras and Output in sequeces. But if we found a structure where the layers are not bound to the devices, we would be much more flexible.
My idea for this is somthing like this:
You have a "programming device". Here are all the layers located. So you can arrange the complete show.
And you have the different "output devices"(server, player, pro, std, quad, ...), these devices ony have cameras and outputs.
Now you only have to route the lsyers to the cameras you want.
With this structure it would be quite easy to switch the output deviced if you have to.
I know there are a lot of issues which have to be checked with this structure, like layer count of the devices or different features of the different devices.
But I'm shure we can find a solution which is good for all of us.


As Patrick also mentioned for non expert-users it is quite difficult to know what is possible an what is not. I often hear somthing like: " With PB you can't do,..."
In most cases I can say, that this is not true, but you have exactly to know how to do it.
But unfortunately they choose a different system before.

In my opinion PB is the system with the most options and possibilities.
But out there we have to "fight" against other systems which are more fancy and intuitive.
I don't want to miss even one of the PB features, but after many years of feature development it is time to look at usability and make thinks more transparent.

Maybe it can help if we can come together to some brainstorming days, to discuss these things.

CU
Alex