Done.

[C52382P]

That's why I said "it just works as long as you change the oil." I never suggested that you should get a new car if you don't. I have things to do that are hard, like record neurotic musicians and deliver mixes that they don't hate. What isn't hard is plugging in any of the previous generation of HUI based controllers, assigning them and relying on them to work day in and day out. No one ever released a new product that is supposed to be an improvement on an existing design that was harder to setup and use than the previous generation and got very far with it. You're suggesting that it's MY FAULT that AVID advertised an easy to set up, easy to use, feature packed plug and play set of controllers that don't work? You almost sound like an AVID employee lashing out at all of the people calling you out on this bunk product. Luckily I happen to know first hand that even if the AVID guys don't like you they are constant professionals and are always as helpful and courteous as they can be.

So why aren't these controllers as stable as AVID's other controllers, or controllers made by mackie, or I dare say even controllers made by Behringer? Is it MY FAULT? Is it the fault of all of the other guys who have had the same experience? Do you really think we don't read manuals? This system isn't stable because the software is buggy. Plain and simple. Hiring a network tech isn't going to fix this poorly supported software.

[robertg]

Originally Posted by C52382P

That's why I said "it just works as long as you change the oil." I never suggested that you should get a new car if you don't. I have things to do that are hard, like record neurotic musicians and deliver mixes that they don't hate. What isn't hard is plugging in any of the previous generation of HUI based controllers, assigning them and relying on them to work day in and day out. No one ever released a new product that is supposed to be an improvement on an existing design that was harder to setup and use than the previous generation and got very far with it. You're suggesting that it's MY FAULT that AVID advertised an easy to set up, easy to use, feature packed plug and play set of controllers that don't work? You almost sound like an AVID employee lashing out at all of the people calling you out on this bunk product. Luckily I happen to know first hand that even if the AVID guys don't like you they are constant professionals and are always as helpful and courteous as they can be.

So why aren't these controllers as stable as AVID's other controllers, or controllers made by mackie, or I dare say even controllers made by Behringer? Is it MY FAULT? Is it the fault of all of the other guys who have had the same experience? Do you really think we don't read manuals? This system isn't stable because the software is buggy. Plain and simple. Hiring a network tech isn't going to fix this poorly supported software.

He is not implying that it's not buggy and broken (as far as pro-tools is concerned) - however getting the networking right IS very easy and extremely basic.

It's not any different than plugging in a new workstation on your LAN. As long as DHCP is working on the network, that's all you need to worry about.

[RyanC]

Sorry man I'm not trying to be harsh. Just saying it's the reality with these things.

I had a hub that pro controls didn't like had to replace it (they also didn't like some cables that otherwise worked), stupidly tried to plug a Control24 into a NIC directly with out a xover cable, had forgotten to install the old digi network protocol and torn my hair out wondering what was wrong etc. Networking stuff can be finicky sometimes. I doubt 4-5 Behringers and usb hub would be completely free from issues either (some hubs overheat, might need a powered one etc).

Not to mention had to replace a power supply in the 24 and a couple faders in the proco.

The artist series certainly aren't perfect, and there are a lot of ways they could make the software better and more stable, but it sounds like your system just isn't setup right. It should be better than what you describe and it seems most people have them more stable than that (especially with a fairly standard computer system).

Did you try fixed IP's?

[Bill Denton]

Originally Posted by robertg

Bill - why do you think it's necessary to segregate eucon traffic to its own LAN? It really isn't. Unless a gigabit network is absolutely saturated, which is a rare case, there is no reason. Eucon isn't much traffic at all.

You're looking at it backwards...

Ethernet was never intended to be a real-time protocol. When an application wants to send some data over the network, the data is sliced up into consistently sized pieces and "wrapped" along with a few other pieces of data carrying "network" information (such as the destination for the data) to create a packet. Then, like a newly-hatched chick, it is kicked out of the nest and on to the network.

But the hen has no way of knowing whether or not the network is being used by other traffic...if our packet hits the network and collides with another packet, both packets back off for a different random amount of time, then retries "merging" into the traffic created by other packets.

Obviously, if you have an "isolated" network, where the only traffic is coming from the Eucon units and the computer, a given packet will not have to "wait" as long before "getting on" the network.

Now consider...the computer and Eucon units in your home studio are connected to a router which is connected to the Internet. So, you're on your studio computer, your wife is on the "family" computer doing some shopping, your son is on his laptop playing an intense video game, and your daughter is in her room watching a movie on her tablet. Your Eucon packet is going to be fighting with a huge number of other packets for network resources.

Obviously, this is a highly simplified explanation, but it's adequate to illustrate the point:

The problem eliminated by putting Eucon traffic on an "isolated" network is not a matter of Eucon traffic being mixed with "other" traffic, it's a matter of the "other" traffic getting mixed with the Eucon traffic...

