I would deem useful to receive advice, about the optimal way to interface the Zynth with the outer Internet cosmos.
I never managed to get a clear view, on the recommended Internet and WiFi connections.
My current and overall reading of this subject is as follows:
A direct cabled LAN connection from the router should be preferred, whenever a software update is required, due to faster download times and greater net stability.
Configuration of the Zynth from an external computer needs to be performed either via Wi-Fi, or Ethernet cable from the external device.
I am getting excellent Internet access results, with a TP-Link powerline link to the router (as per @cfausto’s advice), but I noticed that it does not override automatically the active Wi-Fi connection (which must be disabled), as it would be expected like in other hardware platforms when a LAN link is detected.
Moreover, I cannot reach any of my Zynths from my iMac through an Ethernet cable, unless a Wi-Fi connection to the router is also active. Again, I would believe Zynthian to behave in this scenario like any other computer, defaulting to cabled LAN when a physical Ethernet connection is hooked.
It is just me or is anyone else experiencing the same overall behaviour?
And, which settings should I possibly effect via terminal, for Zynthian to operate in my nominal expected fashion in the Internet connection department?
Hello, personally, whether I use a cable or a Wi-Fi connection, I can always connect to my Raspberry Pi. I haven’t personally encountered the problem you’re describing. I’m curious to see the response from other Zybthian users.
I’m glad my hint about using a powerline adapter helped you get a reliable Ethernet “cable” to your Zynthian.
As for running both Ethernet and Wi‑Fi at the same time, that’s getting into territory beyond what I’m able to deal with. The device will assign a different IP address to each interface, and from there you’ll have several networking details to sort out, on both the Zynthian and your router/home gateway, such as subnets, default gateways, routing metrics, and so on.
I wish I could help you more. This is expertise I’d really love to have.
Great, I’ll be keeping an eye out for all the upcoming advice, sysadmin recipes and network architecture tips shared in this thread. I can definitely make good use of them!
Funnily enough we use powerline in the bell tower.
It’s interesting to look at the prevalence of IP and forget the many methods that used to exist for moving stuff around. I found an old token ring connector recently.
Ironically we are re introducing differing routes as successful adjuncts to pure IP over Ethernet.
Just adding OSC control leads to surprising limitations.
One can operate OSC over a Pi Pico’s Wifi connection very successfully but if you attempt to do similarly with a USB connection, the lack of a suitable circuitpython liblo USB implementation deadlocks you.
I’ve been operating with MIDI control running in parallel via the USB MIDI implementation and it does all seem to behave reasonably reliably. I also remember the issues we had with howl around back when qmidinet first appeared and that all got sorted out.
These things get done slowly but methodically.
There is a whole nest of machine naming and tagging that might at some point appear as racks of zynths start to become a distributed solution to the endless pursuit of power among some.
Quite how we approach this is worth considering and any element of consensus or observations is to be encouraged.
This has all gone on hold as Pi’s have become disturbingly expensive but that merely means we get a bit more time to muck around with point to point audio across the country!
I also spent years working with networks built on Novell IPX, Digital DECnet, and full OSI 7‑layer management stacks, long before TCP/IP became dominant in the late '80s and early '90s.
But that history isn’t really the focus here. We’re not discussing physical connectivity, nor application‑layer behavior.
The topic is specifically the practical realities of Layer 2 and Layer 3 design choices and challenges, the kind of issues Cisco‑certified professionals and alike are trained to understand and solve.
That is the road I have been walking along across the last few years. For the moment, I have taken particular pleasure and pride in squeezing to the limit the capabilities of every single Zynth - I must say with an unusual degree of military resolve the V 5.1 as of late -, but prospectively I have been planning for long to deploy a multifarious Zynths bank, for the ultimate electronic symphony enterprise.
I have been trying to find some answers or hints for your question of using simultaneously Ethernet and Wifi to connect your Zynthian to (webconf) computers.
It looks like having both eth0 (Ethernet) and wlan0 (WiFi) connected to the same network at the same time can cause connectivity instability or routing loops. This is caused by multiple default gateways and ARP confusion, usually called ARP poisoning. If you want to have both interfaces active on the same subnet but prevent routing conflicts, you can assign them different IP addresses or adjust the routing metrics.
For technical troubleshooting on handling connections and subnets, you might explore the Pi Forums providing valuable community context on avoiding ARP poisoning and correctly parsing your IP route lists.
Many thanks @cfausto, for looking with obvious professional insight into my query. My ideal Zynthians setup would be to dispense altogether with Wi-Fi connections, relying only on virtual-cabled powerline links for data download, and on an end-to-end Ethernet cable from an external computer for webconf configuration and management.
Indeed, I noticed that on a Zynthian connected both directly to the router and through radio modulation via WiFi both eth0 and wlan0 addresses are duly shown on Admin> Network info. What perplexes me is that the webconf connection through LAN collapses if the Wi-Fi link is severed.
I will try and have a look at your posted RPi forum section. Any more specific help, with Zynthian net connection settings, is of course absolutely welcome.
I just tried to find a place for you to understand why your setup is not working as desired and to search for clues and answers for your requirements.
Even if there is a way to make Ethernet and WiFi work simultaneously, I believe that’s suboptimal and may easily collide with assumptions and features of Zynthian system.
This should be properly sorted out at the local network level, so that any computer/webconf device you want to use may reach your Zynthian(s), be it connected via ethernet or wifi interface, thus my initial reference to sysadmin/networking expertise to help establishing the architecture you ask for in this thread topic.
There is a certainly carefully considered design choices to be made if it isn’t to become messy.
We would probably benefit from having some priority of CUIA ordering established by the local gods to allow the considerable conflicts our flexibility can produce resolved without routing hell whilst one is just preparing to give the audience your current rendition of Jump!
@Wyleu, yes, Open Sound Control is great as a messaging protocol for networking computers, synthesizers and alike. And it does not depend on a specific transport layer/medium. It sends data over standard Ethernet or Wi-Fi using UDP or TCP protocols. SO, we need to have a working network underneath it, and that’s the part I have been talking about.
