View Single Post
Old 01-16-2019, 04:51 AM   #2342
dixo
Human being with feelings
 
dixo's Avatar
 
Join Date: May 2011
Posts: 92
Default

Quote:
Originally Posted by Geoff Waddington View Post
Yes, agree on all points you both make if we constrain the solution to your use cases.

However, you may notice I also referenced the Console 1 in my first post on this topic.

Here is the Console 1 behaviour with the UAD Pultec low frequency control mapped to 2 Console 1 controls.

Notice how everything is fine when adjusting with the mouse, but when a Console 1 control is used, we get suboptimal behaviour, because of the internal feedback.

https://youtu.be/YbWzWva-bII

So here we have somewhat related issues that can be solved by a periodic update mechanism.

I think I'll implement it at a per widget level, but for now users will set it on a per surface/per page basis.

What do you think ?
I don't mean to get a solution just for my use case, but it seems to me that the internal feedback is a common and somehow logical addition to the range of widget variations (e.g. rotaries, faders, buttons):
- Widget without feedback
- Widget with feedback
- Widget with internal feedback

These seem to be the main types of behaviour we have seen so far on all surfaces that people have tested with.

For instance, I think the behaviour of the Console 1 knobs is not different from how the BCR2000 behaves for its knobs (although I have not tried the scenario shown in the video).

Although a periodic update will ensure that the LEDs will (eventually) show the correct state, it has the drawback that there is a trade-off between response time and MIDI traffic: you don't want to wait too long for the LED state to be updated (i.e. update frequently) but you don't want to send too much unnecessary MIDI traffic (i.e. update infrequently).

So, to me it seems a smarter implementation will be beneficial, only updating state when necessary, and only for the widgets that need it:
1) The parameter mapped to the LED has changed (e.g. mouse action on screen, or through another surface, etc). This may be sufficient for 'properly' implemented surfaces like the QCon or MCU.
2) The control associated with the LED (e.g. the button or rotary) was operated (pressed, released, rotated). This is what the BCR/X-Touch and Console 1 require (in addition to 1).

On top of that a periodic update would be very useful to cater for edge cases or MIDI transmission errors (I see these for instance on my LCD displays now and then) but it can be at a fairly low rate, and thus saves bandwidth on the MIDI connection.

If you are going to implement a periodic refresh then indeed per widget control would be nice. But in the meantime, at page level seems more natural/flexible to me than per surface, although a page may contain a mix of surfaces with different needs for periodic update.

Last edited by dixo; 01-16-2019 at 05:19 AM.
dixo is offline   Reply With Quote