@whale-av It's not 1999 and we don't party like that anymore. The line not falling on a pixel should not matter, it should adjust the staggering and grouping of the pixels to compensate, I have not seen aliasing effects like that since the early 90s. If it were a resolution issue one would see aliasing effects elsewhere, not just in pd, which the affected users may be seeing, no one has mentioned/asked that yet. I ran this computer through its supported resolutions to see if I could get aliasing, no luck, everything drew proper.

P.S. I have no idea what that image is supposed to reference, but it gave me a good chuckle.

@ddw_music @ingox what do you get if you run lsof -p $(pidof Xorg) | grep /dev/dri in a terminal?

@oid i get:

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
Xorg    757 root  mem       CHR              226,0               12360 /dev/dri/card0
Xorg    757 root   14u      CHR              226,0      0t0      12360 /dev/dri/card0
Xorg    757 root   15u      CHR              226,0      0t0      12360 /dev/dri/card0

I have no idea what this is.

@oid:

all my wires come out as shown in the screen grab of my redraw of Ingox's patch, nice crisp single pixel lines.

and

I have not seen aliasing effects like that since the early 90s

We might be having a terminology problem here.

Graphics aliasing is: A line should ideally look like a diagonal, but instead it looks like stairsteps.

The "changing thickness" that you mentioned could be seen as one case of aliasing... but... your "nice crisp single pixel lines" are in fact aliased. You are seeing aliasing -- every day when you use Pd. (Edit: deleted a bit here, not helpful comment from me)

So, for fun:

(
u = UserView(nil, Rect(800, 200, 450, 300)).front;
u.background = Color.white;

u.drawFunc = { |view|
    var drawPort = { |x, y|
        3.do { |i|
            Pen.moveTo(Point(x, y + i))
            .lineTo(Point(x + 8, y + i))
        };
        Pen.stroke;
    };
    Pen
    .color_(Color.black)
    // integer pixels are "between" canvas pixels
    // and subject to anti-aliasing
    // by shifting the coordinates by a half pixel,
    // lines are drawn exactly on display pixels
    .translate(0.5, 0.5)
    .moveTo(106@29)
    .lineTo(130@29)
    .lineTo(135@34)
    .lineTo(135@49)
    .lineTo(106@49)
    .lineTo(106@29)
    .stroke;
    drawPort.(106, 29);
    drawPort.(106, 47);
    Pen.moveTo(117@142)
    .lineTo(157@142)
    .lineTo(157@162)
    .lineTo(117@162)
    .lineTo(117@142)
    .stroke;
    drawPort.(117, 142);
    drawPort.(117, 160);
    Pen.moveTo(109@49).lineTo(120@142).stroke;
};
u.refresh;
)

If you prefer the version on the left, that's fine. We can agree to disagree about the aesthetics. But I don't think there's any room to disagree with my assertion that the version on the left does not reflect the state-of-the-art in graphics rendering. It simply is out of date.

Would Pd benefit from a more modern graphical presentation? Yes. (Would it be a large investment of developer resources -- yeah, probably too large. So it won't happen. Doesn't mean that the current state of things is good exactly.)

@ddw_music @ingox what do you get if you run lsof -p $(pidof Xorg) | grep /dev/dri in a terminal?

I get nothing.

this is a driver issue or possibly your distro's TK

If it's a driver issue, that would be assuming that the processing chain goes something like "software requests a line to be drawn --> the request is passed along to the video driver --> video driver does (or doesn't do) anti-aliasing." I'm pretty sure that's not how it works -- especially considering that the above screenshot shows different rendering, but under the same video driver.

The distro's TK version:

$ tclsh
% info patchlevel
8.6.8

The absolute most recent seems to be 8.6.10. So I would doubt that there is a different Linux distribution where Tk's drawing is significantly improved.

So let's compare Tk's native drawing outside of Pd to Qt, borrowing a script from http://zetcode.com/gui/tcltktutorial/drawing/ :

That confirms one thing at least -- it's Tk's fault. The Tk one on the left is... like... it's 2020, why is a graphics toolkit drawing like this in 2020? Are they for real? (So, the Pd problem is that it's hitched itself to a badly out of date wagon. That might have been a good decision at the time, but Tk hasn't kept up with the modern world, and it's holding Pd back in that regard.)

hjh

@ddw_music Undoubtedly Tk is not calling os antialiasing for the os window drawing for line objects.
I still think some are comparing apples and oranges though.
Different screen resolutions, near vision ability, preference for clear jagged or smudged jagged, modern?.... all come into play.
Lines close to horizontal and vertical are the only ones that bother me personally. I spend a lot of time cleaning them up, and can be very annoyed when they go out of kilter opening a patch in another version of Pd.
I stick with my screen resolution point though.
My laptop (1440x900) obviously produces this...... aliasing.pd

and there are no intermediate pixels available.

Super Colider looks like it is using half-tone BLit stretching and although I don't think I would really like the smudging any better for such lines in Pd there is no other solution for antialiasing.
Render resolution cannot usefully surpass the pixel density unless for export.
I would expect that for some monitors there will be "gamer" card drivers that would do the same.

Except....
I would like a tool similar to the "Tidy up" edit tool....... a "Snap Cords" to align cords (not objects) horizontally and vertically when the cords are very nearly aligned already.
David.

@ingox it means you video card is actually being used by the system, /dev/drive/card0 is your video card. The standard test using lsmod or dmesg actually only checks to see if the kernel loaded the driver, does not actually tell you that it is being utilized. I have no idea where I was going with that, I think it was just 4AM logic, but I may have actually had a plan and just forgot it during sleep.

@ddw_music said:

We might be having a terminology problem here.

No, I was referring to the aliasing error shown in Ingox's screen grabs, the line changes thickness, it is not aliased properly. In my experience most people realize this given the context. With anti-aliasing you never have nice crisp single pixel lines, you have 3 or 4 pixel lines of two shades of grey depending on the angle, they are not crisp, just smooth.

If it's a driver issue

The aliasing error being a driver issue. Aliasing vs anti-aliasing is obviously a software issue.

The distro's TK version:

I meant implementation not version, the hour was late. A quick glance at the pd source, its config and the Makefile suggests there is nothing there that enables anti-aliasing for OSX, which strongly suggests that you just need to compile TK with anti-aliasing and you will have it (possibly after recompiling TK apps, did not bother to look into it to see how it works). Most likely every linux distro assumes that anyone choosing TK is doing so for speed over aesthetics, a fair assumption, so they package TK without aliasing. I did not give a thorough search of the source, just a few greps, read the readme and checked the configs help, but considering that there is not one mention of TK in the Makefile, I think it is a safe assumption. This is part of linux, distros have to consider being able to run on less than state of the art hardware.

@oid as I stated in my first comment in the thread, the reason for the disparity is the different system rendering libraries tk uses.
on osx it uses core graphics, which supports antialiasing (though I believe you can modify it at runtime with some tcl variable)
on windows it uses gdi, which does not support antialiasing and on linux it uses xlib, which also does not support antialiasing

there are no options in either pd or tk currently for enabling/disabling antialiasing. Tk renders how it will render no matter the compilation flags afaik. Antialiasing is always available on osx and always not available on the other platforms due to the nature of the system rendering primitives that tk calls

It is exactly the single pixel lines that I find objectionable.

The changing thickness seems to be an approach to the problem where the stairsteps would be of a different length, e.g.

*
 *
  *
   *
    **
      *
       *
        *
         **
           *

Frankly they both look gross to me. I think you're trying to say that the rendering in my screenshots is wrong and the above demonstration of a 1.2:1 pixel slant would be right -- but I dislike both of them.

I'm willing to consider that if I saw smoothed lines throughout Pd, I might feel like it's too much fuzz -- but I doubt it. When I tried Purr Data, my first thought was "ah, finally, lines that don't make my eyes hurt." (But then I had to abandon Purr Data because I need Gem for a class, and Gem isn't supported in Purr Data for Mac, so I couldn't use it in the school's Mac-based media classroom... so, back to vanilla.)

In a perfect world, I could choose smoothed lines and oid could choose single pixel lines, but...

seb-harmonik said:

on windows it uses gdi, which does not support antialiasing and on linux it uses xlib, which also does not support antialiasing

That's unfortunate. Kind of underscores the point about being out of date -- that will continue as long as the buck gets passed (Pd: "Line drawing is Tk's problem"; Tk: "Line drawing is xlib's problem" and xlib will have some reason not to catch up with modern line drawing). It's a shame that an important part of the computer music ecosystem get held back by dependencies that aren't catching up.

hjh

@seb-harmonik.ar I believe TK can also use XCB? No idea if that would make any difference or if it supports anti-aliasing. Thanks for pointing out your post which I seemed to have missed or forgotten.

@ddw_music Wayland and Mir will be out shortly and everything on it will likely be anti-aliased. Your distro may have them in the repositories, no idea if TK yet supports them or if it still just builds against Xlib/XCB.

Ultimately I do not care if the lines are anti-aliased or not, if I had the choice I would just accept the default.

@porres Ok I give up. Here are your smudgy lines.
It works in win7 and I don't (so far) like them.

Unfortunately it opens Pd patches and the console in a window that seems to be a fixed size on my system.
Working on it again when I have the time so please post if you solve that fixed size window problem, but it looks very much like an emulation window......
Don't blame me for any problems please.
There shouldn't be any lasting problems as it doesn't write to the registry.

Download the binary for your system here......... http://www.androwish.org/download/index.html
It contains TkPath which gives you what you want (amongst other things)..... GDI+ for windows, whatever it is for Linux.
I used "undroidwish builds from almost the same source tree" for my win64 system.... and that might not have been the best choice......?

Rename it wish86.exe (or whatever it should be for Linux) and dump it in the Pd/bin folder (AFTER MOVING THE ORIGINAL SOMEWHERE ELSE).
Open Pd.exe and Voila.

Shame about the window, but proof that it can be done in Tk and maybe for Linux TkPath could be compiled as an add-in?
David.

@ddw_music said:

That's unfortunate. Kind of underscores the point about being out of date -- that will continue as long as the buck gets passed (Pd: "Line drawing is Tk's problem"; Tk: "Line drawing is xlib's problem" and xlib will have some reason not to catch up with modern line drawing). It's a shame that an important part of the computer music ecosystem get held back by dependencies that aren't catching up.

personally I think it's tk's responsibility to update with an option for modern system libraries or implement something (or provide an option for compiling with a library like cairo or something.)
of course, as I stated above, there are already tk extensions like tkpath and the developers might just point to those as the preferred way to get modern looks.

@whale-av The window is resizable....... https://www.androwish.org/index.html/wiki?name=Beyond+AndroWish
I will update the above post above when I work out how to get the command line switch -sdlresizable into the open call from Pd..
David.

Ooooooohhhhh... very nice.

BTW in my SC mockup above, I'd found that drawing horizontal or vertical lines on an integer pixel actually places the line between the pixel -- so it doubles in width and turns grey. That is objectionable, but easily fixed by shifting coordinates internally by half a pixel.

Unfortunately undroidwish is not fully usable (seems to drop control-letters) but wow... it's so much better looking.

Ok I give up. Here are your smudgy lines.

smacks forehead

hjh

Howdy all,

I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.

I'm just writing for myself and don't speak for Miller or anyone else.

Mac looks good

The antialiasing on macOS is provided by the system and utilized by Tk. It's essentially "free" and you can enable or disable it on the canvas. This is by design as I believe Apple pushed antialiasing at the system level starting with Mac OS X 1.

There are even some platform-specific settings to control the underlying CoreGraphics settings which I think Hans tried but had issues with: https://github.com/pure-data/pure-data/blob/master/tcl/apple_events.tcl#L16. As I recall, I actually disabled the font antialiasing as people complained that the canvas fonts on mac were "too fuzzy" while Linux was "nice and crisp."

In addition, the last few versions of Pd have had support for "Retina" high resolution displays enabled and the macOS compositor does a nice job of handling the point to pixel scaling for you, for free, in the background. Again, Tk simply uses the system for this and you can enable/disable via various app bundle plist settings and/or app defaults keys.

This is why the macOS screenshots look so good: antialiasing is on and it's likely the rendering is at double the resolution of the Linux screenshot.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.

Nah. Apple simply invested in antialiasing via its accelerated compositor when OS X was released. I doubt there are patents or licensing on common antialiasing algorithms which go back to the 60s or even earlier.

tkpath exists, why not use it?

Last I checked, tkpath is long dead. Sure, it has a website and screenshots (uhh Mac OS X 10.2 anyone?) but the latest (and only?) Sourceforge download is dated 2005. I do see a mirror repo on Github but it is archived and the last commit was 5 years ago.

And I did check on this, in fact I spent about a day (unpaid) seeing if I could update the tkpath mac implementation to move away from the ATSU (Apple Type Support) APIs which were not available in 64 bit. In the end, I ran out of energy and stopped as it would be too much work, too many details, and likely to not be maintained reliably by probably anyone.

It makes sense to help out a thriving project but much harder to justify propping something up that is barely active beyond "it still works" on a couple of platforms.

Why aren't the fonts all the same yet?!

I also despise how linux/windows has 'bold' for default

I honestly don't really care about this... but I resisted because I know so many people do and are used to it already. We could clearly and easily make the change but then we have to deal with all the pushback. If you went to the Pd list and got an overwhelming consensus and Miller was fine with it, then ok, that would make sense. As it was, "I think it should be this way because it doesn't make sense to me" was not enough of a carrot for me to personally make and support the change.

Maybe my problem is that I feel a responsibility for making what seems like a quick and easy change to others?

And this view is after having put an in ordinate amount of time just getting (almost) the same font on all platforms, including writing and debugging a custom C Tcl extension just to load arbitrary TTF files on Windows.

Why don't we add abz, 123 to Pd? xyzzy already has it?!

What I've learned is that it's much easier to write new code than it is to maintain it. This is especially true for cross platform projects where you have to figure out platform intricacies and edge cases even when mediated by a common interface like Tk. It's true for any non-native wrapper like QT, WXWidgets, web browsers, etc.

Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot. That being said, I just spent about 2 hours fixing the help browser for mac after trying Miller's latest 0.52-0test2 build. The end result is 4 lines of code.

For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.

Yes, this is correct, but first we have to keep the damn thing working at all. I think most people agree with you, including me when I was teaching with Pd.

I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.

I read this as "community" = "active developers." It's true, some people tend to poo poo the same reoccurring ideas but this is largely out of years of hearing discussions and decisions and treatises on the list or the forum or facebook or whatever but nothing more. In the end, code talks, even better, a working technical implementation that is honed with input from people who will most likely end up maintaining it, without probably understanding it completely at first.

This was very hard back on Sourceforge as people had to submit patches(!) to the bug tracker. Thanks to moving development to Github and the improvement of tools and community, I'm happy to see the new engagement over the last 5-10 years. This was one of the pushes for me to help overhaul the build system to make it possible and easy for people to build Pd itself, then they are much more likely to help contribute as opposed to waiting for binary builds and unleashing an unmanageable flood of bug reports and feature requests on the mailing list.

I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk).

