I am happy to announce the prerelease availability of my first modules: PB-I and PB-O. Latest version is linked here:
Based on Little Util’s excellent teleport plugin, the pair allow the routing of individual cables around VCV. This provides for the creation of cable patch bays and facilitates a more organized workflow.
Feedback strongly welcomed as I do final testing and improvement before submitting this to the store.
Great idea to individually label the ports. That saves me having to maintain a separate label module to remember what all those wires went to.
Believe it or not, I have been dreaming about modules like this for a long time, and was actively working on something very similar for my next Venom release! Now I’m not sure if I will continue with that effort or not (I have plenty more modules I want to create).
The CPU usage definitely seems high. I’m guessing that may be the price of mapping each output port individually rather than mapping the output module as a whole. I see how the workflow is good as you have it, but I’m not convinced it is worth the CPU penalty.
For me the critical functionality that is missing is a way to normal the inputs. I’m thinking of either a second form of PB-O, maybe called PB-O-N, or an expander module for the PB-O. Either way, it would provide a normal input for each output. If the PB-I input is not patched, then the PB-O normal input voltage would be used at the output. If the PB-I input is patched, then the normal value is ignored and the PB-I value is used. You don’t want the normal input to appear in the patch bay user interface, which is why I think you need a second PB-O or an expander.
You might want to consider making the PB-O output true 0 channel if neither the input nor the normal are patched. That way you can patch from your PB-O to some target module without disrupting the target’s built-in normal value. It would be like the target input is not patched, so the normal is preserved. If the user patches into the PB-I input, then the target module would get the patched value.
I notice that voltages are still teleported if the PB-I is disabled, but not if the PB-O is disabled. I see why that is, but it might be confusing / counter-intuitive to most users. You might consider blocking the teleport if the PB-I is disabled.
I will definitely follow your progress. Sometime soon I need to decide if I will move forward with my own version.
Yes, it’s a real issue, but I have a good idea about resolving it: there’s a lot going on in process that (I think) could be set up ahead of time. It just doesn’t make sense that passing an input to an output would cost so much. I had been focused on stability before worrying about it.
Yes, I’m hoping build a couple of expanders next - one for normalling inputs and one for the outputs. This should be too hard, but the cpu usage needs to be dealt with first.
Interesting, Should be very easy to do. Thanks!
Yes, I have an issue for this, disabled behaviour is still being ignored right now: inputs still show up in the connection list etc. It will be handled like adding and deleting modules, so they won’t broadcast or be connectable.
Thanks so much for the feedback!
That global variable STL map that you are using for your magic… Is that really thread safe - considering you might have multiple modules on different threads all sharing that? I guess it might be safe…
I fixed the CPU issue. Woot.
I’m afraid I’m only just starting to dabble in C++ programming: the trick was the brainchild of mgunyho from Little Utils, who used it in the Teleport plugin this was based on. So, I don’t definitively know whether there are situations where it could be problematic. I’ve yet to experience any weirdness that I couldn’t track down to my own bad code. So it, uhh, works on my (multi-threading) machine?
Interestingly, I’ve noticed that multiple instances of vcv in the same DAW show up in each other’s input selection drop downs. Unfortunately, transfering audio between them doesn’t work. I’ll have to find a way to hide them.
yeah, I’m a little hazy on the details. I just now asked the Internet
Another update:
Managed to break polyphonic cables in that last release.
