• State Verified Answer
  • +1 person also asked this people also asked this
  • Date
    3perf
  • Date
  • Replies 4 replies
  • Subscribers 187 subscribers
  • Views 1521 views
  • Users 0 members are here

Manual time on fader: missing and incorrect level feedback via OSC

Hi,
I believe I've come across a bug in EOS (Nomad) when a Manual Time fader is involved.

Usually, all fader position updates are sent out via OSC. But when a fader is set to "Man Time", this doesn't happen.
If I move a fader on Tab28, no updates get sent out -- except for:

/eos/fader/1/5, Double: 1

or

/eos/fader/1/5, Double: 0

And that's only when the fader goes to zero, or transitions from zero to something else. 

Other types of faders (Cue lists, subs etc) immediately send out fader values (and correct ones) when a fader on Tab28 is moved.

When the faders are driven externally (from Luminosus), after about half a second of the fader having come to a stop, EOS feeds back "0" or "1" again. So with motor faders, putting the fader anywhere other than zero, it'll jump to 100% after letting go of it.

Discovered initially on Nomad v2.8.3 (Windows). Retested on 2.9.0 (Windows), the problem still exists.
Have checked the 'known issues' part of the release notes, but I don't think this problem is listed.

Cheers,
Daniel

Parents
  • 0

    Currently any fader that has the ability to be above 100 will have issues. The EOS generic method for faders over OSC currently doesn't have the capability to do this.  The fader over osc is a value between 0 and 1 which ends up being a decimal value but 1 = 100 so it can't be 200.... There has to be an intermediary math function to calculate the percentage between min and max and map that to a value between 0 and 1.  This is a longstanding issue that has existed since the FX size/rate faders came to be and the manual time has the same issue.

Reply
  • 0

    Currently any fader that has the ability to be above 100 will have issues. The EOS generic method for faders over OSC currently doesn't have the capability to do this.  The fader over osc is a value between 0 and 1 which ends up being a decimal value but 1 = 100 so it can't be 200.... There has to be an intermediary math function to calculate the percentage between min and max and map that to a value between 0 and 1.  This is a longstanding issue that has existed since the FX size/rate faders came to be and the manual time has the same issue.

Children
  • 0 in reply to Druuka

    As you're the maker of oscRFR (or at least, involved with the makers?), you certainly understand this better than me. However I don't quite understand where the disconnect is. I would point out that when EOS receives the OSC fader positions, everything is completely fine. EOS receives fader travel positions between 0 and 1, and places the virtual fader correctly, whatever the fader designation (Rate/Size/Sub/Cuelist/etc) and range. It's merely the OSC _output_ from EOS which is incorrect. To me that feels more like a small(ish) bug than a deeper underlying architecture problem. If it were a structural issue, then surely mapping mismatches should occur both ways?

Related

www.etcconnect.com