Teleport - Strangest discovery of Rack VST so far....

Hope this feature stays. My main use of Teleport is to move clock signals around so would be great if I only ever had to establish one clock module to use that clock everywhere.

However, I can see people wanting the option of having ‘local’ teleport in some circumstances e.g. if using it to send audio signals to a mixer you may not want three instances all sending to the same mixer if one VCV instance was designed as for drums and another instance for melody they’d have to share the same FX sends. Maybe something like adding _global as a suffix to each teleport source name you want to work on a global level or spinning that, _vcvfilename to each source you want to stay local?

Also, as a dev myself, the prospect of instances sharing a global fills me with dread that if the instance that created the global is deleted and some goody-two-shoes garbage collector then decides to mop up the resources it could break things.

Out of interest, as I’m not a VCV dev so haven’t had a look at the beta, is there a new module/functionality in an existing module that can grab the current host BPM (and time signature would be great, but not sure how generic that is across DAWs) and pass it on to a module like Clocked?

1 Like

I use Teleport for clocks too.

Regarding getting the BPM, i don’t see any new module for that and my presumption is we use the MIDI-CV module like before. It has a new DAW midi driver and the default Clock output is 24ppqn. It seems to work well and is jitter free so Clocked shows a consistent BPM.

I think I have found a weird bug though related to how this works across different instances that use different Audio modules (Audio-8 in one instance and Audio-16 in another). I need to investigate more though and I’ll then maybe make a separate post about it.

Native C++ programs and dynamically linked C++ code do not have a garbage collector. I believe that a global defined in a dynamically loaded module will have the lifetime of the loaded code. It’s true that if a VCV plugin were to use a global that it would (probably?) “go away” after all instances of the plugin go away. But presumably no-once cares any more - the plugin shouldn’t be running any code after this, or all heck will break loose.

I don’t know how teleport works, but I don’t see any reason not to use a global due to lifetime concerns.

Ah ok. I didn’t mean a Java style garbage collection, more if the DAW gets to free things up itself on deletion, but from what you are saying it sounds like the plugins really are completely self contained so that’s reassuring,

Hi, dev of LittleUtils here!

To be honest, I didn’t expect Teleport to work across VST Instances! It’s kind of cool but also scary at the same time. The list of existing inputs is stored in a static std::map<string, TeleportIn*> that is shared by all Teleport Input and Output module instances, I guess even across threads.

It feels like it’s a bit of a coincidence or implementation detail that all VST instances are running in the same process, so I wouldn’t rely it in my patches.

I’m a bit surprised that Teleport works at all with multiple threads without crashing or glitching, because there isn’t really any sort of cross-thread synchronization. Let me know if you encounter any problems.


It’s amazing stuff haha - I’ve had an instance running on and off all afternoon/evening that has no clock in at all - all clocks are teleported from another instance and it’s been solid so far.

Maybe you could have 2 options in the right click menu: Teleport (this universe) and Quantum Teleport (other universes) :slight_smile:

I’ll keep playing with it and give it a proper workout and let you know if any issues. This is my clock setup that Teleport makes possible - you can see its getting a good workout.

1 Like

Yes, probably a right-click menu like this would be the right UI to do it. I suspect that actually having the “local” option would be more difficult to implement than the global one, but maybe I’ll look into it at some point.

I don’t really understand your post.

If Teleports are sharing a global map in a way that isn’t thread-safe, people are already running into that with v1. v2 and VST aren’t bringing anything new to the table.

Also, it’s not a coincidence that all the VST are running in the same process, it’s the default way VSTs run in all programs, afaik. Yes, you can force them into their own process on Reaper, and perhaps some others… well, if users do, then they can’t use this feature.

Ah yes that rings a bell. Bitwig runs every plugin in its own sandbox by default IIRC so a plugin crash shouldn’t crash the DAW. Most DAWs with that feature permit turning it off though.

1 Like

You are right, thread safety problems that cause a segfault would have probably surfaced by now. std::map should be thread safe from what I understand.

I’m still not entirely convinced that audio glitching is not possible. Say a teleport input is in thread A and teleport output is in thread B. If now the threads happen to execute the process() functions in the order ABBA, the output would read the same value from the map twice in a row. But I haven’t come across this myself and I haven’t heard anyone complaining about it either.

Related to the VST - I guess Bitwig is a good example of implementation specific behavior (or is the sandboxing still done inside a single process?). Who knows if all DAWs start doing something similar in 5 years.

Yes, bitwig is like reaper, as far as I can determine. One can optionally sandbox plugins in a separate process.

Obviously the decision is yours to make. If it were mine (and it isn’t), I would choose to ignore the sandboxing issue. And anyway, the worst case is that some cool (undocumented) feature stops working. In five year??

Clearly you can try to find a solution that will work on all three OS’s and has a chance of working five years from now. It seems awfully difficult.

From Bitwig

32-bit and 64-bit plug-ins (VST2.4 and VST3) are natively supported, no third-party bridging necessary.

Here are the 5 modes explained:

Within Bitwig. Plug-ins are loaded along with the audio engine. This requires the least memory, but any single plug-in can crash all audio.

Together. Plug-ins are sandboxed together, separating them from the audio engine.

By manufacturer. Individual sandboxes are created for each plug-in manufacturer. (This can be necessary when plug-ins need to communicate with one another.)

By plug-in. Individual sandboxes are created for each plug-in used. When a plug-in is used multiple times, its instances are sandboxed together, sometimes reducing the required memory.

Individually. Individual sandboxes are created for each plug-in used. This is the most memory-intensive option, but the safest.

1 Like

Yeah, I will leave the behavior as it is for now.

I would like my software to work in five years. It’s already almost three years old with fairly minor changes when it was ported to v1. Maybe I’m weird but I sometimes like to open up old Ableton project files from five or more years ago and they work fine. I’d hope to have the same with VCV Rack, and I try to make my plugins in such a way.


Not just clocks…

1 Like

totally forgot about this discovery that you made,
I gotta try some freaky stuff with it haha

Does this work in Bitwig with:

  • Individually-hosted VCV instances?
  • Per-manufacturer/Per-plugin hosted VCV instances?
1 Like

Mine is set up as per manufacturer and it works with that. Don’t really want to change that setting right now so can’t say for sure as to the other options.

If I had to guess I would say it would work for Per Plugin (as multiple instances of same plugin are sandboxed together), but not for individually hosted (as the instances would be in different sandboxes).

But hey - we’re talking Teleportation! who’s to say the walls of a mere box will stand in the way? You might need a sandbox with quantum shielding or something like that…

1 Like

No, that’s fine, that’s good enough to know…

I’m going to assume that if Rack instances are individually hosted then it won’t…

That’s how I have mine set at the moment - as I like to restrict core affinity and farm out certain plugins to groups of cores using Process Lasso.

But until Rack VST has access to more than 1 CPU thread, there’s not much point in doing that, to be fair - so I’ll probably change Rack to the Bitwig default

Can’t wait for the full release of this module!!

I am waiting patiently as well. This will hopefully be the solution to route one patch to different midi-channels in Ableton.

I just did a quick test on this which suggests it would work. (I’m in Bitwig but principle should hopefully work in Live).

In first Rack instance, I had a NoteSeq 16 sending V/Oct and Gate out by Teleport

In second instance I had Teleport receiving the V/Oct and Gate and connected those Teleport outputs to CV > Midi

On a third track I had Serum set up to receive midi from the second Rack instance. Serum seems to be playing things in tune and in time.

1 Like