HI there - just back from the session from hell… tried to record a guitar player in the Netherlands using VST Connect Pro (latest version 5.6.10.751) - from Cubase Pro 15 and then 14, but we couldn’t connect a single time! it never once connected us, we tried everything, switching off firewalls, using hub to log in to mySteinberg. the user interface is extremely sparse since they removed the community tab. I had recorded someone with the id system (where you give them a number) before Xmas, and then it already took a few attempts and removing - readding VST connect to the project in order to connect. But now it seems completely broken.
The VST Connect Pro window (and I also tried Connect SE, just to be sure) will always show “not connected” at the bottom. It is not clear to me “when” Cubase actually tries to connect - my guess is when the Performer part tries to connect to our machine - but that always timed out or didn;’t happen. Why is there no separate connect button that shows whether we are connected to a server? no cnnection log window, no messages, it just sits there. We tried switching both sides from 44Khz to 48khz, same problem. The best I could hope for was a messages “please try later” - but never once was I connect to the performer side. So I will have to send Stems and have them import into Pro Tools and record themselves: that defeats the purpose of remote recording.
The system is completely FUBARed. I can connect to the client using SessionWire, but that’s not really suitable for remote recording. Can somebody from the Cubase Team please look at the server component, I think it is very broken. If they cannot set up a reliable server / network, why not team up with the lads at Sessionwire or Landr and use their backbone for transporting the audio?
Please someone at Steinberg, look at this, at this stage I do not know why I bought the VST Connect Pro license; it worked SO WELL when it was still user name based and now its broken. And troubleshooting seems impossible. I can only see a tiny data ping from Cubase in Glasswire, I have no idea which port it uses or how it connects tot he other side, there is no troubleshooting steps and having to remove the Cue channel every time we create a VST Connect instance ti fix stuff is another annoyance on top.
Please rework the network part and give us better tools and transparency for troubleshooting. There is a log window when we create a new VST Connect, why not use that for connection logging?
You need to use the ID method to connect. The old friends page can no longer work because of security reasons. But note that it internally used the same connection method, so nothing has changed reg. the actual connection.
Which is a peer-to-peer connection, there is no server to ping. Make sure to follow all suggestions mentioned here.
I know that the ID method must be used (the other one is not even available in VST Connect). it’s just that it doesn’t work. I had given the code(s) to my performer more than a dozen times, we both restarted, and we never ever got to connect. It is very hard to troubleshoot as there is no message “connected to server” etc. the VST Connect (the host) just has to sit there stupidly and hope that the client can go online and then finds the instance. no message on Connect whether our side is logged in to the network etc. nothing). So you just waste time sitting there waiting and nothing happens…
I am aware of all routing options etc. but the network (back-end) part is very badly documented. And now became unusable. With the old method we could at least see whether somebody was connected to the mysteinberg network. There is no visible login phase with the my steinberg account either.
So the backend is the part that is broken. Why not use a professional service such as sessionwire for the backend?
As @musicullum said, there is no backend. The connection is a peer to peer, so it is just between you and your client, no one else involved.
if it’s peer to peer - how can we check whether there this a connection? The client was in netherlands I am in Republic of Ireland. I tried to scrutinize my network traffic with glasswire but its hard to find - is it running under Cubase network traffic or svchost, or something else? Is a specific port used? We both turned off our firewalls just in case it was blocked.
the UDP Method may not work (I am on a satellite connection through Starlink, because I am located in the middle of nowhere with no cable / DSL / fiber lines), at least according to chatGPT:
VST Connect can fall back to relay servers when direct peer-to-peer fails. That’s why you could record with your singer in Germany even if neither of you had a fully reachable public IP.
- It’s “not super reliable” because UDP packets may be dropped, latency is higher, and NAT traversal can fail intermittently. Starlink’s dynamic IP switching can also introduce brief disconnects.
So, in practice:
-
Direct P2P isn’t guaranteed on Starlink, but VST Connect automatically switches to its relay servers to make it work.
-
The UDP ports you see listed (51111–51113, 51117) are primarily for direct connections. If those ports can’t be reached due to CGNAT, the software still works via the relay, which is why your session succeeded.
I will try whether the port is being used at all the next time:
1. Use Command Prompt to check if ports are in use locally
Open Command Prompt as Administrator:
netstat -ano | findstr 5111
You can cross-check the PID with Task Manager to see if VST Connect is using it.
No idea what ChatGPT is hallucinating here, the statement from @musicullum and the description on the Steinberg website are pretty clear.
In the linked document from @musicullum you can find a signal flowchart that also shows that there are no servers involved.
Working via a satellite connection is not a good idea anyway, the latency in this kind of network is always extremely high, due to the time the signal needs to travel between earth and satellite. You can check that for yourself here:
it may not be a good idea, but it’s what is available in my area - I cannot move my studio away from where I live. Ping is not super but below 50ms, download 250Mbps upload 25Mbps. Not everyone has a T1 backbone available. And I am not complaining about streaming problems - it’s just the connection part of the session.
Starlink satellites are a little closer than geostationary ones, and we regularly livestream music production using Cubase Pro and SessionWire - I use this to upload music, cam and DAW screen to my colleague in Germany who restreams it from there. Before that I had the local “Fiber” connection which used a line of sight transmitted on top of my roof (I said we have no proper cabled network out here in the countryside - not even ISDN). Other than that I could use my 4G phone - probably not an upgrade.
We use that all the time, nothing wrong with Starlink and/or UDP.
Latency is not of any concern with VST Connect either, neither bandwith.
One of the most common problems is that UDP traffic is blocked by so called “internet security” services, we recommend to not use any, OS protection is sufficient.
That is actually true. If a UDP peer-to-peer connection cannot be established, both VST Connect peers attempt to connect to a Relay Server, a simple service which is reachable from public networks, and simply passes along any packet to the peer if a direct connection fails. Note the Relay server is “dumb”, it doesn’t know anything about VST Connect or its connection, it only passes packets along.
Even the Relay server fails if outside UDP traffic is blocked in your local network. See documentation. Also note that both the OS, and your router may be set up to block UDP traffic. When installed properly, the first should have been sorted by the installer, but even that cannot override “security” tools actions.
