Levels - Conceptual Question...

hodeyp

Hi,

I have built a module that controls my home cinema processor. The volume is stored within a level on a virtual device passed to the module from main. Within the module itself there is a level event that controls certain aspects of the processor when the volume changes.

Now for the questions...

1. To reflect this level on the TP i will do a connect levels - but should this code reside in the main program or the module itself? My thoughts are that this should really reside in the main code so as to leave the module clean for use in a separate system that may use multiple touchpanels or not require feedback to a touchpanel

2. For this particular system I am looking to use changes in the level to control other things. But as this is likely to again be specific to this system I do not want to pollute the module. As there is already a level event within the module itself, if I create a level_event in the main code will it be ignored?

Thanks for any advice here...

DHawthorne

I would keep the UI level out of the module, myself.

You can have multiple level events, or any kind of event for that matter, even residing in the same code or module, all will trigger when a change happens.

The only thing you really need to be careful about is creating a loop: for example, your level changes, the module reacts, causing the level to adust itself...that change makes the module react again, etc. That's a lockup situation. For that reason, I tend to make my levels one-directional - they either control, or they are feedback, and not both. Combining a feedback level to a control level may cause the same effect. You could write your code in such a way that changes due to feedback are ignored for a period as control signals, but I shy away from that.

jeffaco

I too tend to shy away from putting interface-specific code into a module. I like modules to be UI generic and have mainline code manage that.

That said, at times it makes sense to make a module do UI stuff. For example, if you look at the SlimServerMod project on SourceForge (source available), the module itself handles the UI.

Why? Well, funny you should ask!

• There's a LOT of text to keep the UI up to date (current song, artist, title, time; next song, artist, title, time; browse song list; etc). To keep all that stuff up to date efficiently takes a lot of code that would need to essentially be duplicated by everyone using the module.
• Optimizing updates for G4 panels is a nice thing, and reduces overall message traffic to the panel. However, it's also non-trivial. Why make everyone introduce that sort of complexity?
• The above is also a lot of message traffic from the Slim Server to the module, then the module to mainline, then mainline to the panel. You cut message traffic by at least 33% but getting rid of the middle man (mainline).
• Some messages (levels, buttons, etc) are "cheap". But variable text is not, comparitively.
• It's a whole lot simpler to use the module if the module itself handles the UI. That makes the module nice and short.

Now, that said, the module handles FEEDBACK. It's up to mainline to handle button presses and then call the module API to make it do things. This seemed like a good tradeoff to allow the designer to have other operations take place.

BTW, for two-way levels, I worked out a good way to handle that and not get into loops that DHawthorne mentioned:

1. Assign a button number to the slider as well,
2. Keep track of if the button is pressed or not,
3. If the button is pressed, and a level event comes in, handle it as input, but don't update the level to the panel. That was due to the user adjusting the level, so the level should be left where the user sets it to.

SlimServerMod has a "slider" to control where in the list of music you are during browsing, and that seemed to work very well on an MVP-8400 as well as a VPN-CP.

hodeyp

ta very much, nice tip on the button number!