1

Topic: Automatic coloring of flyoffs

The other day I was getting a strange error message when trying to compile a project. The message said something to the effect that there is wiring between different NioNodes and I need to use the XDAB instead. Then, when I would click on the error to find out where the problem was, it was very cryptic and lead me through the NioNode... very strange.

However, I found the issue after I went through the project and started coloring all the flyoffs the same color as the NioNode that they are associated with. I found there was a point where two different colors of flyoffs were attached to the same DSP device. Obviously this is sub-optimal and the system will not work this way, I needed to route some of the signals across the XDAB.

So, my thought is that when you drag in a NioNode, when the box opens to select all the options, there should be an option to pick what color the NioNode is. Now, when you compile the project via either deploying or emulating, all the flyoffs would change from white to whatever color the NioNode is so it is blatantly obvious what NioNode the signal is on at any given time. Then, when you want to switch from one NioNode to another, you must hit the XDAB.

This method of coloring flyoffs worked very well as a troubleshooting tool for me and I am curious to know if anyone else thinks it might be a good thing to implement. My thoughts on implementation are that there would be a check-box in the "User Preferences" / "Advanced" box that allows you to turn this feature on and off, thus allowing you to go ahead and have the system automatically color your flyoffs, or you can color them other colors if you have another scheme you would like to use.

Please, share your thoughts, I am eager to hear if anyone else has interest in this.

Josh Millward
Burnt Orange Studios

2

Re: 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?

Make it intuitive, never leave them guessing.

3

Re: Automatic coloring of flyoffs

It seems to me that the real question here is what unit and (possibly) chip did the signal arrive from and which is it going to.  I agree this technique is very helpful.  Not to dwell in the past, but MWare used to only assign one color for a Symbollic Node.  If you colored one of the nodes (with the same name) a different color, they all changed color.  This was a very subtle way of implementing what is being described here.

Just to get a bit more geeky with it: We already have the ability to 'hard assign' devices to units/chips using the device placement options.  Why not have a 'debugging view' accessible as a tool bar icon that displays the placement information on the face of the blocks?  It could also color code the blocks and NIONs to quickly show where everything is placed!  The report already has the ability to highlight items in a similiar manner so it seems like a natural extension - but without all the clicking.  After this is accomplished, extend the same functionality to the wires and flyoffs.  If the compiler can figure out where to place evertyhing, it should also be able to figure out what color to assign to everything.

...of course, we're also missing the forest for all the trees.  Isn't the simpler solution (for the end users) to have the compiler just figure out the XDAB for you?  ...[oh no he didn't go there!?!?].

Thanks,

Joe

4

Re: Automatic coloring of flyoffs

Joe Kurta wrote:

Isn't the simpler solution (for the end users) to have the compiler just figure out the XDAB for you?  ...[oh no he didn't go there!?!?].

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

5

Re: Automatic coloring of flyoffs

oooh you are cheeky!

The various coloUring options all sound like they would make life easier:
maybe the automation can be only be an option that is available for Forum correspondents. "We COULD have done it by hand, but why bother?"

"The single biggest problem in communication is the illusion that it has taken place."
                                                                                        - George Bernard Shaw

6

Re: Automatic coloring of flyoffs

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!!!

7

Re: Automatic coloring of flyoffs

jvalenzuela wrote:

... 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.

I agree with you 100% Jason! However, how do you tell someone who doesn't want to learn this stuff "Just put the unit back in the box and return it to us with a note that says "I'm not smart enough to operate this thing." or just hire someone who does know how it works." Of course, this doesn't apply to anyone here since the reason you are here is to learn more about how it works.

jvalenzuela wrote:

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.

You know what? It was not until after I started always using Cobranet in Advanced mode that I started to get a better grip on how it is supposed to work. I could use it in the simple mode all the time but that didn't make it clear to me how it operated. You seriously would not believe the number of tech support calls I get where the person asks me "I drug in a (CAB device of some kind), but I don't see any flyoffs for it. How do I connect my signal path to that CAB?" They can't seem to wrap their head around the point that the CAB is just an A/D (or D/A, depending on which one you get) box that converts the analog audio to Cobranet (or vice versa) and the channels show up in your Cobranet pile wherever you assign them. So, the correct answer is yet another question, "What flyoffs do you want them to be?"

