jlepore wrote:With further exploration, what is interesting about the current way it works is that each section can be re-ordered without affecting the next section as long as the sections stay grouped together... so you can move input chans around and the controller will match the screen order, without affecting Return and Output mappings... you can also re-order within Returns and not affect inputs or outputs... this could be quite useful...
For instance... the top 8 x 4 banks of BCF encoders could map to 32 input chans... and the faders could map to Returns and Outputs and will stay that way as long as Returns and Outs are kept grouped within themselves, while input chans can be re-ordered to suit the band layout... interesting.
Bob L
ok .. seriously? Does he not know how his own system works?
There's no way he can be this uninformed ....
or is this another section of the code he didn't write and doesn't understand?
In all fairness, I've written some large systems (well, actually, "medium-sized systems" as "large systems", by definition, require the efforts of more than one person) and I can attest that after a couple of years I cannot remember how parts of the system work.
I suspect, just based on my observations of the way SAC behaves, that the code is a bit of a kludge; that being the case it's easy enough to believe that he doesn't remember how some code operates that he wrote years ago. That said, his web site certainly talks about other people writing code for him so it's also possible that he doesn't understand how that code works.
As for the whole control surface issue, I think the best thing that Bob could do is to "open-source" SAC Remote (and the communication protocol between SAC remote and SCA) and let 3rd party developers create new user interfaces, control surface interfaces, and other features for SAC. He can keep the mix engine proprietary (which is where the real IP is) and wind up with a lot of development effort provided by other people. One need only look at SAC skins to see how people could take and extend SAC Remote.
Of course, he'd never do it. I suspect he'd think he was giving away the crown jewels (and who knows? Maybe SAC Remote is so intertwined with SAC that it can't be released on its own so he couldn't open-source it without giving away SAC at the same time). Maybe he's embarrassed by the code quality? However, as SAC begins the inevitable decline into irrelevancy (as additional LAWs come on line), I suspect that tricks like open-sourcing SAC Remote could delay (and possibly reverse) that decline.
Cheers,
Randy Hyde