[robertg]

Originally Posted by Bill Denton

You're looking at it backwards...

Ethernet was never intended to be a real-time protocol. When an application wants to send some data over the network, the data is sliced up into consistently sized pieces and "wrapped" along with a few other pieces of data carrying "network" information (such as the destination for the data) to create a packet. Then, like a newly-hatched chick, it is kicked out of the nest and on to the network.

But the hen has no way of knowing whether or not the network is being used by other traffic...if our packet hits the network and collides with another packet, both packets back off for a different random amount of time, then retries "merging" into the traffic created by other packets.

Obviously, if you have an "isolated" network, where the only traffic is coming from the Eucon units and the computer, a given packet will not have to "wait" as long before "getting on" the network.

Now consider...the computer and Eucon units in your home studio are connected to a router which is connected to the Internet. So, you're on your studio computer, your wife is on the "family" computer doing some shopping, your son is on his laptop playing an intense video game, and your daughter is in her room watching a movie on her tablet. Your Eucon packet is going to be fighting with a huge number of other packets for network resources.

Obviously, this is a highly simplified explanation, but it's adequate to illustrate the point:

The problem eliminated by putting Eucon traffic on an "isolated" network is not a matter of Eucon traffic being mixed with "other" traffic, it's a matter of the "other" traffic getting mixed with the Eucon traffic...

You're like one of those people who sounds very knowledgeable to a lamen, but really doesn't know what he is talking about. Chickens and hens, come on, seriously. Packets don't have to wait for anything across a modern switch.

I guess you must not have a clear understanding of just how robust ethernet really is, or how fast 1 gigabit is.

All of those typical family things you listed running at the home network won't even come CLOSE to saturating the LAN. Maybe if a lot of people are streaming it might saturate the *internet* connection going outside, which could be 3-20 Mb/s, but *NOT* anywhere near 1000 Mb/s, inside.

The amount of bandwidth that Eucon needs is so ridiculously tiny. Look at what it's doing. It's screen updates and fader positions. And ethernet is most certainly capable of doing this in very-near real time with hardly any latency.

Absolutely, no doubt, it can easily share traffic with the local network and isolating it is not necessary.

Collisions, really? They were a problem two decades ago. There is no "fighting" of packets anymore, do you understand the difference between a switch and a hub?

[C52382P]

I tried fixed IP addresses when I first got them (obviously with an older version of the software as well as firmware) and it didn't help anything at that time. Admittedly I haven't tried it again. As far as the CAT 5 cables go they are the ones that came with the units and one that came with the switch. I've never considered changing the switch, I bought the "nice one" ... by nice I mean more expensive. Maybe that's worth changing out but it seems like they wouldn't work at all if it were an incompatible switch. They have had periods off and on of relative stability, with various software versions. It's a strange thing though, it seems as if every different SW version has been both more AND less stable in different areas. I may attempt to connect the switch to my main router along with the mac pro and see if that changes anything. That seems counterintuitive to me but I understand that networking is it's own thing. It's hard to imagine the units being more stable while having to deal with more traffic as opposed to being isolated on their own but I'll try it.

[robertg]

Originally Posted by C52382P

I tried fixed IP addresses when I first got them (obviously with an older version of the software as well as firmware) and it didn't help anything at that time. Admittedly I haven't tried it again. As far as the CAT 5 cables go they are the ones that came with the units and one that came with the switch. I've never considered changing the switch, I bought the "nice one" ... by nice I mean more expensive. Maybe that's worth changing out but it seems like they wouldn't work at all if it were an incompatible switch. They have had periods off and on of relative stability, with various software versions. It's a strange thing though, it seems as if every different SW version has been both more AND less stable in different areas. I may attempt to connect the switch to my main router along with the mac pro and see if that changes anything. That seems counterintuitive to me but I understand that networking is it's own thing. It's hard to imagine the units being more stable while having to deal with more traffic as opposed to being isolated on their own but I'll try it.

It's not that there is too much traffic on the network, it's that the implementation is badly broken. The existence of way more complicated client/server products without issue (such as PoE network cameras) proves that.

Really, you don't need anything more than an entry level 8 port $40 netgear switch. Eucon runs just fine with Logic this way, and if it's unstable with Pro Tools then they need to fix it.

[LDS]

Originally Posted by YYR123

I don't think that was the point of bill's post.

I think the Takeaway is that we should understand that it's not quite as simple as some of it may seem

On the other hand I do think the procedure that avid gives you on their website for changing the IP addresses is quite straightforward for both Mac and PC

It doesn't make what I said any less erroneous.

That being said though, if you were running a local EuCon network via a switch hanging directly off your ethernet port on 192.169.1.### it won't even consult your router or WAN running on 192.168.#.#.

