Tim, Yes, that does sound a bit boring. The second method would be fine, as long as you had one or two templates. If there was a piece of equipment which was entirely different, we'd have to go through the long process of creating another template, but I can't see this happening very much (famous last words). Best, David. _____ From: visurfacereader-bounce@xxxxxxxxxxxxx [mailto:visurfacereader-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Burgess Sent: 25 June 2012 09:52 To: visurfacereader@xxxxxxxxxxxxx Subject: [visurfacereader] Poll on flexibility versus ease OK, I'm finalising the code for reading LED lamps and there's a trade-off to handle. The current design allows you to define named states (e.g. on, off, flashing, red, rein, etc.) for each LED that you define. This is very flexible and will survive any conceivable LED implementation that a manufacturer could come up with. The downside is that, if you've got a protocol that defines 50 lamps, each of which supports 5 states, you've got to define a total of 250 states, which is boring at best. A work-around would be to provide a check box that, if checked, would make all LED lamp interpretation for the protocol point to a single set of state definitions. From a code point of view this is a bit of a cop-out, so I'd appreciate feedback on what behaviour users would prefer to experience. I'm under a reasonable amount of time pressure, so I'll have to make a decision within the next 48 hours or so, so please have a think and respond. Best wishes. Tim Burgess Raised Bar Ltd Phone: +44 (0)1827 719822 Don't forget to vote for improved access to music and music technology at http://www.raisedbar.net/petition.htm