The Teleport modules from Little Utils are really living up to their name…
They are Teleporting across VST plugin instances!
i really wasn’t expecting that and presumed each plugin instance would be discrete.
10 Likes
This absolutely makes my day and I hope makes it to the full release! Awesome find
2 Likes
That is so unexpected and amazing, I couldn’t fathom what you meant until I read your post a fourth time.
1 Like
That is a cool feature. As a programmer, it’s probably what I would have expected? I imagine this thing uses some global variable, and everything is running in the same process so… But cool.
1 Like
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.
5 Likes
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) 
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.
2 Likes
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.
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.
3 Likes
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