Right, it's a general principle of Pd/Max-style programming:
- It's always safe to send a value back to a prior object's COLD inlet.
- If you're sending back to a prior object's HOT inlet, this is potentially dangerous. You must make sure there's an exit condition (some branch that does not feed the value back).
IMO "send back to hot" is probably a mistake, unless a [delay] is involved.
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.
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 --
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.)
- 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.
- 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.
Just to say last ceammc lib 0.9.4 have random.i, random.f, random.atom (random atom from specified list with weights) etc...
Indeed, this looks fantastic. Wouldn't have found it on my own.
Btw I had a student on Monday complain precisely "in SC I can just ask for a random number in a range, but in Pd I have to do math" and I did point to ceammc at that point. Still, it suggests that many programming environments have become more articulate in their access to rngs while vanilla Pd hasn't. It's like, integer rands were good enough for your grandparents so they should be good enough for you "back in my day, we had to..." (though it was kinda cool when Pd's always-quantized random numbers led me to stumble across a really crazy artefact when summing sine waves -- wouldn't have found that if I'd been using random floats ).
I have a moving average abstraction here: https://github.com/jamshark70/hjh-abs/blob/master/moving-avg.pd
Also moving median (requires cyclone as Pd vanilla doesn't have a median function that I could find): https://github.com/jamshark70/hjh-abs/blob/master/moving-median.pd
The moving average is probably faster.
"if the pixel in the key source lies within the range, then it is replaced by the corresponding pixel in the other stream"
"Inlet 1: direction 0|1 : which stream is the key-source (0=left stream;
1 = right stream)"
So -- "direction 0" should mean that matching colors in the left image would be replaced by pixels from the right image (because 0 means that the left stream is the key source and, per above, pixels from the key source within range are replaced).
So I've got an image of a bad CGI dinosaur with a solid green background = 0.129 0.945 0 (RGB) -- putting this into the left inlet of chromakey. This is the one whose pixels should be replaced, so... direction 0, right?
But when I set "value 0.129 0.875 0" and "range 0.15 0.15 0.15" to match the green background, then I get the background coming through solid, and a transparent hole in the middle where the dinosaur is.
If I set "direction 1" then I get the foreground dinosaur, and the green gets replaced.
So it seems that the "direction" message is explained backward? Or is that part correct, and the explanation of "key source" is wrong?
Or perhaps there is some other way to interpret those statements...?
Update: Apparently this is standard in 3D graphics frameworks -- https://www.khronos.org/opengl/wiki/Transparency_Sorting -- "In order to achieve translucency, all opaque objects must be drawn before drawing any translucent ones."
In Pd, this means [t a a] with varying degrees of translucency underneath may not work (unless translucency is always constant), because, if two shapes switch translucency priority, there's no way in [t a a...] to change their order.
So I file it under "unanticipated fine print," with a solution.