Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inlet/outlet vanilla incompatibility for 'atom' boxes. #1908

Open
porres opened this issue Oct 18, 2024 · 3 comments
Open

inlet/outlet vanilla incompatibility for 'atom' boxes. #1908

porres opened this issue Oct 18, 2024 · 3 comments

Comments

@porres
Copy link
Collaborator

porres commented Oct 18, 2024

In Vanilla, if you set send/receive symbols to number/symbol/list boxes, the inlet disappears.

I think I see the logic in that. If you have a send symbol, why do you need an outlet? Right?

Well, iemguis, which was an external library, thought it was cool to add an inconsistency and create this idea of a hidden but functional outlet. That was really stupid if you ask me, but the worst is that this was incorporated into Vanilla and this inconsistency was probably overlook and not noticed.

This has allowed people to hide inlets/outlets with dummy symbols just to hide inlets/outlets and I actually like doing that, but it's a stupid hack and it'd be better to just have a setting to hide/show inlet instead.

I actually just like that GUI elements have inlets/outlets hidden while in run mode as in MAX.

Well, enough rambling and contextualization. I'm actually here to say that PlugData has created a patch incompatibility to Vanilla, as you made atom boxes consistent to the way iemguis behave.

I do like that idea and I will probably make a PR so that this consistency is a reality for Pd Vanilla, but while that doesn't happen, you have an extra feature that breaks patches if they are opened in Vanilla if, for instance, you have a number with a send symbol and a connection from the outlet.

I think that such an incompatibility and breakage goes against a golden and sacred principle to never create patch incompatibility, so I hope you can keep it 100% compatible for now and I will do the best I can to try and promote this change to Vanilla so you can also apply it here later.

@timothyschoen
Copy link
Collaborator

timothyschoen commented Oct 22, 2024

I do like that idea and I will probably make a PR so that this consistency is a reality for Pd Vanilla, but while that doesn't happen, you have an extra feature that breaks patches if they are opened in Vanilla if, for instance, you have a number with a send symbol and a connection from the outlet.

I think that such an incompatibility and breakage goes against a golden and sacred principle to never create patch incompatibility, so I hope you can keep it 100% compatible for now and I will do the best I can to try and promote this change to Vanilla so you can also apply it here later.

As far as I understand, this does not actually create any incompatibility. Iolets with symbols are always hidden when in run-mode in plugdata, as they are in pd-vanilla. So when running the patch, there is no difference.

When editing, plugdata allows you to create connections to the invisible iolets for both atoms and iemguis (and it also gives you visual feedback about this). Again no incompatibilies there, since Pd allows this too (if you first connect and then set the send symbol, you can get into this state with atoms too).

Maybe I misunderstood, but I don't see any incompatibilities here?

@timothyschoen
Copy link
Collaborator

Ah, okay, I see what you mean now!

If you first connect and then set the send symbol, you can get into this state with atoms too

This was a wrong assumption by me, whoops.

@timothyschoen
Copy link
Collaborator

I see: this is even a problem if you reload the patch within plugdata! Nice catch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants