Targeting SuperDirt on a local network

Questions and Answers
#1

Hi everybody,
I'd like to have a set up with two computers on a local network:

  • on the first computer, I'd like to run supercollider and superdirt.
  • on the second, I'd like to just run Tidal (Atom) and send OSC messages to the first computer.
    In other words, the second computer would just be a remote to drive scsynth (which run on the first machine).

I'd like to have some advices on this.

If I start SuperDirt (on the first computer) like this:
~dirt = SuperDirt(2, s);
~dirt.start(57120, 0 ! 12, "192.168.0.0"); // where 192.168.0.0 is the ip fo the second computer on the local network and 57120 the port on which the second computer send the OSC messages.

and if I start Tidal (on the second computer) with this in the bootTidal.hs:
tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "192.168.0.1", oPort = 57120}) (defaultConfig {cFrameTimespan = 1/20})
// where 192.168.0.1 is the ip fo the first computer on the local network.

Is this gonna work like this ? Or Am I missing something ?

I ask you because I can't test it right now.
I don't have the second computer, but I need to be ready for the moment where I'll setting up all that together.

Is anyone have ever experienced with that kind of set up ?
I thank you in advance
Fabien

2 Likes
#2

The ip address you pass to ~dirt.start is the one to 'listen' to, i.e. it should be the IP address of the first, not the second computer. Actually it's easiest to pass "0.0.0.0" here - which is a kind of wildcard, so gets superdirt to listen to all addresses that the local computer has.

You might need a recent change to superdirt though, which I think hasn't been released yet - https://github.com/musikinformatik/SuperDirt/pull/198

The other thing is that messages are timestamped, and so the system clocks on the two computers will need to be kept closely in sync. I recommend ptpd for this https://github.com/ptpd/ptpd

#3

Hello,
thanks a lot for your fast answer.
I'm a bit confuse right now, if I follow what you say and put the IP adress of the first computer in the ~dirt.start (SuperDirt runs on the first computer) how can I listen to the OSC coming from the second machine ?

#4

I just need to listen one netaddr (the ip adress of the second computer which run tidal), in this case do I need that change:
https://github.com/musikinformatik/SuperDirt/pull/198 ?

Thank you for ptpd

#5

Ah I think you're right, and that the address passed to dirt.start is indeed normally the IP address of the other computer. This isn't needed though, if you are up to date with this change, you can put "0.0.0.0" as I suggest, and it will accept incoming messages from anywhere.

#6

Thank you,
Ok I understand that:
if I put

~dirt.start(57120, 0 ! 12, "0.0.0.0");

it's a kind of wild card and superDirt accept incoming messages from anywhere.
But I don't need to accept incoming messages from anywhere.
I want to listen to one IP address on the local network, so my question is:
Do I really need that change which calls " Listen to any netaddr" to do what I want?

There are some other things that are not clear for me:
in the file bootTidal.hs I have that line:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "???", oPort = ???}) (defaultConfig {cFrameTimespan = 1/20})

What is the meaning of oAddress and oPort ? and what do I need to provide here to make it work in my case ?

my case is:

  • first computer run SuperCollider and SuperDirt
  • second computer run Tidal

From what I understand, it is the address of superdirt so in my case the IP address of the first computer ? Can you confirm me this ?

Concerning the port, I need to have the same port number in my start file in SC:

~dirt.start(57120);

and in my bootTidal.hs:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "???", oPort = 57120}) (defaultConfig {cFrameTimespan = 1/20})

Is that right ?

One last thing when I boot Tidal, I have that message in tidal post window:

t>Listening for controls on 127.0.0.1:6010

What is the meaning of 6010 here after the local IP ?

Sorry for the noob questions
I thank you in advance
Fabien

#7

Hello, can we get ptpd from apt, or should webuild it from sources ?
It looks like it uses a conf file similar to an .ini, is there an example to take a look on, please ?

From what I've caught 6010 is the port SD uses to listen at osc, and 57120 the one looked at by sclang, but I may be wrong?

#8

ptpd from apt works fine for me.
I run it like sudo ptpd -Cm -i wlp2s0 where wlp2s0 is the network device.

6010 is the port that tidal listens to for control messages. 57120 is listened to by sclang and therefore superdirt, as superdirt runs in sclang.

1 Like
#9

Thank you for your help and sorry to dig up that old thread but at the time I had to pass to something else due to lack of time.

Today, I'd like to retry this set up.

As a reminder I'd like to be able to have tidal running on one machine and SC (superdirt) on another.
I'd like to send osc from tidal to the other machine running SuperCollider and SuperDirt.
I don't know if it's possible, is anyone ever try this kind of set up ?

So far, my attempt to do that can be resumed like this:

  • The two machines are on a LAN connected to each other by an ethernet cable, I can ping from one machine to the other (and vice versa) without any problems.
  • I have ptpd2 running on the two machines.
    On the server machine (which run scsynth and therefore superdirt) I run this in the terminal:

sudo ptpd -V -s -i enp0s31f6

(enp0s31f6 is my network device)
On the other machine (which run tidal) I run this in the terminal:

sudo ptpd -V -M -i enp0s31f6

(I assumed the machine which send the osc messages is the Master that's the -M)

On the server machine before booting scsynth, I execute this:

s.options.maxLogins = 2;

After scsynth has started, I execute this:

~dirt = SuperDirt(2, s);
~dirt.loadSoundFiles;
s.sync; // I'm in a routine
~dirt.start(57120, 0 ! 12, "IP of the Tidal machine");

On the other machine (which run tidal), I put this in the bootTidal.hs:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "IP of the scsynth Machine", oPort = 57120}) (defaultConfig {cFrameTimespan = 1/20})

When I try to boot Tidal, I have this message in the post window (in Atom):

t> Waiting for SuperDirt

It's look like tidal can't connect to the instance of superdirt on the other machine.
Maybe it's not possible to do this ? Is anyone has any experience with that kind of set up ?
I don't know what I'm missing here but if someone can help me with this it would be awesome.

I thank you in advance

#10

Hi @fabien

I think the problem you're hitting, is that tidal now uses the same socket both for listening for OSC as it does sending it to supercollider. So you have to use a LAN ip address for listening to controls (rather than the localhost default), otherwise it won't be able to send messages out.

In short, the easiest thing is to add cCtrlListen = "0.0.0.0" to your config in BootTidal.hs. Then you will listen to all interfaces, and can use the socket to send to any address.

e.g.

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "IP of the scsynth Machine", oPort = 57120, }) (defaultConfig {cVerbose = True, cFrameTimespan = 1/20, cCtrlListen = "0.0.0.0"})
#11

Hi @yaxu

thanks a lot for your answer

I try the cCtrlListen = "0.0.0.0" tips

but I get the same message in Atom:

t> Waiting for SuperDirt (v.1.7.2 or higher)...

I also try both ways for Ptpd:
The machine running scsynth in Master while the machine running tidal in slave and vice versa.

but I get the same result

#12

Hmm, well you do need to set that cCtrlListen for it to work, but there must be something else wrong as well. Perhaps superdirt isn't listening properly.

Is 192.168.0.0 really the ip address?

In any case, I think you can set this to:

~dirt.start(57120, 0 ! 12, "0.0.0.0");

and then it will accept messages from any ip address. Although looking at the superdirt source code, it might have to be

~dirt.start(57120, 0 ! 12, NetAddr("0.0.0.0"));

You could also use a network packet sniffer like wireshark to check what's really being sent / received.

Also, make sure you have the latest superdirt (v1.7.3) installed, via language -> quarks in supercollider.

#13

Thank you for your answer,

Sorry, if I'm not clear,
I added this to the bootTidal.hs:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "IP of the scsynth Machine", oPort = 57120, }) (defaultConfig {cVerbose = True, cFrameTimespan = 1/20, cCtrlListen = "0.0.0.0"})

The real IP address of the machine running Tidal is 169.254.178.89

I tried it like this and I have an error message:

~dirt.start(57120, 0 ! 12, "169.254.178.89");

Like you said the argument senderAddr wait for a NetAddr not a String (The doc states that a string is expected here)

So I tried this:

~dirt.start(57120, 0 ! 12, NetAddr("169.254.178.89", 57120));

and this:

~dirt.start(57120, 0 ! 12, NetAddr("0.0.0.0", 57120));

But I still have the same message in Atom:

t> Waiting for SuperDirt (v.1.7.2 or higher)...

When I checked in language > quarks, my version of SuperDirt is called DIRTY (I don't know if it's ok).
I have to check with wireshark.
Thank you

#14

Hello, and thanks @yaxu for your answers. I'm the other one involved in this.

The message t> Waiting for SD appeared when I mangled with the BootTidal.hs file in the Cabal packages dir.
I usually use Atom with TC. When exploring the packages, i noticed there was a BootTidal.hs in the TC Atom package. When toying with cCtrlListen and oAddress values other than factory ones, Atom returned huge, red error messages.

We tried then with Emacs after reverting the Atom package file back to normal, but with the edited Cabal dir file. What I've had might be clearer for you to diagnose - ofc edited_ip_address is a mock :

GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
Loaded package environment from /home/username/.ghc/x86_64-linux-8.8.4/environments/default
Prelude>
/home/username/.cabal/store/ghc-8.8.4/tidal-1.7.10-verylonghash/share/BootTidal.hs:10:169: error:
    • No instance for (Data.String.IsString Bool)
        arising from the literal ‘"0.0.0.0"’
    • In the ‘cCtrlListen’ field of a record
      In the second argument of ‘startTidal’, namely
        ‘(defaultConfig
            {cVerbose = True, cFrameTimespan = 1 / 20,
             cCtrlListen = "0.0.0.0"})’
      In the first argument of ‘GHC.GHCi.ghciStepIO ::
                                  forall a. IO a -> IO a’, namely
        ‘(startTidal
            (superdirtTarget
               {oLatency = 0.1, oAddress = "edited_ip_address", oPort = 57120})
            (defaultConfig
               {cVerbose = True, cFrameTimespan = 1 / 20,
                cCtrlListen = "0.0.0.0"}))’
   |
10 | tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "edited_ip_address", oPort = 57120}) (defaultConfig {cVerbose = True, cFrameTimespan = 1/20, cCtrlListen = "0.0.0.0"})
   |

We both run ubuntu based systems, ping and ptpd sync attempts work fine so far.
We'll give it more tries next week.
Thanks a lot, have a nice weekend !

#15

I think that is very old. Try changing to v1.7.3. Sometimes if you have edited some files supercollider will fail to update via the quarks interface. So you could try from the commandline:

cd ~/.local/share/SuperCollider/downloaded-quarks/SuperDirt
git pull
git checkout v1.7.3

My apologies, it should be cCtrlAddr that you change, not cCtrlListen. So:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "IP of the scsynth Machine", oPort = 57120, }) (defaultConfig {cVerbose = True, cFrameTimespan = 1/20, cCtrlAddr = "0.0.0.0"})
2 Likes
#16

Thank you for your answer, I will try that asap

#17

Hello @yaxu
thank you very much for your help, it works (without the semicolon after oPort = 57120)
adding this to the bootTidal.hs do the job:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "IP of the scsynth Machine", oPort = 57120}) (defaultConfig {cVerbose = True, cFrameTimespan = 1/20, cCtrlAddr = "0.0.0.0"})

I have a lot of late message on scsynth side, but basically it works, thank you very much.

#18

Hm, you shouldn't get the late messages if the computers are in sync.. But you could increase oLatency to fix it.