This thread has kicked off a fairly major discussion here at Eigenlabs. This is a discussion that has been going around and around for some months, but we now seem to be coming to a proper understanding of the problem. We fully intend to make lighting keys (in what ever colour you want) as positional markers possible in a future release (it's probably not going to make it into the 1.2 series, there are simply too many other things in the queue for that) but it might be useful if I explain why it isn't the work of ten minutes so that everyone can understand why we haven't already done it.
There are in fact two separate, and quite distinct, ways of lighting keys as positional markers. One is in a geometrical sense - 'I want to light every fourth key on the left hand row down the side of my harp' or 'I want the top right hand key of Keygroup 2 lit green all the time when its visible'. This is positional marking in the same sense that the guitar has it. Using this kind of positional marking one learns to adapt to different scales and tuning arrangements in ones head - a process most guitarists will be familiar with from using different open tunings. The second sense of key marking is musical. 'I want every four semitones in the chromatic scale lit orange' or 'mark the octaves in the blues scale green'. This kind of marking varies from scale to scale, and the brain woud use this information quite differently from the geometric markings.
After a lot of discussion, we concluded that both of these marking models have value and anything that does not do both is broken.
In the current EigenD system, the musical marking is by far the easiest to implement, and this is probably what we will do first, adding the ability top mark intervals in the scale file format itself. The geometric marking is more difficult because the current data flow model of EigenD does not include geometric key information - at a certain point in the signal flow the original geometry is lost and everything is about interval and frequency.
There are a number of reasons we would like to change this so that the geometry of the keys is also preserved in the signal, not just to allow flexible positional markers but to permit certain keys to remain unchanged by Stringers and Scalers downstream, a thing that is very weirdly implemented (or not) in the current setups. So we're going to do it, but it is tinkering and adding things at quite a fundamental level, so this kind of change can only really go in at the very beginning of an Unstable series, and it's too late for 1.2.
I hope that makes things clearer - sorry about the technical dissertation!
John
UK
