Thanks for the responses. I decided to report it as “headphone cable bug” to VCV Support.
1 Like
Maybe it’s been suggested before, but I’d love to be able to tag or custom-label everything in a patch: in particular change the text labels that appear when hovering above buttons, knobs, inputs and outputs, maybe also label individual cables or a specific module when it’s right-clicked.
Purposes:
- It’s in the nature of CV itself that most things can have multiple possible usages in a patch, depending on cable routing. It would be hugely practical to be able to quickly remind myself what a particular output/knob etc contributes to in my patch. Instead of having to figure out the logic by tracing back spaghettily chaotic cable paths in a patch I made months ago to, I could label a knob by semantic purpose, and see it by just hovering the mouse above it.
- Besides, several modules out there are poorly or unclearly labeled. Requires RTFM.
- I know there are label and text modules, but they are too spacy and fiddly to completely fill this purpose.
It would be neat if this could be done by adding a second field to the right-click dialog of everything: in addition to the value field for a knob etc, there could be a text field above or below it, where I could enter text that would apply to only that knob - and of course stored with the patch in the .vcv format.
Of course, if no text is added, the default value is the factory label. Or maybe even always display the factory label anyway but add the custom one if it’s set.
Edit: weird language 
2 Likes
I have been thinking about this feature as well. I don’t think I will do anything for VCV as a whole, but I have seriously considered adding the feature to all parameters, inputs, and outputs of my Venom modules. Rather than add an additional field to the hover display, I would simply let the user override the default names, with a mechanism to restore the factory default names.
Upon thinking a bit, I might be able to create a Venom module that could relabel parameters and ports of non-Venom modules (and save the values with the patch, automatically restoring custom labels upon load as long as the relabel module is still present). Such a feature is the type of thing that Benjamin Dill might do with his Stoermelder plugin. But if I decide to extend my Venom plugin with the feature, I might consider adding a module for relabeling any module.
2 Likes
VCV with a floater menu like Autocad for access to some commands CAD Systems double click in scroll bar for a zoom extent for example. And a set of commands by line of text whit shortcuts like Ableton Live Add Selection must be think like a libraries of blocks maybe this is a new topic for the community to share free or payment. Access more easy the edit the patch of vcv by text in a text editor
1 Like
It would be nice under engine, the threads, 1 (lowest CPU usage) 2 (Most modules)…
to save with the patch.
2 Likes
Hmm. I’ll have to try that with BlackHole.
It may even serve as a workaround for another beef of mine. Whenever you select a different output in the VCV AUDIO module, it resets the Sample Rate to 48 kHz and the Block Size to 256. And it does not change it back when t=you return to the original output.
[a few minutes later] Yup. I used a “BlackHole+Headphones” output, and it does not crash when pulling and replacing the headphone plug. It also does not reset the sample rate and block size. Switching it to Speakers does reset them though.
1 Like
Also little req about lib management conveniency. Would be good to add option to displaying modules in kind of text form (with no images), like simple list with vendor’ names folders. That can be useful especially in very large collection installed case. AFAIR sometin similar was in pre-vcv project.
Not sure what you need this for, exactly. What do you want to do with that information?
Scan your installed plugins folder and list out the attributes you’re interested in from the plugin.json there. Depending on what shells you have on your machine (e.g. powershell), could be done entirely in shell script. Perhaps best thing would be to output a csv with columns for vendor, plugin, module, version, etc.
Ummm… don’t most operating systems let you browse the file system without huge images?
Go to the Library, click Plugins (takes you here), then click Owned. To see the modules in a plugin, click the arrow on the left.
This would appear to be the information you’re after, if not in a plain text file.
Guys, i mean inside VCV UI, not in files\scripts, nor thru VCV web site (which made very good).
This wish is because the moment of trying to add a module to the rack, when after RM click, by default everything opens at once in the form of a stack of previews.
Further movements may vary, using the top line (sorting by brand, searching, etc.), but the very first moment of opening such a mass of pictures:
a) Creates a certain (although not critical, but still) delay. b) Has an aesthetically questionable impact lol.
Meanwhile, it is possible to do at least assign another default browsing state ? For example show only for pre-selected brand (as default).
There is this from Stoermelder, it replaces the Module browser with the one from 1.1 or even 0.6 (as shown)
1 Like
@Yeager Thanks it seems what i meant. But in any case better when implements such impact as native. (Enabling optional ofcourse). For avoid some mismatches with original building.
1 Like
One could say that about many of the thousands of free modules developed for VCV, yes?
Ideally, VCV has its own interface for visuals as a scope update by ModularFungi (code by Omri Cohen) Thinking music with visuals is a necessity in terms of exposing polyphonic frequencies, low frequency modulations, etc… it is a necessary task in these days. Insistent data entry exposure is beauty.
Hmm Well, honestly, i did not go into technical way of integration of addition that mentioned by Yeager, actually you can be technically right. But in any case, health of host is a higher priority than of an individual plugin (which can cause crash in worst case, but without access to host main files for change\break them, well i hope lol).
1 Like
Any plugin can crash host and do whatever it likes.
It seemed to me that the plugin should be in some kind of shell of rules that do not allow it to change program files (not in the context of the current session of use, but in a permanent sense), as if, for example, a plugin failure damaged the host design/engine (UI or some sound settings etc), and to restore by default it would have to reinstall whole program . I hope this scenario is unlikely in VCV case.
usually in most programs the plugins do not operate in some kind of “sandbox”, like you are suggesting. If you would like to develop some plugins for VCV, you are welcome to consult the online documentation and do so.
something else: also mandatory OFFLINE documentation.