This is not so much a bug but rather a missing feature. The feature request would be “Allow New Panel Cables to be summing jacks”. What happened is we added summing nodes (multiple outputs running to an input jack), but the New Panel Cable feature did not offer an option to add a new summing output.
So, clicking “New Panel Cable” and having a list of Panel Outputs show up is actually useful and correct – the output will be a split from the MIDICV jack. E.g. if you want to monitor whatever is coming into the EnOsc input you could add a new panel output to do that.
But what’s missing is adding a new Panel Input that sums with the MIDI->CV jack signal.
I think the way your PR works, you would choose input or output by choosing to start with the MIDICV output jack or EnOsc input jack. That makes sense. Another way is to offer both options at both places: “New Panel Out Cable” and “New Panel In Cable”.
The long-winded explanation of what’s happening:
Before summing jacks, you can only have one output per node. So, MIDICV is the output jack, and EnOsc is the input jack. Adding a New Panel Cable is only allowed to add a new input (since there already is an output on the node). Confusingly, Panel Inputs are outputs, and Panel Outputs are inputs. That seems like a contradiction or typo, but it’s correct – Panel Inputs are physical jacks that send signals to modules and sending signals to modules is what output jacks do; therefore Panel Inputs are output jacks. Similarly, Panel Outputs take signals from modules, so they are inputs.
So what happens here is when you select New Panel Cable, it sees there’s already an output (MIDICV) so it only gives you the option to add a new input – which is the list of Panel Output jacks.
When you do it in the reverse order (New Panel Cable → pick a Panel Input first), there is no output jack on the node yet, so you get the list of Panel Inputs (which are outputs). Then when you create a new cable, you are actually creating a summing node: the signal coming in from the Panel Input is summed with the signal from the MIDI->CV module. This relies on the summing jack feature recently added, which the New Panel Cable button ignores.
I think this stuff can get so confusing that it’s important to make the interface metaphors consistent. The way it exists in my mind is:
Internal cables are like physical cables. (They might be Tiptop Stackables, where you can connect multiple cables into a single jack.) You only ever want to map inputs to outputs.
“Panel cables” are mappings — you map a physical jack on the hardware to a virtual jack within the patch. You’d only want to map a physical input to a virtual input, or a physical output to a virtual output.
I think it’d be wise to restrict the interface to those connections – if you’ve got a cable from the MIDI-CV output to the EnOsc input, and you want to monitor that from a hardware output, you map the MIDI-CV output to the hardware output. If you’ve selected the EnOsc input, you can connect it to a virtual output with a virtual cable, or you can map it to a hardware input (which as you point out manifests as a virtual output), but not to a hardware output.
Honestly having thought about all this I might rename “Panel Cable” to “Panel Mapping” or “Panel Jack Mapping” to reinforce the distinction. This has never bothered me until today though.
I get that New panel cable" is a useful connivence.
Personally, Id prefer to just have input and output modules, as vcv does (and other virtual modulars, and arguably eurorack).
IN/OUT modules are good entry points, to adding functionality such as gain staging, DC offset removal (optional), vumeters /scopes etc.
also for consistency / new users, they act like any other module, so less cognitive overhead.
you dont even have to treat them ‘special’, e.g. say you can only have one instance, as you can do things like auto sum.
I guess this is a feature request - lol … @danngreen , does the (native api) SDK have direct access to the IO / buffers, so I could build my own?
@gabrielroth
Hmm… I see what you mean, it makes the system clear if Input jacks get a “Map to Panel Input” button and output jacks get “Map to Panel Output” button.
There’s one thing missing, which comes up when summing two (virtual) outputs on a (virtual) input jack. If you wanted to monitor the summed signal that the input jack is actually seeing, you would need to be able to “Map to Panel Output” on the Input jack. Going to either of the two source output jacks and doing Map to Panel Output there would give you only one of the signals, not their sum (which is what the input jack sees). It’s probably not a common use case, but still valid.
Maybe a solution is having both Map to Panel Input and Output buttons on all patched jacks (unless it’s impossible, like a totally unpatched input jack wouldn’t get a Map to Panel Output button)
Or both buttons could only appear if there’s a summing situation, but that probably ruins the clear-cut simplicity.
(It could in reality be one button and you pick an Input or Output, but the same choices and logic would apply.)
There’s no direct access, there are only panel maps. The AudioStream class queries the PatchPlayer (which handles panel map sums/splits) about the signal on each panel output and then copies that to the buffers.
As for dedicated output modules, that could be done with a module that automatically creates panel mappings when constructed/added to a patch. The only change firmware would be having some way for a module to create mappings. We could make an API for that (add_panel_mapping), we already have a thread-safe queue for patch modifications, so it’d probably be a simple thing without any architectural changes.
Back in the beginning, I had considered having builtin dedicated panel modules. I had pictured it as a patch bay on the bottom edge of the screen (closest to the actual jacks). But doing it that way makes the patch noisier with more cables and more modules, so I decided not to. Such a view could be toggled on/off as a option in the Patch View. Essentially it’s just a GUI preference.
that’d be great, they we could create our own input/output modules
if its a small change that be really useful.
(I assume the panel mapping already handles multiple mappings to same output port , and sums?)
yeah this would be nice, yeah bottom makes sense due to physical jack placement.
however, as you say if its fixed, it uses up precious screen space.
Id be tempted to have a ‘1u like’ row on the top of the rack, so that it scrolls along with the rack, that said, scrolling with a new row size is possibly tricky.. hence I though a standard 3U would be good.
I mention 1U mainly, as I though outside of this (for bus modules), 1U support would be so cool, but then again, VCV does not support, so it’d be rather limited (to MM modules only)
OK, so there’s two options for this situation:
(1) add “map input to output” functionality,
(2) users add a mixer module when they want to monitor a merged input.
Still under the “my 2¢” rubric:
Option (1) adds an intrinsically complex UI feature that the user will see during patching whether or not they want to use it, that forces them to think about the difference between virtual inputs and physical inputs, in order to support a use case that I suspect is pretty rare. Note that this thread exists because I saw this feature and thought it was a bug!
Option (2) requires an extra step and a bit more CPU during the rare use case, but avoids the confusion during normal use.
Personally, I’d go with option (2) — makes things easier most of the time, and doesn’t prevent any usage.
Ok, I apologize for the friction here, I’m on board now with your suggestion!
I had mistakenly thought the current firmware allowed us to map a Panel Out jack to a summed input jack, but actually what it does is create a mapping to one of the output jacks before the summing. So the feature I was trying to protect hadn’t been working since we added the summed inputs feature.
I think your PR is then correct – it removes the buggy feature, simplifies the mental model (Inputs->Panel Inputs, Outputs->Panel Outputs), and lets you add a Panel mapping to an input that’s already patched (creating a summed node).
While investigating this, I found related issues with the “Connected to” list in the mapping pane and on the list of panel maps on the jacks page. Connected panel and virtual jacks were sometimes not listed in complex cable split/sum/mapping situations like this:
