Allow not to try to make connections so easily

[porres]

When editing patches in PlugData I can easily make unintentional connections.

The nearby area it considers to make a connection possible is quite wide and bigger if compared to Vanilla. Can we make the area configurable?

I'd also like to configure that no connections from inlets are possible? As sometimes I just wanna grab the object and move it around and I end up making a connection from the inlet... I already mentioned this in https://github.com/plugdata-team/plugdata/issues/1638

So, in short, 2 new options to configure

• reduce the area
• don't allow connections from inlets

[alcomposer]

Max, and every other port node graph I have come across allows inlet & outlet to make a new connection. I think we can close this for now, as having inlets visible, but not draggable would be confusing to new users to patching, and users coming from Max or other patching environments.

[porres]

I think we can close this for now, as having inlets visible, but not draggable would be confusing to new users to patching, and users coming from Max or other patching environments.

Can we reopen though, since you ignored in your point the actual request which would be to make this 'configurable' and not the default setting for new users. I am not asking for this behaviour to simply change or that it'd be the default, which is what your point considers.

Also, you completely ignored the other request, which would be to configure the area for possible connections.

[porres]

I feel like I need to elaborate, so let's go. Also, I'm influenced by previous discussions on the forum, not only with you, but as well as other users.

I get that you feel it is intuitive that a connection could be made from the inlet to the outlet.

I am also completely aware this is a possibility in MAX, so let's get this out of the way...

I'm also assuming that there is a preference to mimic MAX, not only from this, but other things not worth mentioning now to prove my point. Well, actually you also put this yourself, by praising and favoring someone coming from MAX.

users coming from Max or other patching environments.

I like how coming from Pure Data and all of its forks so far is simply completely disregarded and not mentioned as one possible "patching environments", I find this really interesting and problematic to imply Pd Vanilla, Pd Extended, Purr Data, Pd-L2ork and Pd-ceammc aren't worth noting as patching environments :)

So I get there seems to be a very strong opinion that separates these into different classes and stuff. Such types of feedback and requests that merely mentioning workflows that people miss from these apparently non patching environments may be considered like “asking Pages to behave and look like Microsoft Word”… not to mention a possibility of being accused of suffering from Stockholm Syndrome :) So forgive me if I’m wrong, but I’m getting a weird vibe and hostility here when it comes to even consider adding an alternative for people that are coming from the same family of software (siblings actually). It’s very very weird that such a feedback isn’t considered and what prevails and settles the discussion is favoring the expectations of people coming from MAX… (which is more of a distant cousin rather than a sibling).

I also hear that the ‘audience’ is supposed to be different, as if you don’t really care much about even opening the back door for others to join the party…

Then I guess you can’t be surprised why someone like me hasn’t really been using this software all along, as it feels like it’s very hostile to my profile and there is no real intent to listen and open it up so I feel more comfortable here :)

I’ve worked with MAX long enough to understand that being forced into a featured creep environment is not a matter of adapting (neither a Stockholm Syndrome), it just really really annoys me and I’m not up for being forced into working with this piece of software if this is the only route it cares about.

Anyway, I briefly mentioned how I’m making connections too easily and the request was just concerning that. Since I’m talking so much, let me also elaborate on this. I’ve never missed these kinds of feature you’re offering in all my life by the wat. After many many years working with Pure Data, I can say I’m not frustrated at all on how it’s working and I’m really really far from missing something that would help my workflow making connections. On the contrary… I am missing many features and functionalities from Vanilla that the vast majority of PlugData (and MAX) users have been completely oblivious of, since they’ve never seen it I guess… and even bringing that up into the forum seems to shock some people that can’t believe this is a possibility.

So, let me tell how this gets in the way… and I guess people who had to live with this and feel glad about ‘shiny things’ and ‘information load’ never challenged this cause they had to take for granted the implications involved, but it’d be nice to hear other people’s point of view and feedback (when I feel like there’s not even a good opening to hear and ask for that). So, this gets a lot in the way when you have too many objects packed together, which can happen a lot I must say…

Do I need to detail? Think of two objects packed in and very close to each other, with a cord only a few pixels long and you want to grab from the outlet of the object and you can quite easily accidentally grab a connection from the inlet instead.

And this takes me to the other request I had, cause if you try really hard to make a connection at any cost, I can’t even just release this undesired connection coming from an inlet to make it get lost in the air and try again, no no no… it will find a way to connect somewhere that wasn’t even close and that I even never dreamed of…

And hey, by the way, I have yet a third requirement that I was quiet about, but now I can also bring this to the table.

Also let me tell you a story to tell you where I’m coming from. I offer a handle to resize [scope~] in Vanilla. We were cloning that from MAX and I know that in MAX you can do that from all corners. We honestly couldn’t do that because we felt it was a really stupid and ‘creepy’ feature. Having it on the bottom right corner was pretty much enough. It’s simple and efficient.

I find it a ‘feature creep disease’ when you try to hard to make every possibility happen and don’t care about all the visual noise and information load.

Let’s add this to the inlet to outlet connection, cause now if I want to click and drag an object I have to be careful not to accidentally make a weird resizing from the top left corner, as well as drag a cord from the inlet, when I just wanted to drag that object towards the top left part of my patch window…

So yeah, a third configurable request I have is to diminish the possibilities of resizing an object :) if these two requests weren’t enough.

You know what I find myself doing? Resizing a bang before I try any connection… and other things.

When you try so hard to help people, you might be getting in the way. When you try so hard to fix things that ain’t broke, you might end up breaking it. I feel like I need to work extra hard and like I’m performing surgery and make very very precise movements so I don’t accidentally cut an artery and kill my patient…

I get there is a conflict in design principles, I’m much more ‘KISS’ (keep it simple, stupid) oriented, and I really love it and I wish there could be at least some flexibility here to acknowledge that some people might prefer this approach and might be very very happy with what Pd offers, and will feel unmotivated when they find themselves in the “MAX wannabe Pd mutant version”.

Being from the same family of software, I’d think that merely considering happy Pd users wouldn’t be so much of a hassle. And honestly, after what I’ve faced recently on the forum and stuff, I’m working really hard to find motivation to keep insisting and I’m really close to giving up and just focus on all the rest I do and am happy with.

Anyway, I can’t reopen this and I will open a new issue and refer to this one and I will just make it very very short that reducing information might be of interest for some users, and I hope you can improve the attitude towards debating this, hearing out, and actually consider this instead of bluntly rejecting without any real debate and even ignoring most of the request and points.

[porres]

There's a new issue to revive this, but I would also add more to my previous statements

I get that you feel it is intuitive that a connection could be made from the inlet to the outlet.

I could elaborate on this and actually challenge it.

I can see it would make sense to also allow that, but you put it in a way as if there was no distinction and it also ignores real day to day workflows where this might get in the way and I already mentioned it, but I'll also say that it should be pretty clear that both should not be equally weighted.

The way it is, it's like you would do both things 50% of the time, and I don't think that it is actually the case in any way!

My car can ride on reverse, but I have 5 gears to run forward and do that most of the time. If I were to pick one direction, I'd choose going forward only...

Now, if you had a gun in your had and had to pick one to save your life, would you choose to always make connections from bottom to up?

It does make better sense to write patches from the beginning to the end and follow the path of the dataflow. At least this is how I always always always work...

I start with an oscillator or noise source, go into a filter, I never start with [dac~] :)

So the way you make it look is that is somehow unintuitive to prevail and favor from out to in connections, when it does make perfect sense since it does have a different weight.

So I really challenge the notion where both are equally valid and to see it that way overlooks how this might step on your toes and focuses on a feature bloat goal.

Sometimes we don't need all the bells and whistles, and I think it's perfectly valid for me to ask for a way that I can disable some of these...

[timothyschoen]

My car can ride on reverse, but I have 5 gears to run forward and do that most of the time. If I were to pick one direction, I'd choose going forward only...

Fortunately, we don't have to pick a direction, since you can just do both. Would you rather have a car that cannot drive backwards at all? That's a bit what this request feels like to me. "You could accidentally put your car in reverse" is not an argument for not allowing cars to go in reverse.

Regarding adding options to configure patching: I'd rather keep this as limited as we can, though I will be adding a few (like pd-vanilla iolet spacing). There have been plenty of requests for making things more customisable, but adding a lot of these options negatively affects the maintainability of a project. Because some options will only be used by very few users (as I suspect this one would), which means that almost nobody is regularly testing it. I mean, pure-data also has even way less customization, and that's probably for a good reason.

I find it a ‘feature creep disease’ when you try to hard to make every possibility happen and don’t care about all the visual noise and information load.

But it's also feature creep disease when you make too many things configurable. And for stability, that's arguably worse!

wish there could be at least some flexibility here to acknowledge that some people might prefer this approach and might be very very happy with what Pd offers

I'm not telling anyone to stop using Pd! If you like what Pd has to offer, you can use Pd! I can acknowledge that people might prefer that, but my vision for plugdata is different than that of Pd. Which is why we end up making different choices.

I'm also assuming that there is a preference to mimic MAX, not only from this, but other things not worth mentioning now to prove my point. Well, actually you also put this yourself, by praising and favoring someone coming from MAX.

users coming from Max or other patching environments.

I like how coming from Pure Data and all of its forks so far is simply completely disregarded and not mentioned as one possible "patching environments", I find this really interesting and problematic to imply Pd Vanilla, Pd Extended, Purr Data, Pd-L2ork and Pd-ceammc aren't worth noting as patching environments :)

It’s very very weird that such a feedback isn’t considered and what prevails and settles the discussion is favoring the expectations of people coming from MAX…

Not at all, and you're assuming a lot of things that I have never said. We're designing a patching environment purely based on the things we like. Alex and I share a lot of the same vision in this regard. We're not pandering to Max users, but if we like what Max does, we can get inspired by it. Same for all Pd derivatives, if we like what it does, we take it. Like how I recently added Pd's autopatching. We design it the way we like it, by using examples and principles that we agree with.

aren't worth noting as patching environments

I never said any of that! Do you have the idea that I dislike pd-vanilla or other Pd forks? That's not the case at all! I'm also not trying to "replace" Pd, if you like what Pd has to offer more, you don't need to use plugdata, and that's okay. But I would appreciate it if you didn't strawman me, for quality of this discussion.

as it feels like it’s very hostile to my profile and there is no real intent to listen and open it up so I feel more comfortable here :)

I'm sorry, what? Alex has been busy marking and organising all our pd-vanilla compatibilty issues, so we can work on them. I've been implementing autopatching, fixing atom boxes compatibility. We've been doing nothing but listening and even worked on things you want. But it feels like you are expecting us to agree with everything you propose, and I think that is an unrealistic expectation.

[porres]

"You could accidentally put your car in reverse" is not an argument for not allowing cars to go in reverse.

That is not really my point, but the fact that one direction has a different weight. It's not like I can drive backwards the same way as forward. It's not that easy to set the car to go on reverse as well (they kinda solved that), but the reality is that these are equally valid and is getting in the way.

And to try and keep the focus on the issue, I'd hope we can discuss my points, that this and other features might get in the way and disturb the patching workflow and experience. I gave examples. Also, I know I'm not the only one struggling. I might be the only one trying to bring this up and in a bad way though :(

pure-data also has even way less customization, and that's probably for a good reason.

I don't think this compares well, cause it's very simple and not bloated, so not there's not much for configuration. But within the few features it does provide, it does offer ways to configure, like disabling autopatching.

But it's also feature creep disease when you make too many things configurable.

I see it as a consequence in this context. PlugData offers a huge amount of configurations because it has many features. And the same with Max, which has even more stuff.

you're assuming a lot of things that I have never said.

sorry, this wasn't aimed at you, but I did base these assumptions on feedbacks from others

I never said any of that! Do you have the idea that I dislike pd-vanilla or other Pd forks?

This comment was a critique on the way things were phrased in this topic. Mentioning that what I asked for is not usual in "patching environments" and in between the lines that disregards Pd and all the other forks and does favor and praise for MAX. I don't actually believe this was Alex's actual intention and belief, but it was unfortunate and somehow it did slip that there is a mentality that subjugates the experience and expectations from Pd users as well as not considering issues as a possibility or being valid.

Sorry but I feel this is the elephant in the room, via different kinds of feedback from the forum and stuff, so I'm bringing it up!

There is a lot of drama, sensitivity and warfare if I bring up insatisfaction with the way things are and say I miss some of the experience that I'm used to. I'm mentioning things that impact my workflow negatively and make me uncomfortable and what I'm getting is things like "well, we target a different audience", and something like "we really want to make MAX users comfortable", not to mention harsh offenses that questions my mental health (not from you of course)

if you like what Pd has to offer more, you don't need to use plugdata

I know, and I haven't been using it unfortunately because of this and other issues. I'd like to feel more comfortable and use it more though, hence the requests.

I'm sorry, what?

I'm sorry, but this issue was simply closed and rejected without any actual discussion

and the way it was rejected didn't address the actual points I made

It did say "having inlets visible, but not draggable would be confusing to new users to patching", but I never even asked that it would have to be the case. I merely asked for a way to configure it, not make it the default.

The 2nd request wasn't even addressed at all.

So sorry, but it did feel like a blunt silencing of the issue.

Closing an issue without working it out is a very drastic measure, and in here users cannot even reopen them if they object! That's not how it's in my repo or Pd's.

[porres]

In order to focus back on the actual issue, here's a video that illustrates what i described

https://github.com/plugdata-team/plugdata/assets/5360142/b148ab15-2e65-41db-bbf1-0177fc0f3e04

So, this is more proeminent when you have patches that are very tightly packed, i didn't record that but I think it's easy to visualize that if you have two boxes close together and you wanna go for an outlet you may easily get the inlet to drag a cord from instead. Nonetheless, I end up doing this a lot when placing an object via a shortcut and then moving it a bit to better align it to the patch, but clicking on where plugdata placed the object doesn't drag the object because that's the inlet area and I get a cord instead. And this is not the only other case either, it's just easy to hit the inlet instead of an outlet if you quickly try and click on an object and drag it, because the area in between an outlet and an inlet is very very tight and narrow, do you need to hit it in the bulls eye.

Let's consider the above video as one just trying to click and drag the object but got an undesired cord connection from the inlet instead... and now let's move on to the 2nd issue, on how it's so much easy to make a connection that you can easily make one that you never intended. In the above examples the boxes are rather separated in a somewhat reasonable manner, as I do tend to pack boxes much tighter, but see how it leave me no room at all to simply release the click so the undesired connection gets lost in the air... no, it'll find somewhere to patch it...

So now I have to rely on yet another command, a "control + z", to remediate...

The third issue I'm bringing up also adds more complexity, as there are too many draggable areas for resizing, which narrows things even more and makes it harder to hit the exact spot where no connection or resizing is possible.

---

I see the concern about maintainability and offering more options. Well, it's your call, but saying that it'll be harder to see if that is functioning well makes only sense if nobody or virtually nobody uses the feature... so no one is testing it to see if it works...

If no one is using it and then it's buggy, and then no one reports it... well, great, don't fix it I guess. But a single power user like me will definitely guarantee you that tests will be made.

Or better yet, but being comfortable and using this, I will definitely test many many other things in this project, and will definitely report it and help out...

You can see I have no problems in opening issues and bugs :)

[timothyschoen]

OK: how about we bundle this and pd-vanilla inlet/outlet spacing under an option called "vanilla iolet behaviour" or something? That way we keep the number of options a bit more limited, and you can get full pd-vanilla behaviour if you want. Sounds good?

[timothyschoen]

very very tight and narrow, do you need to hit it in the bulls eye.

I think the key here, if you want to get more comfortable with plugdata, is to get used to pinch zooming. This is very comfortable (esp on a macbook) and I think if you zoomed in by 10 to 20%, you won't have this issue anymore. We'll add the options, but maybe this will help you with other things too. You mentioned earlier needing surgical precision, but that's easily resolved when you can make everything as large as you want!

[alcomposer]

@timothyschoen @porres how about we leave this conversation here?

Let's move to the new issue that is open. :-)

[porres]

how about we bundle this and pd-vanilla inlet/outlet spacing under an option called "vanilla iolet behaviour" or something? That way we keep the number of options a bit more limited, and you can get full pd-vanilla behaviour if you want. Sounds good?

Good for me! If too many configurable options is a concern, this is a good solution at least for me as I'd choose both anyway :)

[porres]

I think the key here, if you want to get more comfortable with plugdata, is to get used to pinch zooming. This is very comfortable (esp on a macbook)

truth is, I do zoom all the time with pd vanilla on macOS cause I can't live without the system's built in zooming function for whatever. I am zooming crhome right now to respond to this comment as my eyes are not that good.

I zoom so I can read help patches and also write them.

So I know about zooming :) it's just that sometimes I don't to have to zoom ;)

[porres]

Let's move to the new issue that is open. :-)

ok, thanks!

and sorry for being too verbose