Midi input port should accept "nil"

A mildly bugging element in vvvv45: disconnected midi controllers causing red nodes throughout all subpatches.

I’m working with midi controllers a lot, but don’t have them connecting all the time. Especially when working just on small fixes, quickly. For those moments it would be great if MidiNote and MidiController could accept “nil” as a valid input and output; without causing red nodes throughout all subpatches.

please test with current alpha. didn’t change the behavior of the node, but only accepted (nil) as valid input

Runs like a charm. Thanks!

Red NIL input is back in beta35.5, my patch is flaming red :(
Bug or feature?

@gregsn anything you can do about this?

hey mfo,

i guess sometimes you may perceive it as a bug and other times as a feature.
So now we have a flag that you can switch via main menu: “Report enum problems”.
If reporting is turned off, we don’t propagate enum errors to parent patches. That way your patches will not all be red all over the place. However, still, visible enum entries in your inspector or in your enum io box showing an invalid entry will still be displayed in red.
please check latest alpha!


Hi gregsn,
thanks for the insight. Indeed “Report enum problems ON | OFF” works. However, this prevents all enum problems, real problems, from being shown. Not really what I would want.
This brings us back to square one, the reason for this topic. I think NIL should be considered a valid input for Midi devices - simply a disconnected device. Of course depending on your vantage point, you might think of a disconnected controller as an actual problem. But is it a bug? (What red marking indicates to me.)
Would be a prime example for the differentiation between Warnings and Errors. Afaik vvvv doesn’t haven any differentiation of that kind, does it?

hm. Red never was about bugs. Because if we would know of a bug we would typically try to fix it instead of coloring the node. So red nodes always report a problem that arises through the use of the node and is suposed to tell the user to adjust something to make the node work again.
Using those midi nodes without any device will make them not work, so i guess you can say they have a problem.
Sorry but maybe you should lay out the whole workflow that you are thinkíng of: When do you want to switch to the “(nil)” or “no midi device” entry and when do you want to switch back? Do you want to get reminded that you forgot to switch back any node?
In your first post you said you want to do small fixes quickly. Why not just ignore the fact that those nodes aren’t connected to a device and just do your changes anyway as you know they will work as soon the device is back up again?

Is anybody else feeling the pain?

Yeah, you are certainly right about the Red.

Regarding workflow, I build my application (sort of live performance tool) for use with several Midi controllers. When maintaining it, I’ll not always have all controllers set up and plugged in - partially because I’m not at home, partially because someone borrowed a controller, partially because I’m too lazy. In those moments the Midi port jumps to Nil. There are alternative input methods, i.e. faders on screen. So, there is no problem. To say so: leaving your car in the garage and going to work by bike doesn’t mean there is a problem with the car.
I don’t see the need to highlight in Red.

In any case, if no one else is “mildly bugged” by this, then let’s close and forget about this thread.

hey mfo!

But your midi nodes stop doing anything, when no device is connected, no? I mean can you still do meaningful changes, when you don’t get a proper feedback? And then tebjan told me of loopbe, a tool for creating virtual midi devices - do you use stuff like that?
Also nowadays enum entries shouldn’t switch to (nil) when no device is available. Instead all entries should stick with what you actually chose lately.

Soo. For now i hope that the one or other trick can be plugged into your workflow!

  • just ignore those red nodes or
  • turn off enum error reporting or
  • use a virtual device.

At least as long as nobody else is jumping onto that issue. Thanks! sngreg

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.