the behavior you describe that the midi device is only opened the moment the data is consumed is actually by design and it is like this ever since. it would be interesting to learn more about your cases where this design causes problems.
maybe related: looking at this, we indeed just found a bug (already present in 5.2) where you’d get an error when only hovering the output of the MidiIn node with the mouse. this is now fixed for > 6.0 and you should see: while hovering the output (when nothing yet is connected to it) with the mouse, you’ll see the “Is Open” output to be true.
I think the 5.2 behavior was correct, other thing is if it has created other problems while hovering.
How to deal with this situation?
i have been using this pattern since i started to work with Gamma.
But now with 6.0, if the content inside the “if” region is not evaluated, the Midi In node will never be Open.
Sorry @joreg, it looks that i was always using several MidiIn nodes in my applications as a rule, and one of them connected to a “hold latest”.
I have this habit probably because of this behavior and after years of use i forgot the reason.
In any case, i would think on informing the users about this behavior, or change it (if it doesn’t break anything), it’s not 100% right to say that the device “is open”.
well, but let’s recap: in the beginning you suggested there was a change in behavior in recent versions. we have established that this is not the case, right?
so now you’re suggesting that the existing design is flawed saying it is “a source of problems in some cases.”. can you elaborate on those cases to help us understand the issue? we then can maybe help solve those cases independenlty of changing an established system.
This behavior was always like that, sorry again for my mistake.
I already explained that due this undesirable behavior i have used other strategies in order to force the “Is Open” pin to show if the device is actually open, independently if any data has been consumed.
As i explained in this thread before, the picture above is a good example of using “Is Open” pin is a source of problems.
To recap:
-If i need to consume the output in order to trigger the “Is Open” pin state, IMO its behavior doesn’t correspond with its description (name).
-Ideally this pin should show if the device is open and ready to use, independently if any data has been consumed or not.