A couple of points:

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years, especially since Miller's stated goal was for 50 year project support, ie. pieces composed in the late 90s should work in 2040. This is one reason why we don't just "switch over to QT or Juce so the lines can look like Max." At this point, Pd is aesthetically more Max than Max, at least judging by looking at the original Ircam Max documentation in an archive closet at work.

A way forward: libpd?

I my view, the best way forward is to build upon Jonathan Wilke's work in Purr Data for abstracting the GUI communication. He essentially replaced the raw Tcl commands with abstracted drawing commands such as "draw rectangle here of this color and thickness" or "open this window and put it here."

For those that don't know, "Pd" is actually two processes, similar to SuperCollider, where the "core" manages the audio, patch dsp/msg graph, and most of the canvas interaction event handling (mouse, key). The GUI is a separate process which communicates with the core over a localhost loopback networking connection. The GUI is basically just opening windows, showing settings, and forwarding interaction events to the core. When you open the audio preferences dialog, the core sends the current settings to the GUI, the GUI then sends everything back to the core after you make your changes and close the dialog. The same for working on a patch canvas: your mouse and key events are forwarded to the core, then drawing commands are sent back like "draw object outline here, draw osc~ text here inside. etc."

So basically, the core has almost all of the GUI's logic while the GUI just does the chrome like scroll bars and windows. This means it could be trivial to port the GUI to other toolkits or frameworks as compared to rewriting an overly interconnected monolithic application (trust me, I know...).

