I suppose it's something to do with tcl/tk, but what?

cheers

As a newcomer to Pure Data and the community, it is heartening to see users and developers coming together to figure out how to improve the state of the art. I can understand and appreciate both the perspective of experienced users who instinctively work around and grow accustomed to existing behaviors, and new users that encounter... unconventional behaviors and see them as warts that detract from the overall user experience.

Within a few days of starting to use PD, I had created a text file called wtf_pd.txt with 17 annoyances that immediately jumped out at me in terms of UX. I've now figured out how to work around most of them, but I would very much like to address these problems, hopefully by getting accustomed with the coding standards of the project, submitting some PRs, and getting buy in from the development team. A perfect example being the fact that I can't resize the graph-on-parent canvas size by clicking and dragging, but have to enter in values manually in the properties dialog. Feels like editing HTML/CSS in the early 2000s .

At the end of the day, I think what we need to do is continue the discussion and work towards fixing these little papercuts over time. While individually they may be small, collectively they have a significant impact on the overall usability of the program. I do recognize, this being an open source project with finite resources, that these types of fixes rightfully take a back seat to stability and more severe bug fixes. But having discussions like these at least allows perspectives of new users to be heard, and eventually (hopefully) addressed as development cycles become available.

I have so much enthusiasm for the future of PD because it's opened up a whole new paradigm for me as an artist and musician. It is my belief that there are many, many other artists out there who would come flocking to Pure Data if they recognized what it was capable of.

My goal is to help bring PD to a wider audience by continuing to put myself in the shoes of new users, and to try my hand at contributing fixes wherever possible.

@danomatika said:

That's a result of many of the forks adopting the "kitchen sink" monolithic distribution model inherited from Pd-extended. The user gets the environment and many external libraries all together in one download, but the developers have to integrate changes from upstream themselves and build for the various platforms. It's less overheard for the user but more for the developers, which is why integrating a frankly large and complicated external like GEM is harder.

Fair enough -- but, no GEM on Mac, I can't use it in class. And I couldn't use it at home either, because (a couple of years ago) it seemed that Purr Data had added something(?) to the Pd file format so that Purr Data patches could not open reliably in Pd-vanilla. It didn't take too long to realize that I have to pick one or the other.

I'm downloading Purr Data to try again. It's been probably 2 years now.

I'm happy to download the deken GEM package.... I recognize that the whole usage of [declare] is still not as easy or straightforward for many beginners.

I teach my students not to add a bunch of paths/libs in Preferences, and always to use [declare]

Ah yes, I forgot about this one. It wasn't rejected, just came at a time when there were lots of other things shouting much louder, ie. if this isn't fixed Pd is broken on $PLATFORM. I would say that, personally, your initial posting style turned me off but I recognize where the frustration came from. I also appreciate making the point AND providing a solution, so the ball is in our court for sure. I will take a look at this soon and try it out.

Yeah... the tone. I've made more peace with the tool and hope that my tone has softened somewhat. I think at the time, I had observed that the user forum (here) tended to respond to criticism of the interface UX more or less along the lines of a/ we just get used to it (hm, no, if the tool is clumsy, we should improve the tool) or b/ we like it this way (aka don't mess with existing users' muscle memory) -- which is fine if the behavior is more or less standard, but the behavior in question is not. And in fact, the first comment on the PR was to question whether my assertions about the right behavior were correct at all.

