Quick reference for input port properties (Idea)

Alphagem-O · August 22, 2026, 2:48pm

Almost every module has input ports to modulate its parameters.

As it turns out, I sometimes struggle to quickly remember cruical requirements for specific ones, such as: ‘What is the range of sensible input voltages (e.g. 0 to 10V, -5 to +5V, other)?’, ‘Is the input voltage translated continuously or stepped (e.g. notes or octaves) and if so, how many steps?’ or ‘Can this parameter be modulated polyphonically?’.

Recent examples I encountered are the input ports of modulation parmeters of Proteus (Seaside) or OFS (docB).

If I am not mistaken, there are three types of input ports: CV, gates and triggers. For CV, the range and polyphony would probably be more interesting. For gates and triggers, polyphonic inputs would be the focus.

Sometimes these answers can be looked up with more or less effort in the respective manual, but in many other cases hardly anything can be found, and one needs to start experimenting with constant voltages, meters and scopes to obtain definitive answers.

And then it might be solved for the current patch — and forgotten in the next one. There may also be a chance by looking at the code, but that’s far beyond my narrow horizon of knowledge .

So, I am thinking about starting a small repository (thread) in order to compile such information for a growing list of modules, so that anyone can use it as a quick reference for streamlined patching.

What do you think? Do you have similar struggles and how do you handle them at the moment? Would something along the lines of a quick reference be useful and would you have any ideas for setting it up?

k-chaffin · August 22, 2026, 3:16pm

My personal approach is to take a sheet of printer paper for each module I explore and I record by hand the exact CV required by each input port for a specific state. I make a note if the the input port has an attenuvertor associated with it that needs to be set to full open in order to get the desired states. While resulting in a lot of paper note’s, I keep the notes in a manila index folder and I just pull out one or a few at a time, depending on what I am working on. Having the CV settings that result in particular eigenstates of the parameter is very handy for sequencing parameters. I typically use an AS Triggers MK1 to dial in CVs and be able to see their value on the digital voltmeter on the module. If the parameter does not have a CV input port, I use a Stoermelder uMap module mapped to the parameter knob and do the same type of mapping using the MK1. I record these voltages and states on my sheet of paper for the module..

fractalgee · August 22, 2026, 3:20pm

Oh, would be very useful, methinks, as you are hardly the only one noticing inconsistencies and undocumented ranges. I can’t live without at least one scope in my patch at creation time. I love polyphony, but sometimes can be maddening that you feed 4 of everything into every in and only stereo comes out (two mono channels) or only one mono output. That ain’t poly, my mind shouts and then off to dg for any module that CAN output that in true poly fashion. Squashed many a ‘in the zone’. session I must say. Everything in and out ‘except’ the Gate in is the worst offense for calling the module ‘polyphonic’ .

I would vote for a convention that no module should be called polyphonic unless everything in and out is polyphonic, or invent a new tag for those that are: `Fully Polyphonic`, or some more imaginative tag.

I doubt we can get everyone to document every range, as documentation is already quite hard for many a dev.

k-chaffin · August 22, 2026, 3:28pm

I publish my modules CV input values and states in my manuals. For Meander with 50+ panel parameters, this ends up being a massive effort.

jaibhimadevi · August 22, 2026, 5:06pm

Amen to more accurate polyphonic labeling- for example, there’s more than one delay module that’s labeled “polyphonic”, but only one is fully polyphonic. A few modules accept poly input, but sum to 2x mono. Yes, RTFM and being aware of use cases/what’s sensible for a particular module is always good practice, but it is frustrating to be in the flow, grab something labeled “polyphonic”, and have to replace it/give up the original signal routing idea, because the module’s not actually fully polyphonic.

stoermelder · August 22, 2026, 6:56pm

In my opinion, the best approach is to include such information in the ports tooltip. I try to do this for my modules.

brer_rabbit · August 22, 2026, 8:32pm

I’ve been adding a clip LED on a few parameters for this. I’ve tried doing that for each & every param but that’s a lot of real estate. I mainly reserve it for frequency CVs, where CV is from a knob + a jack.

Alphagem-O · August 22, 2026, 9:45pm

Thank you for sharing your thoughts, it’s great to see all the different approaches!

No doubt it would be absolutely best if all developers provided proper guidance to their modules.

However, I assume that developing modules is already a major challenge for most people (I couldn’t do it!), and that there will likely always be a quantum of inconsistency. Hence I am looking for ways to bridge gaps and harmonize the information.