Basically, if we take Jonathan's approach, I feel adding a GUI communication abstraction layer to libpd would allow for making custom GUIs much easier. You basically just have to respond to the drawing and windowing commands and forward the input events.

Ideally, then each fork could use the same Pd core internally and implement their own GUIs or platform specific versions such as a pure Cocoa macOS Pd. There is some other re-organization that would be needed in the C core, but we've already ported a number of improvements from extended and Pd-L2ork, so it is indeed possible.

Also note: the libpd C sources are now part of the pure-data repo as of a couple months ago...

Discouraging Initiative?!

But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.

IMO Pd is healthier now than it has been as long as I've know it (2006). We have so many updates and improvements over every release the last few years, with many contributions by people in this thread. Thank you! THAT is how we make the project sustainable and work toward finding solutions for deep issues and aesthetic issues and usage issues and all of that.

We've managed to integrate a great many changes from Pd-Extended into vanilla and open up/decentralize the externals and in a collaborative manner. For this I am also grateful when I install an external for a project.

At this point, I encourage more people to pitch in. If you work at a university or institution, consider sponsoring some student work on specific issues which volunteering developers could help supervise, organize a Pd conference or developer meetup (this are super useful!), or consider some sort of paid residency or focused project for artists using Pd. A good amount of my own work on Pd and libpd has been sponsored in many of these ways and has helped encourage me to continue.

This is likely to be more positive toward the community as a whole than banging back and forth on the list or the forum. Besides, I'd rather see cool projects made with Pd than keep talking about working on Pd.

That being said, I know everyone here wants to see the project continue and improve and it will. We are still largely opening up the development and figuring how to support/maintain it. As with any such project, this is an ongoing process.

Out

Ok, that was long and rambly and it's way past my bed time.

Good night all.

Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot.

A reason to dropped them is not only for cosmetic, but the worry for their lifetime. I'm a bit afraid about their maintenance and/or avaibility in the next decades. Anyway thanks for your work on Pure Data!

@Nicolas-Danet Don't interpret "I'm happy" as "I'm happy and never want it to change."

I've looked into Jonathon's GUI communication interface and there is not too much to change within the sources, really. Just replace most of the sys_gui calls and add gui drawing details to the GUI itself. He has his approach documented in the Purr Data readme. This is after I had already personally gone through all of the GUI code to integrate the Pd-extended sizing and improve issues with IEM GUI draw order. In fact, a lot of the IEM GUI sys_gui calls are redundant and could be better refactored.

For example, the Purr Data g_bang.c sources do not send any custom tcl strings, just "update the bang with this color" and the drawing is done on the GUI side: https://git.purrdata.net/jwilkes/purr-data/-/blob/master/pd/src/g_bang.c#L35