So... while I do understand that the community would get tired of people complaining without fixing things, there is a danger in that of appearing to circle the wagons and reject criticism out of hand. (I think some comments in this thread raised that risk as well -- some members' a-priori rejection of antialiasing struck me as a quite startling form of resistance to progress.)

Perhaps the true test of a UI is not how you feel about it when you're relaxed and have all the time in the world, but rather how you feel about it when you have to get something done quickly, under time pressure. Pd works, but it doesn't always flow.

Thanks again for the detailed thoughts --
hjh

@ddw_music said:

Fair enough -- but, no GEM on Mac, I can't use it in class.

I tried pd-l2ork version based on purr data and a fresh version Gem is included. But, under macOsX, Gem is very unstable and tricky recently... sometimes you need to change the window manager in [gemwin] abstraction to fit the machine hardware etc... Strangely Gem in pd-l2ork doesn't work with my Windows, so it's really annoying for class. That's why I am using ofelia abstractions in class which are simple but works everywhere (Windows/OSX/Linux).

@link said:

Within a few days of starting to use PD, I had created a text file called wtf_pd.txt with 17 annoyances that immediately jumped out at me in terms of UX. I've now figured out how to work around most of them, but I would very much like to address these problems, hopefully by getting accustomed with the coding standards of the project, submitting some PRs, and getting buy in from the development team.

Do you have a Github account? You can open an issue and list all of your "paper cut" annoyances together.

Another approach is to bring the your list to the pd mailing list, then we can open an issue and bring the discussion there.

Last, if neither of those work, send me your wtf_pd.txt...

A perfect example being the fact that I can't resize the graph-on-parent canvas size by clicking and dragging, but have to enter in values manually in the properties dialog. Feels like editing HTML/CSS in the early 2000s .

Yup. Resizing to the object boxes was only added a few years ago but it would be great to have the same for GOPs.

@ddw_music Your single select drag and resize behavior bug fix is merged. Thanks!

UPDATE: A note from Miller on the pd-list:

Meanwhile merging the no-select-text PR - I meant to do that earlier but somehow missed it.

@danomatika Yes, I have a github account and I am planning on opening several issues. My plan is to let my initial impressions soak for a bit before I submit the bug reports; I want to make sure I'm touching on the most pressing issues and that I'm not missing anything obvious first. Thank you for the affirmation.

@60hz said:

I tried pd-l2ork version based on purr data and a fresh version Gem is included. But, under macOsX, Gem is very unstable and tricky recently...

OK, maybe I'll check a more recent Mac version.

I did have to advise one student to change [gemwin].

That's why I am using ofelia abstractions in class which are simple but works everywhere (Windows/OSX/Linux).

Yes, I remember those. They are truly impressive!

Unfortunately, I had to give up on them because of the lack of pix_ filters. I had started on an [of.shader] abstraction -- and actually got some basic shaders to run successfully! -- but something in my modifications to support this ended up breaking the behavior of multiple drawing chains. That is, I saw buggy behavior in my branch, but when I opened the same test patch using your branch, the bug disappeared. At that point, I had to decide that I don't have time to debug this (and, even if I did debug it, that would mean creating and maintaining a library of shaders, which... let's look in the dictionary under "time sink"...). So... back to GEM. I wasn't super thrilled about that (Ofelia seems more modern in a lot of ways) but teaching load and paperwork are increasing and I haven't been able to work on any of my own music for the last three months, no way I can carve out time for a huge project in an area I'm not even expert in.

@danomatika I did see the e-mail that the no-edit-on-move has been merged. Thanks!

Now, wait for Purr Data to catch up which is probably not a simple merge.

hjh

Just wanted to mention that I thought I saw that the edit-object-text-after-moving behavior just got removed.

Also this might be a GitHub or dev list topic but imo the main process shouldn't have anything to do with anything from the gui, including object/line geometry. The only thing it should be concerned with is audio and message processing, and the bare minimum info necessary to accomplish that.
So the main process would get info on which connections are made or removed, and what order the inlets and outlets are in but that would be it.

@seb-harmonik.ar Yeah, I noticed this too. Miller reverted it for some reason. I have pinged him on Github to ask for the reason. It seems like a settled issue, but sometimes we need his perspective as well...

@danomatika I remember someone giving some reason for reverting but still feels like a strange decision imo.
Maybe there should be some option/preference..
edit: ah, I see in the thread you make the same suggestion..

@danomatika said:

@seb-harmonik.ar Yeah, I noticed this too. Miller reverted it for some reason. I have pinged him on Github to ask for the reason.

From the comment in the source code, it seems that some users frequently do:

1. Ctrl-D to duplicate an object.
2. Mouse move.
3. Retype immediately into the object box.

... which, with the "no-edit" change, requires an extra click.

(My suspicion here is that "some users" = only Miller Puckette, but anyway.)

In github, I had commented two months ago that this really should be a user preference.

Now, granted... unpaid open source project, volunteer development, a couple of months inactivity on a non-critical issue is not at all surprising. So I wouldn't read anything into non-response.

It may be helpful for other forum users to comment on the github issue. Where it stands now, in github, is that there's MSP's view (which looks to me like "I want mouse-move-edit, and it's my project"), one grumpy user (myself) strongly opposing it, and a couple of votes in favor of a user preference. Because it takes developer time to add a user preference, it may require input from more users -- currently there's not enough demand for them to take the time, but if 20 users ask for the same change, then that's different.

hjh

@ddw_music said:

In github, I had commented two months ago that this really should be a user preference.

Actually it looks not crazy-difficult to implement that myself. I can't prioritize that project so it might take a little while, but I think I see the main code bits to take as models.

hjh

@ddw_music I might take a look at this and add the preference to pd-next too, if it isn't accepted. after all it's just an aesthetic/editing thing that doesn't affect the objects or patch format at all..
I think another option would be to have a keybinding to edit currently selected object(s?), since the users who want to edit object text after ctl-d need to use the keyboard at that point anyways