One of the things that's hard for her is typing. She's got fewer working fingers than most of us, but loves playing Minecraft and is learning to draw. Typing is really hard for her and leads to chronic tendonitis, which is really painful on top of the difficulty of typing with only a few fingers.

I'd started building a visual programming language a while ago intended for microcontrollers, but I'd like to get something running sooner than it will even have a working prototype. That development might take years and Pd already exists in solid shape.

Its interface, though, even in its Purr Data form, still makes a new user do reverse lookup to try to find out what functions exist in a separate document, rather than being able to choose ones that work, and requires them to repeatedly type in object names. I see that there have been a couple of attempts at making an autocomplete system, but I don't see any that currently work. Is there work being done on this currently?

Aside: I have an idea for a fun project with the kid of building a macro keyboard that would give them quick access to the existing list, but that's a huge workaround (even though it's probably a really fun project).

Yes, there's the autocompletion plug-in:
https://github.com/HenriAugusto/completion-plugin

And there's also a pd distribution used in the CEAMMC (Centre for Electroacoustic Music Moscow Conservatory) that comes with this feature as well as a toolbar and a big external library:
https://github.com/uliss/pure-data/releases

Even though it is still in beta, I would recommend Plug Data, it has auto-completion, has a dark theme, comes included with the else library and can be used as a DAW plug-in, although it uses different shortcuts than pd vanilla:
https://github.com/timothyschoen/PlugData

Two other projects I would recommend checking out:
https://www.automatonism.com/ - A modular synthesizer in Pd (you can actually click on buttons to create the modules instead of typing them)
http://malinette.info/en/? - programming interactivity toolkit.

I'm now curious about what software you could use to build this macro keyboard, let me know

My AI professor back decades ago wished that he could start programming with MAX, but it was completely out of the range of the students. I'm hoping to pick up his dream, particularly since he's at a new institution that requires that he teach beginning computer science in Java (?!?)

Are there compatibility issues between them?

Ah, there was another version that might interest you, I don't recall if it has autocompletion, but it is more graphic:
https://l2ork.icat.vt.edu/main/make-your-own-l2ork/software/

Personally, Max seems more user-friendly and might be easier to cook something up, but in the long run it's not sustainable for universities and students a like, since it requires buying licenses.

Maybe not pd related, but might be relevant: https://www.microsoft.com/en-gb/makecode

Edit, I do not think you need to use dynamic patching to do the midi keyboard, you probably can just convert the midi key into an asci key and send it too pd.

My AI professor back decades ago wished that he could start programming with MAX, but it was completely out of the range of the students. I'm hoping to pick up his dream, particularly since he's at a new institution that requires that he teach beginning computer science in Java (?!?)

While java is joyless and corporate-desiccated, it's a better choice for computer science instruction than either Max or Pd.

Max and Pd are good at reacting to incoming messages (whether generated by GUI objects, MIDI devices, OSC apps etc) -- the top-down "push" model is often more intuitive for this than, say, SuperCollider's callback function paradigm. This suits the purpose for which Max was designed in the 80s.

"Push" messaging is also handy for signal flow graphs.

This messaging model is terrible at expressing complex algorithms. (I don't have any plans to back down from that word.) And, Pd and Max both suffer from woefully underdeveloped data structures (Pd's "data structures" do not quite replicate computer science's hash tables, heaps etc -- which computer science formalized because they're optimal solutions for certain problems) -- I suspect this is because they're designed principally for reactivity, not for data work.

They look cool, and I think I've gained a lot actually by figuring out how to do some non-trivial stuff in Pd (e.g. my tick-scheduler abstraction), but I would never use either of them for hard core programming tasks. They are really not built for it.

hjh

Chords are particularly difficult for her because of both the angle of her wrist and some disobedient fingers.

