Wishist: Highlight should override effects

By override effects, which parameters are you desiring? Intensity and color only? 

Yes, that's my preference. But it should probably just override whatever parameters are in the highlight preset or fixture profile. Some people like highlight to open the beam as well, but not me.

You can put a stop effect flag in the highlight or lowlight preset on the specific channels and parameters you want to not be effecting.

Thanks! I've just been informed of that workaround, but it's pretty clunky, as you have to go in and change the preset every time to you patch a new fixture to your show. And due to a bug(?) you can't just Select All and add a stop flag, if there is already a stop flag somewhere in the selection.

I looked into your report regarding setting a STOP flag for a channel range where one channel already has this flag. I can see this as well and will start a discussion with the team.

I looked into your report regarding setting a STOP flag for a channel range where one channel already has this flag. I can see this as well and will start a discussion with the team.

Awesome, thank you! Does ETC have a position on my concerns about Highlight? I can't believe I'm the only person who thinks Highlight should override effects on parameters the same way it overrides regular values.

That's a feature request and as such should be posted in that section.

It has been. Waiting for a reply.

community.etcconnect.com/.../a-few-feature-requests-that-have-fallen-through-the-cracks

It has been. Waiting for a reply.

I think it's totally unacceptable that so many problems are told to silo themselves to the feature request forum, where there is basically zero ETC engagement. As far as I can tell it's literally zero since Anne left 4 years ago.

community.etcconnect.com/.../option-to-stop-intens-effects-during-highlight

There is a difference between bugs (things that don't work as expected and intended) and those things that people wish worked differently. And as a result attention is given to bugs over features - which makes sense to me. And that is a prime reason for why general discussions should move over to the appropriate forum topic to receive the correct level of attention.

When it comes to bugs (broken, unexpected behavior, etc) that are actual flaws in how something was implemented, there is indeed a silo for that and ETC has been extremely responsive to those. I'd say many of my bug reports have been addressed faster than expected.

On the other hand, there are things like this, a wish, a desire for something to work differently than it was designed to do. As with any software development, there is always more requests than time available to work those requests so they need to be prioritized. As such, things like the feature request silo is a great tool that ETC uses to help understand how many people agree with your wish or desire. There are things that a few of us would really find useful -- there are a few requests I've sent in that I believe are only going to benefit myself and my workflow, and probably few other people, so I wouldn't expect (no matter how much sense it makes to me) that ETC would implement those feature requests. However sometimes I've submitted a request and a lot of people have agreed. You just never know unless people have an ability to vote for such a feature.

While there have been some very long-standing requests (tap tempo for example), I can see very active development both in terms of bug fixes, but also in the sense of feature development. A cursory look the release notes is very telling of the work being done here. 

I'm glad you find ETC responsive about bugs, but I have been extremely dissatisfied with their support in this regard as well in the last few years.

I just want the bugs to be acknowledged and given a bug number to look for in the patch notes, but even when they reply (which is not a given, whether sent in via forum or email), they only occasionally acknowledge the issue and follow up with the bug number. I think I have 7 open issues that I haven't been given bug numbers for, and 3 of which I have received no reply at all to. This is excluding the additional 4 currently unresolved bugs I discovered and have received numbers for.

There are only like 6 people actually working on the software, so I don't expect these things to be resolved quickly unless they're critical to playback, that's fine, but there are more support people, and they will never get resolved if they don't make it into the Eos internal bug tracker.

^This.

If you look up above, ETC responded to my in-comment bug report on this 6-year-old post that you can’t add a stopeffect flag to a selection of there is already a stop effect flag in that selection. They said “I am starting a discussion with the team,” thanks.

But when I specifically replied, what’s ETC’s position re: the Highlight function stomping effects, and highlight being a self-terminating state that holds selection like every other moving light console, they blew me off to the feature request section, where I ALREADY posted this request 6 weeks ago.

I just did a quick look and recently of the 18 bugs I identified that were legitimate "shouldn't work this way" sort of things, 10 have been fixed within a reasonable time (weeks to months), only 8 are still outstanding.  And ONLY ONE has yet to get any response from ETC. Only twice have they responded with what I felt was a bug was something they're doing intentionally, but of course, I could take it to the feature request -- where no less than 4 of my 13 of my requests were downvotes to zero or lower -- which means that while I might find it helpful or necessary or obvious there are more people who want the operation to remain the same. Humbling for certain, but again, it helps see how many people really want something. But some of mine have low single digit support. That being said, there are those with hundreds of votes, and obviously development effort should go towards those first from a big picture standpoint.

Just a bit of perspective on the process.

Hi Ethan and Taylor - 

A few things going on here I'd like to unravel. Indeed, we differentiate bugs / critical issues from feature requests on this forum, and who handles each internally. Bugs prevent shows from being done in-the-now - they are our highest priority, and our Support team focuses on getting them documented, into R&D for development, and fixed. As you may imagine, Support receives dozens of bug reports each day - some of them real issues needing investigation and fixing, some of them user error or misunderstanding - all of them needing time and effort from our humans to work through.

Before this year, this forum was not receiving the attention it needed, and many posts were simply buried and forgotten about. We have made a big effort to deploy folks to remedy that - but they have not been able to get through every post from over the years, and I have directed them to focus on more recent posts first. This post from several years ago received attention because our forums drag new activity to the top - another user replied last week, and our team began engaging. I'd like us to eventually get caught up on all posts in all Eos forums - but it is a big heap, so we'll get through it as we can. 

As the Product Manager, my responsibility is to handle input from all sources, and manage our available resources to drive Eos forward. Again, bugs and regressions always make it high up the list to fix first. But depending on the nature of the issue, the number of sites it may harm, and the complexity to fix it - I may decide to keep a bug in our backlog longer than other work. In addition to bugs, we also work on new features, innovations, renovations of older sections of the code, and support for OSs and libraries to keep Eos running on modern systems. Day to day, my job is to assess a list of priorities, and set them for the scale of work we can accomplish. Every moment of every day is a negotiation, and priorities change regularly. 

As such, the feature requests forum is exclusively my purview. I do keep an eye on requests and discussions there, as well as social media, private channels, and elsewhere. Please don't take my lack of response as a lack of awareness - the reality is that among my myriad other responsibilities, I often only have time to be selectively responsive across all platforms. To help folks understand how our feature request forum is used, I have added some explanatory text - I hope it helps.

And to the points above - the folks that support this forum frequently need to engage with Product Management (me) to assess what is being discussed before responding. "I am discussing with the team" usually means "I am chatting with Gonsman." In this particular case, the Stop Effect flag not being applied if a channel already has one is a bug - the discussion around changes to Highlight are not. I have also instructed the team to push folks to post feature requests into the appropriate forum, even if they have done so in a bug post. It is an additional step for you, but it separates the idea from other discussions and issues, and offers you the ability to think through and clearly articulate what you want - which helps everyone.

For my position on your ideas on Highlight, I think there are a few things we want to look at to modernize that function - and pausing intensity effects has been previously discussed. "Is this something ETC is working on?" No, not on a timeline worth discussing - we have other priorities we are focused on ahead of this.

I am always happy to discuss what we're thinking about for feature changes and timelines, and you're welcome to email. But like everywhere else, my inbox is generally sorted by height of fire and I am not always fast in responding.

I hope this brings some clarity to how we use our forums to respond to users, let us know how else we can help. 

~n~
_______________________________
Nick Gonsman
Eos Family Product Manager

Thanks Nick!