A mess? Actually I was thinking, perhaps erroneously, quite the opposite. To explain in less abstract terms, I'll use an example of a system I worked on which resulted in a rather involved user interface. It is a BGM system, so, as you might expect it is comprised of several zones. For simplicity lets say that each zone has a level, mute, and source parameter that can be adjusted by the user. There is quite a bit more to it, but this should suffice for the arguments being made.
Now the user interface has lots of little control panels for each of these zones and their associated parameters. Aside from being assigned to different zones, the control panels are essentially exactly the same. So in Nware one must copy-paste an instance for each zone and then manually assign them to the correct parameters. As you can imagine, this is a very labor intensive and error prone task. In reality, these type of operations took at least 75% of my time during development. Coming up with how to make something work was easy, it was deploying features across the many instances where they are needed which was far and away the most trying. To top it off, the result is equally difficult to maintain. Say for instance you would like to modify these panels, to add a feature or fix a problem, you must once again traverse every instance manually.
Another stumbling block is the incorporation of user data into the Nware application. By user data, I mean data that is created and changed by the user: things like presets. This should be distinct from system data such as
signal flow, low level gain staging, CobraNet bundles, etc. An example of the disadvantage of these being stored together is the resulting static nature of user data. If the user wants to add more presets than the system currently has, one has to actually modify the system and redeploy. You would also have to ensure that your modifications include the existing user data already created. Something which can be quite difficult if the modifications take a large amount of time compared to how often the user changes his data. Say you start working on some updates on day 1, the user continues to use the system making whatever changes he needs, and when you're ready on day 4 with your mods, what about the user updates made since day 1?
When revisiting this example project, and considering how to expand and improve upon it, my first reaction was to turn to the nControl product. While it made up for the processing power lacking in the Nion devices, it has the same exact shortcomings due to its programming environment. For these, and other reasons, I'm coming to the realization that if I were to approach a control-intensive project for which the nControl seems to be targeted, I would actually prefer not to use the nControl.
Obviously I can implement whatever I can dream up with the platform of my choice and use RATC, but that's really no different than any of the other network based DSP platforms available, albeit for the usual audio signal flow stuff, I think Nware is better than the rest. What would set a product apart would be the availability of an API. Not only to allow a very high level of integration, like what pandad or a pandad-like interface can supply, but also a native look and feel if the application is a GUI. With regard to GUIs, modern GUI toolkits are extremely well geared to developing UIs in a structured, modular manner. For storing data, well that's obvious, today's databases do exactly that, and very well. Coupled with a Nion API and a good dynamic programming language, it becomes rather straight forward to realize applications far beyond what can be done with nControl, and even popular control systems such as AMX or Crestron.