Requiring teenagers to learn a C-derived language culls out kids with no talent for computer science (not to mention the kids with talents in computer science that don't happen to stem from the same sensibilities as the teletype) but it doesn't make a literate society.

We don't require kids to read Infinite Jest or House of Leaves when they start to read. They read Dr. Seuss and Lewis Carroll because they show you how English works, including how to hack it for your own purposes.

You didn't learn data structures first. You learned first by hacking around with something that made a little sense, but was beyond your understanding, and you took stuff apart. That works for a lot of people who are inclined lexically in a teletype-compatible way. But lots and lots of people aren't. Programming languages aren't typed monospace because it's the best, proven way. It's because Grace Hopper had access to a teletype and mnemonic sets of letters both made sense to her and were compatible with the technologies available at the time. Its current commonality is a historical accident.

The gap between "kid languages" like Scratch and, say, Java has to do with pedagogical, philosophical blind spots in computer science, where computer scientists reproduce other computer scientists like themselves. And that means that computer science has entire areas that are underexplored, and things like Pd, SmallTalk, HyperTalk, and even Minecraft show paths not taken, with no guarantee that there are not lush forests of new kinds of understanding down those paths.

My AI professor back decades ago wished that he could start programming with MAX, but it was completely out of the range of the students. I'm hoping to pick up his dream, particularly since he's at a new institution that requires that he teach beginning computer science in Java (?!?)

I suggest also to keep an eye to this web javascript clone of max
https://github.com/Fr0stbyteR/jspatcher

Personally I got into programming through pd, I learned c bc I wanted to write externals.

I'm now curious about what software you could use to build this macro keyboard, let me know

I've built keyboards in the past with an Arduino Pro Micro, a multiplexed array of switches, and Arduino code.

Next time I'll probably just do a diode array instead of the multiplexers. I don't much like C so I might also take a shot at doing it with a Raspberry Pi Pico and CircuitPython because I dislike Python less than C and I suspect it's a better introductory language for my students.

If it's at all possible to do it with Pd I will, though. I see toolsets that compile it for certain microcontrollers (Teensy, Daisy) but I don't know how broadly true that is, and a $4 microcontroller is far more valuable to me than a $30 one. Because if you screw up a $4 microcontroller you have an $8 microcontroller budget on the project, but if you screw up the $30 one you have a $60 microcontroller budget and probably have to wait to get it because you didn't get a pile of them in tape packaging to use with kids who are just learning to solder.

@ddw_music Your concerns are the opposite of those for introducing programming to kids who need to be conceptually literate in a microcontroller-saturated world.

Ohhhhh... I misunderstood the environment, my fault. I think what I said would make sense at college level, but definitely, for kids, not Java. NOT Java.

(Actually, if it's up to me, I wouldn't even subject college students to Java. I can hardly think of a better way to turn anyone off from programming.)

If they need hardcore data structures, they'll keep learning new environments and languages...

Yes and no... if the environment doesn't support rich data structures, then you might never know that they exist, and the lack of them can actually restrict the scope of questions you're able to ask. This isn't important at beginning stages, of course, but it's nice to have them around -- "huh... PriorityQueue, what's that about?" (vs Pd where I actually built a scheduler based on the priority-queue implementation from pd-container, and then someone here asked, "Well why do you need that?" )

Right now, we have a society with dangerously low literacy in the machines they use all day every day. Those kids aren't all going to become computer scientists, but unless they learn that machines don't "don't want to work", but instead are following algorithmic processes that might include errors, the world is increasingly mysterious to them.

This, I 100% agree.

One thing I would note here about Pd culture is that it doesn't talk much about algorithms (except jameslo in this forum). When I have asked for resources about programming pedagogy in Pd, or tried to identify general patching patterns that can be applied to a variety of algorithms, that conversation doesn't go very far. When somebody asks e.g. how to iterate over a list, usually the answer is "giving them a fish" rather than "teaching them how to fish."

I suspect a couple of things here. One is the mystique of "it's not really programming -- it's patching" (but somehow it's just as technical and fiddly as programming). The other is perhaps a bit of a feedback loop -- if it's not really good at "standard" algorithmic thinking, then people don't do it as much, meaning its mechanisms remain underdeveloped, and so on.

This is not to say Pd is a bad choice for beginners. But, if the goal is some degree of algorithmic literacy, there's a bit of an uphill climb with patchers. Graphical patching could be excellent for pedagogy, but Max/Pd IMO are not the ideal level of abstraction for this. They both pretend to be high-level while actually requiring a lot of low-level fiddling about.

The gap between "kid languages" like Scratch and, say, Java has to do with pedagogical, philosophical blind spots in computer science, where computer scientists reproduce other computer scientists like themselves. And that means that computer science has entire areas that are underexplored, and things like Pd, SmallTalk, HyperTalk, and even Minecraft show paths not taken, with no guarantee that there are not lush forests of new kinds of understanding down those paths.

FWIW my favorite programming environment is a Smalltalk derivative (SuperCollider).

Also FWIW, I chose Pd for my college-level interactive multimedia class, even though I very much prefer SuperCollider in my own work. At least in this conservatory of music technology department, maybe 1 student per year gets into code, while 4-8 out of 50 might seriously engage with Pd/Max. I would have made my life a lot easier by forcing SuperCollider, but it was worth the effort on my part for more student engagement.

So I do get what you're saying. Students may not need hardcore programming power.

hjh

Have you shared the patch you built? It’s not something I understand, but I’m curious to see your yarn ball.

I mean, maybe you’d have gotten two people into SuperCollider and the other six would have abandoned the entire avenue of inquiry.

That was my thinking.

It seems my department will introduce a "new media" concentration with one semester of introduction to programming languages. That may be an "in" for SC.

Have you shared the patch you built? It’s not something I understand, but I’m curious to see your yarn ball.

https://forum.pdpatchrepo.info/topic/13882/event-scheduler-backbone-of-a-master-transport

hjh

Thanks! Looking at it, I understand it far better than the description. I might need this at some point!

Cool! I hope you find it useful. It's loosely modeled after Scheduler in SC.

I joked about "why do you need that?" -- in fact, if Pd is 100% in control of timing, then you could handle scheduling using [timer] and [delay]. But in external-sync cases, Pd timing objects are not in control, so you do need something that responds to ticks. If you build your patch around a robust scheduler, then you could translate it easily to work with an external clock. If you didn't, then the patch is less flexible.

With abl_link~, it would look like this. The tick source could just as easily be a metro driving a counter.

hjh