Hi guys,
I’m moving my first steps in using EspGrid and Esp Quark inside SuperCollider to synchronize two laptops on the same local network for a livecoding performance.
I’ve already some experience using MandelHub (from Benoit and the Mandelbrots’ BenoitLib) for the same purpose, unfortunately not without any problem 
So, I’ve successfully compiled the EspGrid and installed the SC Esp Quark. Went through all the necessary steps to make it communicating with EspGrid.
I’m able to create an instance of the EspClock and chat but, when it comes to change tempo, the EspGrid is showing me this message on the console window (and laptops are not synchronized at all):
EspPeer: *** attempt to query non-existent clock adjustment mode ***
2020-03-15 13:28:38.264 espgridd[12047:12047] 6857636266199 EspKeyValueController: dropping KVC from authority <my partner name> with clock adjustment 0
Does this message mean anything to you?
How to fix it?
What I’m doing wrong?
These are the steps I’m taking:
- start the
espgridd application;
- creating a tempo clock with the line
TempoClock.default = EspClock.new;
- starting the clock
TempoClock.default.start;
When trying to perfom a change in tempo, like TempoClock.tempo_(145/60); I get the error messege in the espgridd bash window.
My os is Linux Ubuntu Studio 18.0.4 (the same as my partner’s).
I think this topic can be considered as a follow up of this one.
Thank all for your support
na
If you are syncing SuperCollider to SuperCollider, consider using LinkClock (3.11). Guaranteed easier setup.
hjh
2 Likes
Thank you @jamshark70 for you continuous support,
Me and my partner eventually tried the LinkClock you suggested (I took the opportunity to also install the new version 3.11 of SuperCollider!). It’s been a long time since you suggested it to me the first time: I confess that it frightened me at the time to compile the SC development version but now I can take advantage that the new SC version integrates Link inside it directly! So again, thank you.
Link works very well indeed 
I’ve also found this interesting talk from the Linux Audio Conference 2018 which show how it works.
Me and my partner we tested Link using 3 different laptops connected to a 8 port mini ethernet switch and it worked fine.
Problems arise when, instead of a simple ethernet switch like this one, I try to use my home DLink DVA-5592 modem/router/switch. In that scenario, link doesn’t work any more and I think it’s something related to the DLink and its internal settings.
In fact I’ve read that sometimes routers prevent multicast. I’ve also read that it can be something related to the 20808 port which could have been blocked by some firewall. Do you have some experience with that?
Doing some Wireshark sniffing I’ve also noticed that there’s a strange IP address showing up in the flowing packets: 224.76.78.75. I’ve looked up in the Link source code and I’ve found that IP here. What does this IP stand for?
Don’t want to bother you with these (probably) overly technical questions from the moment are not strictly related to SuperCollider itself but, if you have any suggestions, it will be super appreciated.
Thank you so much and thank you for your kindness
bye
na
I have no idea. I’m not an author or maintainer of Link.
Link does depend on packets being able to travel through the router – it’s up to the user to configure the router to allow traffic across. (But that would be the same for espgrid I think.)
hjh
1 Like
I’ve eventually found a solution.
The problem was with the router as I suspected: the Dlink router was blocking the UDP multicast messages flow.
So, from the router setting, I’ve created an IGMP proxy server and added the address 224.76.78.75 on the “Skip Multicast Groups” text field. Now Link is working as expected.
1 Like