Hi! Would be very handy and time saver if Connections could “remember” their < nc >. Is it possible to implement this in saved data? Would be very very friendly to me 
There are I/O’s, sometimes needed, sometimes not. But anything I set, I need to repeat again and again in every program/projekt start.
e.g. here:
Indeed - that’s how it should be, will check.
Right.
There is a problem though. VST Live remembers up to 32 connections for any port. If you change your rig to different hardware, and once the project has been saved at that place, it will remember the new ports; and when you open that project in a previous location, it will find the older ports’ association, and assign it automatically. That is a great feature we don’t want to jeopardize.
For your wish we’d have to delete all references to that port ever, which we shy back from doing…
Why not just mute the according channel?
Dear @musicullum , thank you for your reply!
I’m strictly talking about same setup, same hardwares, 2mins of difference in time, if that makes difference.
The problem is even more problematic with e.g generic-audio, where self-utilized output assignments can cause doubled assignments so the sound is not coming until removing self-assigned double (while I already made and saved my decision, what and how to. This override (same setup, same everything) for every program start is something different from the handy feature to remember last I/O assignment with a given device.
Don’t know how to solve this. VST Live tries its best to restore “lost” ports, and is not at all prepared for deliberately removing all references to those, because it is somewhat contradictionary to the idea of ports, which are supposed to be connected to something. You try to use “<nc>” as a “Mute” state, which is weird given that there are mute buttons
Or, if I want to get rid of it remove it altogether.
Let me check if we can provide a ctrl/select <nc> to deliberately remove all references to a port.
Not quite just mute, in some circumstances I’m experiencing problem if VL is overriding my configuration and assigns quickly the same phisical port doubled… right at soundcheck but will collect my thoughts that may help us
But getting here and have to inspect my “connections” tab first all the time with my same hardware environment and there are lots of things I have to check anyways, every minute counts and to me every override under the hood is……
While Yesterday wanted to solve something and had to restart VL a lot, while being nervous anyways needed to re-set overrides again an again.
With a loaded project on the same hardware that it was saved with? That would certainly be wrong.
Never had that. Provided that the hardware is connected and nothing changed as compared to what was saved with the project when it is loaded, it would be quite surprising.
Same everithing, even the xlr cables, saved, re-saved, re-set. Actually in 95% cases using my usb-c device or just the internal chip with GenericLowLatencyASIO.
Can it be that problem starts when have less physical ports on hardware then the output ports kept in VL… as I’m doing for multiple purposes and cases?
Yesterday needed LTC out on GenericLowLatency but every start VS assigned my only ports (that would need for LTC-out) to multiple ones, but as overrided my config.
Don’t quite understand that but yes, it may be a problem.
Can we check one of your projects that you so kindly left us to examine if we can find something? Or does it work as described (“startegy”), but there is something else?
Hi @musicullum ,
I’m not 100% sure, but I guess the two reasons how I ended here.
Using LTC gen a lot, but it directly goes to OUT ports (can’t be muted via mixer). To be sure it’s state to physical out, I need check “connections”…
Using more VSTL outs (to multiple uses and scenarios), than I usually have physically. Therefore VSTL thinks to solve my < nc >'d ports filling them with duplicated-outputs and virtualaudi-ouputs “randomly”… meanwhile I could - exept LTCgen - simply negligate these connection-overrides and focus reviewing “unused-outs” MUTEd state in MIXER.
Sure, no worries, although I think:
That is a lovey behaviour and concept
That might give me the feeling it takes control out of my hands… as if a little fairy is flying around my patchbay, re-plugging things, wishing to help me 
No problem then; I can live with it. However, if there is any idea to give the control back to me, I will be happy to evaluate it in the future.
Try ctrl/click on hardware port with todays’ version, does that work for you?
Hi @musicullum ,
I’m not sure if doing it right, it seems to me:
Will ctrl+click work there like e.g.: at a MIDI fader make it “not-set”?Really sorry, but a last minute problem prevented the fix to make it into Fridays‘ version. Next time, promised.
When engaged, you will be asked to consent.
Dear @musicullum ,
no push, no worries and thank you for your time thinking about a possible solution
Hi @musicullum !
It looks working Thank you very much!!
First we had a round or two (doing, saving, closing, opening, checking) until I found out:
“Ctrl+Click +HOLD & Select < nc >” is the right way to do the job (first clicked as we do for “set it Not-Set”, but it selected the one where my mouse-pointer was). We’re good now with ports NC’s
It’s weird then to make this happen when simply selecting < nc > I guess, because of the things you mentioned before, do I understand right?
p.s.:
At one combination only I found the app fails so far: if NC-ing the very first port (in any type of). Then it always filled up with a reachable port at opening.
Yes, as it looses all connections to other hardware.
Guten Morgen @musicullum ,
I’ve found one little, reproducable issue here:
weird, I know. No hurry (in worst case it’s possible to select the needed input port later or soon), just wanted to let you know there is a little exeption somewhere that I’ve discovered yesterday afternoon as wanted to control a single channel light via VL’s DMXmixer.
Here is a screen-rec. I NC-ed the DMX port for purpose to show the hall picture, I hope that will help:
we’re on it.
