Wishist: Highlight should override effects

Hey cool.  I just consulted the manual and found this:

On a command line with a channel selection, you can use [Shift] & [High] to go into Highlight mode
and send the selected channels to the default Highlight setting. This command will self terminate the
command line.

If you just use [High] , the command line will be cleared.

So I'll adjust my above opinion and say you should be able to choose in Setup which behavior you get from the Highlight button.  But it should still 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.

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. 

Yes, this gets brought up every time people discuss highlight needing to stop effects. It's super clunky. I think it would be fine if stopeffect could be by typed in presets, but it can't...

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.