I hope you are not already writing your own custom implementations of the built-in GUIS for your project. I would suggest we work together into porting Jonathon's gui_vmess approach first. I am also in the same boat having written custom implementations in CoreGraphics for iOS but I'd love to replace those with more built=in handling, ie. just draw/update the bang on the Obj-C side without the placement & interaction code.

UPDATE: I do not mean to "toot my own horn" in these responses. By stating some of the work I've done personally, I meant to show that effort was made on some of these points and they were not dismissed out of hand. Also, having spent some time with the code itself, I want to convey that some approaches are definitely possible and the issue is less technical (can we do this) and more organizational (what is the best way to do it and make it sustainable / future proof).

@danomatika said:

I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.

Thanks for the long and detailed post. A lot of the quotes that you're responding to came from me, so I wanted to start off by saying I really appreciate your taking the time to explain your perspective.

What you're replying to is about a year old. Some of my opinions (such as, the GUI frightening away new users) have softened a lot in that time.

I still think Tcl/Tk has failed to keep up with modern standards, and I have my doubts that it will ever catch up. So, I still think that Pd hampers its own progress by hitching itself to the Tcl/Tk wagon. The last couple of posts here are encouraging.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

Developer vs user perspective. The user sees clean diagonals on Mac, and jagged diagonals on Linux or Windows, and I think it's perfectly legitimate for the user not really to care that it's the OS rather than the drawing engine that makes it so in Mac. (It's correct, of course, to point out that the diagonals on a retina display will look smoother than antialiased diagonals without retina.)

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

I did try Purr Data, but abandoned it because (at the time, two years ago), Purr Data on Mac didn't support Gem and there were no concrete plans to address that. This might have changed in the last couple of years (has it? -- I've looked at https://agraef.github.io/purr-data/ and https://github.com/agraef/purr-data but it seems not quite straightforward to determine whether Gem+Mac has been added or not).

Tracking vanilla releases was the other issue. A couple of years ago, [soundfiler] in Purr Data was older and didn't provide the full set of sound file stats. That issue had been logged and I'm sure it's been updated since then. "Tracking" seemed to be manual, case-by-case.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years...

Well, I mean, OK up to a point. There are things like the Tcl/Tk open/save file dialog, which is truly abhorrent in Linux.

Some puzzling decisions here and there -- for example, when you use the mouse to drag an object to another location, why does it then switch to edit the text in the object box? To me, this is a disruptive workflow -- you're moving an object, not editing the object, but suddenly (without warning) you're forcibly switched into editing the object, and it takes a clumsy action of clicking outside the object and dragging the mouse into the object to get back to positioning mode. I feel so strongly about it that I even put in a PR to change that behavior (https://github.com/pure-data/pure-data/pull/922), which has been open for a year and a half without being either merged or rejected (only argued against initially, and then stalled). "Still working for 20 years" but you could also say, still clunky for 20 years, with inertia when somebody does actually try to fix something.

WRT to the rest, any architectural improvements (e.g. drawing abstractions so that the Pd core isn't so tightly coupled to Tcl/Tk) that make it more feasible to move forward are great, would love to see it.

hjh

@ddw_music said:

I still think Tcl/Tk has failed to keep up with modern standards, and I have my doubts that it will ever catch up. So, I still think that Pd hampers its own progress by hitching itself to the Tcl/Tk wagon.

I think most people agree with you, myself included. Tk is clunky but it's in the current code base and has been kept so far since it works, although admittedly barely in many cases.

The last couple of posts here are encouraging.

I know development is slow, but it's really working against inertia. Momentum has been growing the last years and that's mostly due to more effective collaboration to tackle some of these issues. I think finding a sustainable approach to the GUI is one of the largest ones, so is taking a while to grow.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

Developer vs user perspective. The user sees clean diagonals on Mac, and jagged diagonals on Linux or Windows, and I think it's perfectly legitimate for the user not really to care that it's the OS rather than the drawing engine that makes it so in Mac. (It's correct, of course, to point out that the diagonals on a retina display will look smoother than antialiased diagonals without retina.)

Yup, you are totally right. I didn't mean to imply the Linux screenshot looked good since "that's the way it is" just more that it looks so much better on macOS since the screenshot is likely double the resolution as well.

I started using Pd on Windows circa 2006 then jumped to Linux for many years, then to macOS. My feeling was that Pd worked best on Linux but a lot of that has caught up as the underlying systems have developed but in some ways the Linux desktop has not (for many reasons, good and bad).

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

I did try Purr Data, but abandoned it because (at the time, two years ago), Purr Data on Mac didn't support Gem and there were no concrete plans to address that. This might have changed in the last couple of years (has it? -- I've looked at https://agraef.github.io/purr-data/ and https://github.com/agraef/purr-data but it seems not quite straightforward to determine whether Gem+Mac has been added or not).

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.

I'm happy to download the deken GEM package because I know the IEM people have done all the craziness to build it (it's a small nightmare of autotools/makefiles due to the amount of plugins and configuration options). I am also very happy to not have to build it and provide it to other users but in exchange we ask people to do that extra step and use deken. I recognize that the whole usage of [declare] is still not as easy or straightforward for many beginners. There are some thoughts of improving it and feedback for people in the teaching environment has also pushed certain solutions (ie. Pd Documents folder, etc).

Tracking vanilla releases was the other issue. A couple of years ago, [soundfiler] in Purr Data was older and didn't provide the full set of sound file stats. That issue had been logged and I'm sure it's been updated since then. "Tracking" seemed to be manual, case-by-case.

By "tracking" I am referring to a fork following the new developments in Pd-vanilla and integrating the changes. This becomes harder if/when the forks deviate with internal changes to the source code, so merging some changes then has to be done "by hand" which slows things down and is one reason why a fork may release a new version but be perhaps 1 or two versions behind Pd vanilla's internal objects, ie. new [soundfiler] right outlet, [clone] object, new [file] object, etc.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years...

Well, I mean, OK up to a point. There are things like the Tcl/Tk open/save file dialog, which is truly abhorrent in Linux.

Hah yeah, I totally understand. My first contribution to Pd(-extended) was to find out how to disable showing hidden files in the open/save panels on Linux. You would open a dialog, it defaulted to $HOME, then you had to wade through 100 dot folders. Terrible! Who did this and why? Well it wasn't on purpose, it was just the default setting for panels on Tk, and I added a little but of Tcl to turn it off and show a "Show hidden files/folders" button below.

OTOH I have a colleague at work who's internal toolkit still uses Motif. Why? Well it still works and he's the only user so he's ok with it. I'd say that Tk also still uses Motif... but there are many users and they have much different expectations. ;P

Some puzzling decisions here and there -- for example, when you use the mouse to drag an object to another location, why does it then switch to edit the text in the object box? To me, this is a disruptive workflow -- you're moving an object, not editing the object, but suddenly (without warning) you're forcibly switched into editing the object, and it takes a clumsy action of clicking outside the object and dragging the mouse into the object to get back to positioning mode. I feel so strongly about it that I even put in a PR to change that behavior (https://github.com/pure-data/pure-data/pull/922), which has been open for a year and a half without being either merged or rejected (only argued against initially, and then stalled).

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.

"Still working for 20 years" but you could also say, still clunky for 20 years, with inertia when somebody does actually try to fix something.

Another approach would be to try to bring improvements to Tcl/Tk itself but the dev community is a little opaque, more so than Pd. However I admit to not having put a ton of time into it, other than flagging our custom patches to the TK macOS guy on Github.

WRT to the rest, any architectural improvements (e.g. drawing abstractions so that the Pd core isn't so tightly coupled to Tcl/Tk) that make it more feasible to move forward are great, would love to see it.

As would I... we are preparing for a major exhibition opening in December, but I will have some time off after and I may take a stab at a technical demo for this (among other things) then pull in some other perspectives / testers. It has been an itch I have wanted to scratch since, at least Pd Con 2016 in NYC.

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