Feedback advice

jcerecke

Hey,

So I remember reading somewhere on here that in mainline code, the feedback line is only executed when the variable changes that it's feeding back from.

If this is correct then surely this would be the same for:

SEND_COMMAND dvTPCtrl, "'^TXT-',ITOA(BTNS_MAIN_ROOM_MODE[nRoom]),',1&2,',TXT_ROOM_MODES[nRoomMode[nRoom]]"

So then every time I change nRoomMode[nRoom] I don't have to update the text on the button underneath it, it updates itself in mainline.
But this actually continually spits out the send command to the TP, not just on the variable changing.

Is there a better way to do it?

PhreaK

That only applies to channel state manipulation.

If it's something that modifies the UI state regularly and is required to provide the user with good feedback you can create a timeline (100ms is a good compromise between usability and overhead) which performs the update, then start and stop this as required.

If the update is not for real-time feedback and is something like a mode indicator (what your situation sounds like) its a lot neater to have the action which changes the internal system state also perform the UI update. This way things only get updated as required. If you take this approach though make sure the UI gets updated to reflect current system state during its online event, especially if you don't have a guaranteed connection (wireless etc).

vining

Yeah the only state the master tracks for feedback are channel and level so anything else you put in DEF PROG will execute on every pass which will bring your system to its knees.

The best way to handle FB is through events. When an event triggers and a state changes sned your text, channel states, button states or levels but that's not always practical or easy so to simplify things especially for send txt to the TPs you can create a duplicate "sent_var" so in DEF PROG:

DEF PROG

wait 3
     {
     if(nSentRoomMode[nRoom] != nRoomMode[nRoom])
	  {
	  SEND_COMMAND dvTPCtrl, "'^TXT-',ITOA(BTNS_MAIN_ROOM_MODE[nRoom]),',1&2,',TXT_ROOM_MODES[nRoomMode[nRoom]]" ;
	  nSentRoomMode[nRoom] = nRoomMode[nRoom] ;
	  }
     }

Now only the var is checked every 300ms and send txt FB to the TP will only occur when the var changes.

The added wait just keeps the processor from having to evaluate everything on every pass

DHawthorne

My preferred method is to put all the feedback in several functions, broken down by category (system feedback, source feedback, etc.). If everything is code driven, I'll call the appropriate feedback functions only when an event occurs that may have changed it ... like receiving a string from a serial device to update device feedback, pressing a room change button updating a system feedback, etc. If there are events that can possibly happen outside of code (devices that change state on their own, and need to be queried, for example), I'll fire those functions from a periodic timeline. It can get confusing, having multiple feedback functions, and which to fire when, but it greatly increases my flexibility to make them run efficiently without spamming the message queue.

jjames

DHawthorne wrote: »

My preferred method is to put all the feedback in several functions, broken down by category (system feedback, source feedback, etc.). If everything is code driven, I'll call the appropriate feedback functions only when an event occurs that may have changed it ... like receiving a string from a serial device to update device feedback, pressing a room change button updating a system feedback, etc. If there are events that can possibly happen outside of code (devices that change state on their own, and need to be queried, for example), I'll fire those functions from a periodic timeline. It can get confusing, having multiple feedback functions, and which to fire when, but it greatly increases my flexibility to make them run efficiently without spamming the message queue.

I'm starting to go this way with feedback - it takes a little bit getting used to (and to think it ALL out), but it eventually eliminates the need of DEFINE_PROGRAM all together.

For unsolicited feedback, you could have the feedback of the device trigger a channel. So, when you get a string from a lighting device saying a room has been turned on, turn on a channel, and use the channel_event to update the status. The need for timelines that are used for feedback could be completely eliminated as well based on this.

Just my two cents, but this approach of an event driven system seems to be the way to go.