jvalenzuela wrote:

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!!!

No, Jason, you are not crazy. These are the kinds of desires that separate the men from the boys. Sometimes I think that would be fun too, but then I realize that I need to actually get something done and not be screwing around in the XML configuration files for NWare.

"Dude, why did you do it the hard way???"
"Because I can."

Josh Millward
Burnt Orange Studios

8

Re: Automatic coloring of flyoffs

Josh wrote:

or just hire someone who does know how it works

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!

Josh wrote:

I drug in a (CAB device of some kind), but I don't see any flyoffs for it.

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!

Thanks,

Joe

9

Re: Automatic coloring of flyoffs

Hello All,
I think automatic XDAB placement is a great idea and all but has anyone seen what happens when you put all inputs and outputs on XDAB and let the compiler put everything in between where it wants? It isn't pretty. Its default behavior is to fill NION 1 chip 1 then NION1 chip 2 and so on. It will work but the latency and DSP usage are going to kill you.

The way I see it, automatic vs manual XDAB placement is a bit like comparing how Windows and UNIX do things. Windows does everything for you but it's kinda sloppy and takes up LOTS of resources (2GB RAM just for an OS!!!???). UNIX requires a few more instructions from the user but it's a helluva lot tidier and much more efficient (512MB RAM for Solaris with apps). You get the picture.

I'm sure we'll eventually have automatic XDAB placement that works well enough but we tech freaks will turn it off in favor of doing it ourselves anyway.

The only true wisdom is in knowing you know nothing. -Socrates

10

Re: Automatic coloring of flyoffs

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?

Thanks,

Joe

11

Re: Automatic coloring of flyoffs

Joe Kurta wrote:

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!

I'm game for that. During class they *VERY* lightly touched on chip assignment with regards to I/O in an indirect way. If you do full compile report you can infer which I/O devices(slots/CM1) are connected to which chips.

In the end, I guess if you guys want to cook up some wire-my-file-and-setup-Cobranet-for-me Wizard that's fine, just !!PLEASE!! do not get rid of the manual ways of doing it. For me, one of the high points of the Nion platform is the fact that I CAN do some of this stuff manually in very specific ways as required by the application. That and the shiny faceplates....


So Ivor.....when can I expect an Nware version that will run on my (not-so-shiny-but-works-great)Sun Workstation, and who are you calling a freak?

12

Re: Automatic coloring of flyoffs

jvalenzuela wrote:

PLEASE!! do not get rid of the manual ways of doing it

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...

Thanks,

Joe

13

Re: Automatic coloring of flyoffs

So we are agreed that we need a simple way to do things for the average "dudes", and a hard way to do things so us geeks have a reason to talk to each other.

Make it intuitive, never leave them guessing.

14

Re: Automatic coloring of flyoffs

Precisely.  Billable hours!

Thanks,

Joe

15

Re: Automatic coloring of flyoffs

As someone who spends most of my days providing support for "average dudes", I'm also all for the simple way being most accessible, without losing any of the flexibility to do the very cool things.

Hence my comment to Scott elsewhere about not having "Arcane" as the first thing these average dudes see when they look for DSP devices.

And while I'm at it: it would be great if the Expression Labeller just did the obviouls {1+=1} and didn't show the scary page full of text and formulae. There should be an "advanced" option that then does go to what is the current page.

"The single biggest problem in communication is the illusion that it has taken place."
                                                                                        - George Bernard Shaw

16

Re: Automatic coloring of flyoffs

phils wrote:

And while I'm at it: it would be great if the Expression Labeller just did the obviouls {1+=1} and didn't show the scary page full of text and formulae. There should be an "advanced" option that then does go to what is the current page.

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.

Thanks,

Joe

17

Re: Automatic coloring of flyoffs

Just thought I'd return from the long tangent:
In MWare (remember that??) a shambolic node had colour as a property, so each time a receiver appeared it automagically matched the transmitter. I know the Custom flyoffs are androgenous, and not exactly parallel, but it would still be cool if when I add another flyoff it matches earlier ones.

"The single biggest problem in communication is the illusion that it has taken place."
                                                                                        - George Bernard Shaw