Automatic coloring of flyoffs

On most multi-NioNode Projects that I have done, this is exactly what I have done...But manually.  In fact, I have recently started to teach this trick in the class.  Bring in all your NioNodes, and then colour (a little British lingo there) them.  Then color (switching back to my language) the Flyoffs the same.  It is very helpful in keeping my little mind straight.

I think this being automatic would be a very helpful tool, but how does the flyoff "know" what color to be after it comes off a XDAB?  And what if the flyoff is used in two different NioNodes, such as when it is a BGM source that is used in rooms that output from different Nodes?

If we leave coming off of the XDAB a manual task (the programer decides the new color), but the color is "embedded" to the flyoff.  That way, when you grab and drop it from the flyoff tree, it has the color that it was painted when it was created off the XDAB.  Maybe reserving black as a multi-NioNode color would be a "best practice".

Anyone else have a comment?

Now where exactly is the fun in that? End users? Kiosk is for end users.

Heh, I'm not against the auto-coloring, just the automatic XDAB configuration. One one hand, yes it does remove the requirement of some level of knowledge from people setting these systems up. But I think that understanding how these boxes interact, what the XDAB is and how to deal with it is good knowledge to have. Manual configuration requires you to have that understanding, and hopefully makes you that much better. A good example of this is the advanced cobranet interface. I've worked with people who don't understand these settings, and therefore have gotten themselves in a little trouble with their systems. If advanced was the only way, it would force people to get a better understanding of what's going on.

Of course, there is the possibility that I may just be crazy. In fact I'd like Nware 2.x to be a set of straight command line utilities that directly accept the various XML configuration files, optional media files, etc.... Muhahahahahah!!!

As an independant programmer, guess what my response will be!!

Jason,

I agree also regarding the advanced devices however, the software could be designed to perform better in a 'less advanced' mode too.  After all, not everybody is buying the most advanced box - the N6!  From a consistancy standpoint, (which seems to be my theme on the forums) if there is a less powerful version of the hardware available, why not a less powerful version of the software too (auto configuration of XDAB)?  Maybe it's my turn to be crazy, but it seems odd to me that someone has to go through 5 days of training covering XDAB, Python, Control Logic, etc to install even small systems using NX32's.

Example: how many MWare (Mainframes, Miniframes, etc) systems are installed without using the DAB tools or Alignment delay blocks?  I'm sure you and I used the DAB tools exclusively and could squeeze 10% more usage out of the DSP architecture because of it, but there are many systems out there that work just fine without them.  The compiler would do it's thing automatically if no DAB blocks were in the file, but if they were present they would take priority and you could essentially override the compiler by using them.  Funny thing, this concept is also found in NWare.  The compiler automatically assigns algorithms to chips for us unless we override, right?  - to be consistant, if we have to manually assign the XDAB channels, shouldn't we also have to manually assign everything to each chip?  After all, why aren't we concerned with the Digital Audio Paths between the chips (remember Intercellnets and Interboardnets?)?  The compiler is automatically assigning those for us, but because we don't have access to a LDAB (local digital audio bus) block, we are ignorant to how it moves signals between the chips!!  Of course, I'm taking the devil's advocate approach just for sake of discussion!

This actually brings up a good point.  Several other manufacturers products act this way, which is where I suspect the comments come from.  I'm thinking of one in particular that allows you to draw a wire between the DSP and a 'CAB'.  It not only makes the connection but automatically assigns bundle numbers for you!  Leaving aside for a minute how this is making the audio industry less intelligent - if the NWare software provided that level of connectivity not only for XDAB but for CobraNet, how much less would Josh's phone ring?  ...how much shorter could training sessions be?  ...how many more small venues would NION be installed in?

Sorry to open up such a can.  Re-reading my above comments, it seems maybe more of a marketing discussion than a technical one!  Fun though!

Ivor, good point. 

To play the other side of the net (which I'm having fun doing - sorry if I'm being annoying)...  have you ever created a multi NION file and NOT put any XDAB?  The complier errors at you in a very smart way... it tells you exactly where it would put each XDAB by displaying an error to the effect of "cross wiring, use XDAB instead".  Clicking on each error highlights the wire in question.  The way I see it, the code is 75% percent there already!

I like your analogy!!  How about another one:  it's sorta like the phone company when you dial a long distance number without the '1'.  A recording says "if you want to dial this number you must dial a '1' first".  Well, if they are smart enough to know I should dial a 1, how much harder would it be for them to just prepend the '1' for me and not play the recording?

Agreed.  I'd like the AI version as well as the option to keep my hands busy too.  You know what they say about idle hands...

Precisely.  Billable hours!

I'll second that.  Perhaps the formulas could be 'hidden' in another form like all the examples in the scripting window?   ...or in the help file.