I jotted down a first draft of a quick reference template, with Octave (VCV) as an example. It would function sort of like a parameter index card, one card per parameter.

Would you consider something like this useful? Feedback and suggestions would be very welcome!

Octave shift CV input — Octave (VCV Fundamental)

Number of polyphony output channels (module, 1 = monophonic): 16
Number of polyphony input channels (parameter, 1 = monophonic): 16
Parameter data type (CV, trigger, gate): CV
Sensible voltage range: -4V to +4V
Port intensity control: (Attenuator/Attenuverter/None): None
Total number of output steps (#/Continuous/Other): Other: 1 octave step per volt
Comment #1: Standard position (no shift) of manual octave shift selector is the 5th position from bottom
Comment #2: Even though the manual octave shift covers only +/- 4 octaves, the port tolerates +/- 10 octaves and more. Extremes are inaudible
Comment #3: Channel 1 only: Yellow dot display shows octave shift chosen (range of +/- 4 octaves)
Module link: VCV Library - VCV Octave

Octave (VCV)_20260822

Alphagem-O · September 3, 2026, 7:25am

It might make more sense to collect the information in a simple table. Easier to read and edit, and more flexible overall.

Alphagem-O · September 3, 2026, 10:07am

Implemented at: Input Port Properties (Quick Reference)

Cella · September 12, 2026, 5:10pm

Hi @Alphagem-O, it’s a great idea and the results are really helpful (i.e. Proteus) , I also struggle to remember how some modules operate.

I imagine it’s takes lot of time and effort to document one module, and it got me thinking about ways to scale that effort. Given that for most of the modules the code is open, I’ve got an idea to feed it to - don’t beat me - LLM and ask to gather information on input ports their signal processing. LLM’s are really good at code and signal flow analysis nowadays, and major advantage of using them is that they can spot how inputs interact with each other, as well as edge cases. And it’s fast, of course.

Here are some outputs I’ve got for modules you’ve covered, curious what you think. Such analysis can be tuned and automated.

Alphagem-O · September 13, 2026, 2:26pm

Hi @Cella, thank you so much for your excellent suggestion and for spending time on developing ideas for streamlining the process. This looks promising and I am seriously baffled about how advanced AI technology has become in a rather short time.

I think your LLM version clearly is more precise and comprehensive than my tables will ever be, and the information seemingly can be compiled much more quickly.

However, the flip side of this improvement seems to be, IMO, that the presented information is also significantly more detailed and complex. For serving the purpose of a quick reference, I would ideally prefer the user to get a more concise overview without having to dive in too deep.

So, to make the AI-collected information readable without much effort, I believe it would likely still need to be curated/verified/shortened manually to omit excess information, and to double-check the validity of statements, such as e.g. erase hallucinations. I can only guess that this also may take a bit of time and effort, but the result will probably be a much stronger product than what is there right now.

Hence even though I am not sure whether this process will really improve the efficiency of the compilation process, I can envision the AI support as a way to fill in the blanks for a more comprehensive picture. A critical question there will be: How much information would a user want/need and how much may be too much for practical purposes?

In summary, I can see that AI could be a great addition here, as it could for example play a role as a tool in the acquisition of more information (i.e. through interpreting the code). Not sure how good it is in creating a concise presentation to the user though — perhaps this could be tweaked?

If a few points could be addressed, maybe this project could be developed further:

Could AI statements be compacted into a shorter, more concise form — without losing clarity?
Could AI be used to counter check manually established overviews, such as the current table, and correct and amend the info in a useful way?
As I am not proficient at all in handling LLMs, 1.) Who could operate the AI to compile the code analyses? And 2.) Who could compare the LLM-generated records with the code to make sure that statements are not hallucinated or misinterpretations of the code?

Thanks again for your input! Would be great to discuss this further.

Cella · September 13, 2026, 3:07pm

Hi @Alphagem-O , all valid points.

Could AI statements be compacted into a shorter, more concise form — without losing clarity?

It’s definitely more verbose at this moment, but it can be counteracted by instructions and examples given to AI. Might also be useful to produce both concise and extended version - if user wants, he can see more details.

As I am not proficient at all in handling LLMs, 1.) Who could operate the AI to compile the code analyses? And 2.) Who could compare the LLM-generated records with the code to make sure that statements are not hallucinated or misinterpretations of the code?

I can definitely do it progressively. Main question is priority - maybe worth starting with most popular plugins.
It’s gargantuan work to check everything, so I’m not sure any person would subscribe to it. At the same time, code is code, it’s does what it says, and hallucinations aren’t as strong when AI looks at specific codebase. Yet, to be sure, I can counteract hallucinations by asking few different models and then consolidate the consensus.

