Development for friendlier customization.

[burrisd]

This branch will be used to begin looking at a separation of driver core versus methods that might be used more generally to customize individual driver behavior.

I'm not sure where this is going specifically. It will begin with modifications to separate the specifics of coding to the MIDI Remote API as it was presented in the original demo to present a more general process of defining the virtual surface controls. A design consideration will be to move in a direction that can use configuration data as instructions for the core to construct your presentation.

I expect that this will take a while, but it seems a friendlier way to customize a core driver is important enough to prioritize. Other driver changes will likely be minimal in the meantime.

[burrisd]

After some experimenting, it's not clear if my initial thoughts on this will be beneficial. The details of hooking the callbacks and binding still need to be done for each specific control. Adding another class wrapper doesn't appear to simplify this much. Possibly will abandon this effort.

[burrisd]

Further work on this is proving to isolate the awkward syntax of working directly with the MIDI Remote API. Work is ongoing, and things are changing rapidly on the development branch for this. So far, this is proving to isolate things the users care about from the gory details of the API. The SL specific portion is currently creating the surface controls using the new classes. Presently only the page navigation is bound to functionality with a hybrid of old and new binding approach. New bind methods are being developed before restoring the original demo capability under the new approach.

[burrisd]

There are some aspects of how this is going that I like. On the other hand, I keep getting lost in the levels of indirection and I think I'm having some issues with data scope. Code that looks like it should work and causes no errors is not working! I'm going to checkpoint this branch and focus back on cleaning up and/or reorganizing the main branch. I may revisit this later, but at this point it's been a LOT of effort leading to a lot of frustration.

[burrisd]

I think I have discovered the problem I was having. It appears to be related local variable scope. I will investigate this further later for a good solution. Short term I will change my approach to not rely on this feature. I think the solution is to build a global data structure. In C++ I would have never attempted this, but my interpretation of variable scope in JavaScript led to this bug.

[burrisd]

Per previous comment, I've tried a number of things that seem to keep confirming my conclusions. For now, I believe that I'm going to have to focus solely on some experimentation to confirm a variety of foggy issues about how JavaScript is handling data scope. The separation of the "framework" code into a module seems to have further confused the issue under the rules of how JavaScript isolated module data.

I am attempting to focus of encapsulation, separation of concerns, etc. that I would consider natural aspects of object-oriented design. It seems that limitations of what JavaScript was designed for keep getting in the way of progress. I've wasted a lot of time and energy. Time to focus on understanding and documenting some the data issues and why they are occurring.

Even Perl/Python would have been more conducive to what I'm trying to accomplish. ES5 is a very old JavaScript implementation that predate some of the changes toward "Object oriented".

[burrisd]

A portion of the problem I've been attempting to debug appears to be partially a Cubase MIDI Remote API issue. I've determined a work-around solution by manually selecting a track in Cubase that starts the buttons functioning as expected until a page change. I'm going ahead for now assuming a bug in the API.