The only problem I could see happening is if you tried to access a public DNS record that returned an address in the 192.169.1.x range. It would be treated as part of the local network.

Standards are in place for a reason. Its like walking into a studio that has their patchbays wired with inputs on the top row. If you are the only person using it, you could slap it together however you like. It would work, but it would drive others nuts though!

I definitely agree with the sentiment that networking isn't as easy as it seems. That is largely why I am persistent here on the DUC regarding the avid artist series.

It is by no means a perfect product... but I do read a lot of comments and slagging of it and think that the primary cause is networking issues. I think Avid's instructions are a little too straight forward in that sense. They largely deal with just EuCon and that is it!

[Bill Denton]

Originally Posted by LDS

It doesn't make what I said any less erroneous.

That being said though, if you were running a local EuCon network via a switch hanging directly off your ethernet port on 192.169.1.### it won't even consult your router or WAN running on 192.168.#.#.

The only problem I could see happening is if you tried to access a public DNS record that returned an address in the 192.169.1.x range. It would be treated as part of the local network.

Standards are in place for a reason. Its like walking into a studio that has their patchbays wired with inputs on the top row. If you are the only person using it, you could slap it together however you like. It would work, but it would drive others nuts though!

I definitely agree with the sentiment that networking isn't as easy as it seems. That is largely why I am persistent here on the DUC regarding the avid artist series.

It is by no means a perfect product... but I do read a lot of comments and slagging of it and think that the primary cause is networking issues. I think Avid's instructions are a little too straight forward in that sense. They largely deal with just EuCon and that is it!

That being said though, if you were running a local EuCon network via a switch hanging directly off your ethernet port on 192.169.1.### it won't even consult your router or WAN running on 192.168.#.#.

As both I and the original poster pointed out, 192.169.#.# is a routable, public network. Using a public network is bad practice in the situation being discussed here.

If you want to have two separate networks on the same infrastructure, use something like 192.168.0.# and 192.168.1.#. You are then still using two private networks, and following good practice.

But more importantly, if the Eucon units are connected to a switch or router/switch that has additional traffic, such as from the Internet, ALL of the traffic goes through the same switch fabric and uses up bandwidth.

So, even using 192.168.0.# and 192.168.1.# (two separate networks) doesn't accomplish anything if the networks share infrastructure.

And keep in mind, we are trying to do real-time stuff on a network that doesn't support it. But, the less "other" traffic you have on your infrastructure, the closer you will be able to get to real-time...

[Bill Denton]

Originally Posted by robertg

You're like one of those people who sounds very knowledgeable to a lamen, but really doesn't know what he is talking about. Chickens and hens, come on, seriously. Packets don't have to wait for anything across a modern switch.

I guess you must not have a clear understanding of just how robust ethernet really is, or how fast 1 gigabit is.

All of those typical family things you listed running at the home network won't even come CLOSE to saturating the LAN. Maybe if a lot of people are streaming it might saturate the *internet* connection going outside, which could be 3-20 Mb/s, but *NOT* anywhere near 1000 Mb/s, inside.

The amount of bandwidth that Eucon needs is so ridiculously tiny. Look at what it's doing. It's screen updates and fader positions. And ethernet is most certainly capable of doing this in very-near real time with hardly any latency.

Absolutely, no doubt, it can easily share traffic with the local network and isolating it is not necessary.

Collisions, really? They were a problem two decades ago. There is no "fighting" of packets anymore, do you understand the difference between a switch and a hub?

Obviously, this is a highly simplified explanation ...

Did you miss that part? I am not trying to discuss networking with network engineers, which I can do...I am trying to describe a complex scenario to people who often have zero interest in the "nuts and bolts" being discussed. They just want their stuff to work. By using the "hen and chick" analogy, it helps these folks understand complex concepts.

The first network I built was 10 Mb/s, using mostly hubs because switches were too expensive...the most recent was a 1 Gb/s with all switches, not a hub in sight. So yes, I know the difference between switches and hubs and I know how fast 1 Gb/s Ethernet is.

The first web site I built was all static .html, the ones I have built over the last few years are ASP.NET, so I also know how exponentially network traffic has increased.

Here is the point...if someone follows my advice and uses a separate physical network for their Eucon stuff, which is totally isolated from Internet or other network traffic, they will not have to worry about Eucon bandwidth issues, ever. If they use proper IP address ranges, they won't have to worry about trying to figure out what they did a year ago if they want to add another Eucon device.

And, if someone follows my advice, they will have eliminated all of the network variables, and they will then be able to go to Avid and say with absolute certainty "It's a Eucon problem".

Even you will have to admit that there is nothing "wrong" in my explanation of how Ethernet works. So, if you don't like my explanations, don't read them, just provide your own explanations.

And I will continue to provide explanations that will allow people to accomplish what they want to do, which is not becoming a network engineer...