Vixen 3 combined effects

[aussiephil]

Ah, but therein lies our disconnect. Where you're using an effect to fade down the whole display, there is actually a separate sequence-level concept being used to accomplish that. I didn't fully disclose the details of it, so you had no way of knowing that. Conceptually, what you're doing at the sequence level to fade the entire display down is separated from the effect data, so there's no need to negotiate the interaction between them. They (actions such as the fade out) are intended to be applied to the results of all of the effect data, so they come in at the end of the execution pipeline.

KC,

Ok that makes sense but limits the potential real world use of the ramp down effect.

Lets say i have snowflakes on the roof I want to remain chasing till the end of the sequence whilst fading everything else off, based on the above statement the fade out will apply across all effects at the end. i would expect to apply the fade out to a "all lights" group and then say to the snowflake group your chase effect has a higher priority than the fade.

I'm fairly certain i get the concept of the sequence level effect and it would be a good way to acheive something across all channels.
Adding in a Layer or Priority property though would just empower the software even more so people sequencing can work with exceptions like individual items staying on when the sequence is fading down.

Anyway KC, you and the rest of the team are doing a great job, just trying to really make Vixen3 the most powerful object based sequencer you guys can turn out. Trying to look at this from both the mega power user as well as the newbie, these sorts of layer/priority properties would default to standardised newbie functionality whilst providing power users in the RGB world a supremely powerful tool to use

Cheers
Phil

[KC]

I misspoke slightly. While it is sequence-level, it is applied to specified groups, not the sequence as a whole (unless you applied it to all groups or a single root group).

But your use case of exceptions (specifically, needing to remove an element that is included in one of those groups) is notable. Let me ask you this...the more we throw into what it has to do every second, the less it can do in one second's time. For a new user who has a small display and isn't using some of the more advanced concepts, their runtime performance would be just fine. But as a power user with thousands of channels, what is your expected experience? If you're working over the same 10-second span repeatedly, and that 10 seconds is packed with everything this can do involving thousands of channels, is something like a required compilation after changes too much, too annoying?

Thanks for all the feedback, Phil.

[Materdaddy]

I misspoke slightly. While it is sequence-level, it is applied to specified groups, not the sequence as a whole (unless you applied it to all groups or a single root group).

But your use case of exceptions (specifically, needing to remove an element that is included in one of those groups) is notable. Let me ask you this...the more we throw into what it has to do every second, the less it can do in one second's time. For a new user who has a small display and isn't using some of the more advanced concepts, their runtime performance would be just fine. But as a power user with thousands of channels, what is your expected experience? If you're working over the same 10-second span repeatedly, and that 10 seconds is packed with everything this can do involving thousands of channels, is something like a required compilation after changes too much, too annoying?

Thanks for all the feedback, Phil.

KC,

I think this is something that was (shortly) debated in the original Vixen 3.0 Beta 0 thread. I think it went something like this: New users with a few channels and a modest display should be able to use Vixen 3.0 on something a little slower, and if you require a nice new expensive machine to run a large (thousands of channels) show, so be it. The people running thousands of channels can buy a new beefy machine, it will be a small cost in the overall picture of their display.

Phil,

Thank you for all the feedback in this thread. It's like our brains are thinking about all of this the same way with the major exception of you can explain it words much better than I can!

[aussiephil]

I misspoke slightly. While it is sequence-level, it is applied to specified groups, not the sequence as a whole (unless you applied it to all groups or a single root group).

But your use case of exceptions (specifically, needing to remove an element that is included in one of those groups) is notable. Let me ask you this...the more we throw into what it has to do every second, the less it can do in one second's time. For a new user who has a small display and isn't using some of the more advanced concepts, their runtime performance would be just fine. But as a power user with thousands of channels, what is your expected experience? If you're working over the same 10-second span repeatedly, and that 10 seconds is packed with everything this can do involving thousands of channels, is something like a required compilation after changes too much, too annoying?

Thanks for all the feedback, Phil.

KC

It's actually my pleasure to provide feedback.

Let's see if I can make sense today in reply.

Firstly, my exception is likely used by a lot of people in Vixen2 with realising how it would need to work in Vixen3, i quick look at some of my own Vixen2 sequences from a couple years ago showed exactly that scenario.

Now, I understand and take the point that the more we ask the software to do the greater the risk of performance issues.
From my perspective and MD already touches on it in his reply I think the following, assuming a small display is sub 1000 channels and larger pixel displays are likely to be 6000ch plus based on qunatities of pixels I get told are being ordered.

