• oid

    @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.

    posted in technical issues read more
  • oid

    @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.

    posted in technical issues read more
  • oid

    @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.

    posted in technical issues read more
  • oid

    @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?

    posted in technical issues read more
  • oid

    @whale-av Good catch, missed that in my quick hack.

    posted in technical issues read more
  • oid

    @ingox Apple has gotten fairly aggravating regarding all this in recent years, part of why I gave them up about a decade ago. I still have to deal with them fairly often since my parents use Apple and I am the one that they call everytime something goes wrong. One of the really irritating things is OSX can not mount a hard drive with even a minor issue and a key piece of their HFS+ spec is proprietary, the open source HFS+ spec lacks that so the open source tools can not generally fix even minor filesystem or journal problems on an HFS+ partition. Thankfully linux can almost always mount the drive and copy most, if not all of the data off, reformat and all is well, but it is a headache. Still less of a headache than getting my parents to use linux.

    @ddw_music said:

    That issue is not caused by the screen grabber. It's the normal appearance of Pd for ages. See the 2nd "Modulation index" --> [*~]. (This is a png -- there are no jpg compression artifacts. This is how it really looks on my screen, in the Pd window.)

    Ingox and I already confirmed that, this is a driver issue or possibly your distro's TK, if you are running linux on an apple machine, I would bet it is driver, I have never come across this issue in any linux, all my wires come out as shown in the screen grab of my redraw of Ingox's patch, nice crisp single pixel lines. This is most certainly not an issue with PureData.

    posted in technical issues read more
  • oid

    @ingox No matter how pretty you make your patches, I am still going to reorganize them.

    Wonder if this is the reason OSX has the anti-aliasing, perhaps their video cards and HD screens have an aliasing issues with such things as simple 1 pixel lines. 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.

    posted in technical issues read more
  • oid

    @ddw_music said:

    IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac. Zooming way way in, as your snap from slackware does, also renders the comparison unfair, in the other direction.

    I am not trying to make a fair comparison, just make yours more fair, you happened to select images from my thread and tagged me, so I had all those patches at hand. I personally hate anti-aliased single pixel lines in most situations, I will take a nice high contrast single pixels line almost every time. Readability is more a function of patch layout. Here is Ingox's patch reorganized from when I was trying to make sense of it, free of the weird artifacts which I assumed were caused by a post screen grab resize, but could have been caused by the screen grabber itself. Lines should not be changing thickness like that, most noticed on the line between [moses] and the number box, they should be 1 pixel wide but it alternates between 1 and 2 pixels in width,
    mc.png

    I love that pd still looks the same as it did when I first used it something like two decades ago.

    posted in technical issues read more
  • oid

    @ddw_music said:

    it seems fairly evident to me that the cleaner lines in Mac are easier to read. I don't see any way in which the Linux screenshot is preferable

    You are comparing a patch with many crossing wires with one with no crossing wires, straight forward logic and zoomed in, you literally picked the hardest to read patch and the easiest to read in that thread. Also, the linux one looks resized which does not help. Here is Il pleut's patch as I redrew it and zoomed in for a fair comparison. This is on slackware, might not look as smooth, but in no way harder to read.
    Ilpleut.png

    posted in technical issues read more
  • oid

    @ingox I meant how it is combined with the conditional test and [pack], kind of like a sort in place.

    @Il-pleut I like that one with [v], gets me thinking.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!