Quick reference for input port properties (Idea)

Kudos, high praise, much respect for all the work you have been doing with Clarity, Test Gear, Help. I am going to list things I don’t like or think should be improved, but don’t take offense. Calling out all the things I like and am impressed with would be exhaustive to write, and to read!

I will put notes for Clarity, Test Gear, and Help all in this post. Perhaps Clarity and Test Gear notes belong in a separate thread. Let me know if you prefer this info as GitHub Issues.

All my testing was on a Windows machine.

General

I think your modules would look better without the screws. As it is the screws currently overlap elements of your faceplate graphics. You could reformat your faceplates a bit to make the screws look better, but it seems simpler to just remove the screws.

Test Gear

  • I think Switch and Attenuverter would work well on outputs, not just inputs
  • Perhaps Switch should be renamed Mute?
  • Note is redundant with VCO. I think Note should be removed.
  • VCO is not really voltage controlled, so should it simply be called Oscillator, abbreviated Osc?
  • DC Level and Volt/Oct both do the same thing, but just use different scales. Perhaps combine them into one with an option to choose scale of Volts or Pitch (assuming 0V = C4, v/oct). Tool could be called Constant Voltage
  • It would be nice if Voltmeter Peak showed both min and max. Or allow user to select current, min, or max.
  • I struggled to configure Scope to work effectively with LFO signals. I couldn’t get the speed slow enough to be useful, but I think there are other issues. I’m just not sure what they are. Also resizing was very temperamental. I struggled to grab on to the edge to resize.
  • After attaching a test gear to a port, click and drag on the port no longer creates a cable. Once I click and drag away from the port, then subsequent click and drag operations successfully create a cable.

Help

  • Scroll sometimes appears when it is needed, sometimes doesn’t. I haven’t figured out a pattern yet.
  • Help does not recognize controls or ports on my Venom Envelope Factory that are not direct children of the faceplate. Envelope Factory hides stages that are not needed by placing all the controls and ports for a stage on a child faceplate that can be hidden or shown. These are the controls that are not being recognized by help.
  • It is possible to instantiate multiple audio readings that overlap. Ideally only one should be allowed at one time - starting a new one should terminate any prior reading.
  • Clicking on a line to speak seems counter-productive
    • If a user can see well enough to determine which line to click, then speak probably isn’t needed
    • If user can’t identify the line(s) to click, then it is kind of useless
  • I think if speak is enabled, then simply option clicking the module/control/port should automatically speak the entire help.
    • navigation options could be added to scroll forward, backward through individual lines, and/or stop the speaking
  • Help popup and speak could be totally separate options that can be enabled/disabled independently. Option clicking an item could then speak, or open the popup, or both.
  • Maybe allow the user to configure what key and mouse click combination is used to activate the help.
  • I am surprised the help must be compiled into the plugin. Maintenance seems untenable with the pace that new modules are being created. Wouldn’t it be better if each plugin help file was stored somewhere in the VCV installation and loaded on demand? Then users can add, correct help without recompilation
  • I really dislike the YMAL format you currently have. It is hard to correlate all the various attributes that are spread throughout the file to their corresponding control or port. It would be much easier to read and maintain if the file were arranged hierarchically. It would be much easier if all the module level attributes are collected in one place. Likewise, all the attributes for each control or port should be collected together.
  • Assuming you adopt a hierarchical structure, then I think JSON would be easier to maintain directly. There are plenty of text editors that can do bracket matching to assist. JSON would also be more conducive to on demand loading.

Dark

I like the concept, but I think there are issues with the execution. If these issues get resolved, then I definitely would use it!

  • I don’t understand why VCV modules that have light and dark themes still have some of the graphical components modified by Dark. For example, the VCV Audio module.
  • Some faceplate components don’t have enough contrast after Dark is applied. For example, the VCV Host has horizontal linework that gets lost after Dark is applied.