The larger pixel user is already looking/using software like LSP that already demands high end processors like i7's to be usable with those channel counts, Madrix requires similar performance levels, Vixen2 whilst not processor bound does require 8Gb plus of memory so a high end machine is more likely even with Vixen2 for people with these sorts of displays.
All this adds up to the Higher End user is likely to already have or will need to buy a higher end machine anyway so if Vixen3 requires 16Gb Ram, Quad core or greater i5/i7 level hardware then this is just inline with everything else.

Now small channel count displays, if the software can successfully handle processing effects across 10's of thousands of channels then processing even multiple layers for a 1000 channels should still perform on mid level hardware, maybe not the true low end some use with Vixen2 but even those users should see how Vixen3 may require better performing hardware. These days second hand dual core machines are nearly throw out items at auctions.

To directly answer is a compilation of the sequence too annoying... YES, imo it is the thing that was most annoying in LSP till they pushed it into the background, letting the optimiser run as a seperate thread.

If you adopted the concept of layers and layer order attribute then I would suggest that if performance is an issue that you limit the number of overlapping layers on any one group to say four (i explain that number in a minute). Even if you only implement the Layer order attribute and don't yet expose it except in say an effects builder it gives scope for feature improvement.

The four number came from playing with a little bit of software from ETC called pixeltoy, this software can real time render up to four layers of effects to thousands of channels over e131 with very little processor overhead. it largely proves that the processing can be done and done fast and efficiently. whilst it does not implement layer order as an attribute it does order the layers for the purpose of generating the output.... I respectfully suggest that the Team have a look and play with Pixeltoy, it embodies a lot of the concepts i have spoken about in the vixen3 threads.

What's my high end user experience expectation?
I would hate to see an actual "manual" compile step before running when sequencing but appreciate that for final output it may be highly desirable.
I like the current UI and how the effects show/indicate what the effect is doing, the delays apprarent when drawing the effects to the screen certainly appear to be in the UI code and need to be improved.
From a user perspective if i make a complex chase and apply to a group, i then want to immediately move to doing the next effect and i'm less concerned about the visual representation of the effect applied and it could be redrawn with a seperate background thread. this could be an acceptable trade off between performance and hardware maybe.

Hope some of the above makes sense.

Cheers
Phil

[aussiephil]

Phil,

Thank you for all the feedback in this thread. It's like our brains are thinking about all of this the same way with the major exception of you can explain it words much better than I can!

MD - you done a great job so far I've been trying not to tread on your thread to hard and to keep it largely on topic.

Cheers
Phil

[KC]

Phil(s),

Still playing with the priority concept and the exclusion of groups from something affecting an ancestor group. I accept the possibility that I may be over-complicating this, but to fully allow the level of manipulation I believe you're describing, well, consider this scenario:

You are allowed to specify more than a single "filter" (for lack of a proper word), such as the fade-out, that is being applied to multiple groups so that they all fade over the same span of time. Assume filters "Filter A" and "Filter B" are both affecting a set of groups -- "Group 1" and "Group 2" among them -- over different time spans, but those time spans overlap so that they are both affecting the groups during that overlap.

Group 1 wants to opt-out of Filter B.
Group 2 wants to opt-out of Filter A.
All other groups being affected by the filters want to be affected by both.

I don't propose that anything I'm saying in here is proper use of anything (such as priority evaluation), but is only for illustrative purposes.

To start out, everyone has a sane default priority. Filters have a higher priority than the effects they affect so that they affect them (got that?).
Group 1's effect - 100
Group 2's effect - 100
Filter A - 200
Filter B - 200

Group 1's effect gets a priority > Filter B so that Filter B cannot affect it.
Group 1's effect - 300
Group 2's effect - 100
Filter A - 200
Filter B - 200

Group 2's effect will still be affected by Filter B, so all is still well.
But Group 2 doesn't want to be affected by Filter A, so its priority gets adjusted.
Group 1's effect - 300
Group 2's effect - 300
Filter A - 200
Filter B - 200

But Group 1 still wants to be affected by Filter A, so Filter A requires another adjustment to be allowed to do that.
Group 1's effect - 300
Group 2's effect - 300
Filter A - 400
Filter B - 200

But now Group 2 won't be affected by Filter A...and this tug of war continues.

Your ball.

[derekhessman]

Group 1 wants to opt-out of Filter B.
Group 2 wants to opt-out of Filter A.
All other groups being affected by the filters want to be affected by both.

Add an exclude group(s) feature to each filters

Group 1's effect - 100
Group 2's effect - 100
Filter A - 200 X-2
Filter B - 200 X-1

Problem solved

[KC]

Granted -- and that is the most direct solution -- but Phil's wanting to accomplish the task with his more generic priority level mechanism, so I wanted to see how that could resolve the problem. If for no other reason than to see all possible solutions (or, *more* possible solutions).