I don’t know when this change of behavior happened, but the current behavior is confusing and a source of problems in some cases.
Ideally the “Is Open” Pin should show if the device is open and ready to use, independently if any data has been consumed or not.
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.
Btw if i hover the Output pin, “Is Open” doesn’t change.
Running 6.1-0003
Can you please upload a patch that we can run in 5.2 and 6.0 to see the difference?
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”.
in what sense is it not correct?
What i wrote here
well, but i’d say it does exactly that. how do you say it does not do that?
In my opinion “Is Open” should be enable as soon as the device is ready, without to connect anything to the output.
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.