I’ll try to tweak prompts to get more concise version - your results definitely help to steer that. I’ll share it here.

Alphagem-O · September 13, 2026, 10:14pm

Having a short and a long version might not be a bad idea.

The effort would definitely be progressive. Module priority is a good point. I started with modules that I use a lot and that had me pose questions about their port properties.

Some modules may be less interesting even though they are used often. To me one of these might be Valley’s Plateau. It’s monophonic and I don’t see it to be modulated all that often. So I wouldn’t make it a high priority.

Besides re-running the modules that are currently in the table, I am about to add RndG (docB), so that could be another one. I think it’s interesting that its Clock input is actually polyphonic.

Which other modules do you think could be interesting for now?

Your point regarding hallucinations in code is well taken. I suppose I will verify some of the AI findings at the module anyway, so for now we could keep manual quality control to a minimum. Having more than one AI work on the same task and cross-comparing results is a great idea IMO.

I look forward to a more concise pilot. You can PM me.

chrisgr99 · September 14, 2026, 12:09am

I have only just noticed this thread, and it turns out I have been working on something close to it.

Option-click a module’s title, or any control or port, and a note appears describing that one thing. For an input port the note ends with the properties being discussed here: the voltage range, including whether it is unipolar or bipolar; whether the signal is continuous or stepped; and whether the port takes a polyphonic cable.

The most useful line in a module’s note is the first one: what the module actually does, which a panel of knobs and jacks rarely tells you. Nothing on harmonàig’s face says that it takes one pitch voltage and builds a four note diatonic chord from it. The note then covers whether the module is polyphonic, and what its right-click menu offers, which is often documented nowhere else.

I have been using Claude Code to review my installed library, over two thousand modules. The sources are whatever ships with each plugin — panels, documentation, release notes — together with its GitHub repository where there is one, and from those comes a brief description of each module, each control and each port.

I have checked the results against a number of modules I know well and they hold up. This is LLM output, so at least a small amount of it could be wrong. Set against that, what exists today for most ports is a name and sometimes a tooltip, and for a large number of ports these notes say more than the tooltip does. The notes are mine rather than the maker’s documentation, and they say so.

I built it for my own use. If there is interest, it will become a feature of my Clarity plugin, off by default. Either way there will be a pre-release build when it is ready, and I would sooner have it used against modules people know well than finish it in private. I will post here when there is something to try.

Alphagem-O · September 14, 2026, 6:26am

That is an amazing development, thank you for sharing it! Having crucial information easily accessible right there would be super useful, IMO.

Since it would be so prominent, the quality of the content in this place becomes most important, i.e. it needs to be concise and informative or else it may be more of a burden/nuisance to the user.

One (minor) disadvantage I see: Having it baked into a module, it is more difficult and laborious to maintain compared to a simple Excel table that lives in a forum or a cloud drive. However, this is probably far outweighed by the accessibility.

I have one more thought, slightly off-topic and in more general terms: I firmly believe that the source of an information is often just as important as the information itself. AI is now taking on so many tasks and is rather ubiquitous.

Therefore, I think it should be mandatory to let a user know if a piece of information was (fully or in part) generated with the assistance of AI. It should be fully transparent and the user should be made aware immediately, and not have to spend much time and effort to become aware of it.

In this case, I could for example envision a very short disclaimer at the bottom of the box. On pictures it is already being done sometimes with a small text somewhere in the corner. Would that be reasonable?

chrisgr99 · September 14, 2026, 4:29pm

@Alphagem-O — thank you. I agree with all three points.

On conciseness: the port property line is assembled from a fixed vocabulary rather than written — four facts at most, always in the same order. The descriptive text is limited to one or two lines per port. Nothing appears on screen unless it was asked for.

On AI disclosure: I will find a concise way to note in every help pop-up that the information was compiled with the help of AI. It belongs at the point of reading rather than somewhere a user has to go looking.

On maintenance: a shared repository would be the way to go, if others want to participate. It would let anyone check the basis of a statement, correct it, or add records for a module I have not covered. The obstacle at present is that the data is a large number of JSON files rather than anything organised for other people to use.

One thing I should disclose before sharing the data, since it will be visible in the records themselves — each item carries a reference to where it came from. For most ports the information came from the plugin’s materials: its manual, its panel, its published source. The agents’ brief was to find the information, not how to find it. Where no such source existed, they found a way to look at the machine code immediately around the port’s implementation — which was not an approach I asked for or anticipated. In the large majority of cases it established whether the port is polyphonic, and the type and range of the signal the port expects. That amounts to disassembling a small part of a closed-source plugin. I would like to use this information in the help text, and it would also be in the data. Each record says where it came from. If the developer of a closed-source plugin would rather it were not used, tell me and I will remove those records from both.

Coverage at present: complete help and metadata for just under half the modules in the VCV database, those being the ones I had installed. The rest is a matter of installing them and running the same analysis.

How it was done, since it bears on how much to trust it. It was not one sweep. It took three or four passes over the library, worked in segments, with my own intervention at points. Claude Code ran it as a fan-out, at times twenty agents at once, each with a brief covering a group of modules and one kind of data. That is what made a library this size tractable, and it is also why the passes were needed, since consistency across that many workers has to be enforced afterwards. The passes served a second purpose. A later pass, with different agents over the same modules, checked the earlier findings and corrected them in a fair number of cases — close to what Cella suggested about consolidating more than one opinion. The data has been gone over more than once rather than taken from a first answer.

A further possibility. Once the data is public and in a regular shape, it is no longer only the text inside my notes. It becomes a searchable reference to what modules do, which a user could put in front of their own AI assistant to ask which module does a given job.

Alphagem-O · September 14, 2026, 8:18pm

Wow, it appears that you’ve already done a tremendous amount of work on this!

Half of the VCV Library still amounts to approx. 2000 modules, which is impressive.

I understand the concerns about a developer’s consent, especially with proprietary code. Please be aware that regulations in different geographical regions might be different. Activly asking for consent of closed-source code seems to be the right thing to do. I’m sure that many developers have put a lot of hard work into their plugins, IMO, and they may have their reasons to keep the code hidden. And you probably don’t want your effort to be discredited either because anyone feels that they haven’t been ask permission.

Just to get a better idea, could you show an example or two of pop-ups for modules that were already touched on here, for example OFS or Proteus or any other? (Although I don’t know which ones are open-source and which ones are not, so that might be worth keeping in mind.)

chrisgr99 · September 14, 2026, 10:03pm

@Alphagem-O — thank you. On consent, I agree, and I will ask before publishing anything derived from closed code.

Here are examples of what the help produces, for Proteus (Seaside Modular), one of the modules covered earlier in this thread. Proteus is published with source, so these came from the source at the installed version.

That is the module note, from option-clicking the panel: what the module does, the few things worth knowing before patching it, the polyphony, and the right-click options.

Those are two input ports, and they are the part relevant to this thread. The middle line carries the properties under discussion — range, continuous or stepped, and how many channels the port reads. It is assembled from a fixed vocabulary rather than written, so it reads the same way on every module. The line below covers what the jack does when nothing is patched, and what a negative voltage does.

Controls get the same treatment: what the control does, and where its extremes sit.

On the closed-source modules, to be accurate about the method: the agents were given the values to find, not the way to find them. Where the plugin’s own documentation was incomplete and no source was published, reading the machine code around the port was an approach they arrived at themselves, not one I asked for or anticipated. No code was copied and none is kept. Any developer who would rather their modules were left out, or would rather supply the values themselves, only has to say so. Where no value was established, the note says so. Option-click a port in Clarity and the help reads “value ranges not available”.

One practical problem. Contacting developers one at a time would take a long time, and dropping every module with closed source would leave unfortunate gaps. Does anyone know an efficient way to reach plugin developers as a group, or to make them aware of the question? Failing that, developers reading this are welcome to supply the values for their own modules by contributing to the shared repository — that is better than my deriving them, and faster for everyone.

Alphagem-O · September 15, 2026, 5:50am

Thank you for the examples, this looks amazing! I think the integrated help boxes could become exceptionally valuable for a lot of folks.

Perhaps @Cella would also like to weigh in here to join efforts and avoid duplication?

There still is the question of how to best present the information, and whether perhaps, in addition to the boxes, more verbose short and longer external versions may also be useful in case someone would like to dig deeper.

No authority here, but what do you think about starting two threads here in the Forum: One for consent and the other for voluntary contributions by developers and users?

Even though you may not reach everyone this way (and especially for consent would still have to contact a fair number of the closed-code developers directly), it might still be a good starting point.

I looked at your GitHub page, which looks very neat and organized. Does the current version posted there already include the features you describe for interested users to try out, or when would it be ready for trial?