I'm a makerspace teacher in an alternative school in Western Massachusetts. I have a student with cerebral palsy who's interested in programming, partly because she's quite creatively compelled and partially because being able to program would allow her to build devices that are otherwise hard for her to use, like game controllers. It turns out she also has an interest in electronic music. So that got me thinking about Pure Data.

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

@JoshuaACNewman A macro keyboard can be made much simpler just using a normal keyboard and keybinding, some info here. I started making a version which accepts two key commands so you could type "ag" to get [array get] and the like, but I am failing to find my plugin, i either accidentally saved over it or lost it. But with just keybinding you could get around 100 objects on a standard keyboard with single key commands and shift/capslock and just relabel the keys. You could also use a midi keyboard and dynamic patching.

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.

@JoshuaACNewman said:

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

@MikeMorenoDSP Yeah, not only am I a high school teacher, but we're in one of the poorest districts in New England. It would be wildly unethical for me to suggest a tool that costs money to kids who often don't have stable housing. Never mind whether I could afford it on my own salary. Anything that has a license that could prevent the kid from using it in the future — particularly if it winds up something they rely on materially or even creatively — makes that license the wrong choice.

@oid No, the issue is with the way her hand interacts with the keyboard. Custom building a keyboard is well within my capabilities and (eventually) within hers as well. The important thing is that it has to be at a different set of angles than one for the average human hand. I'm hoping that by the time she graduates, she'll be designing in Fusion360 and printing herself adaptive parts with abandon. But definitely some sequential key combinations are a good idea.

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

@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. If they need hardcore data structures, they'll keep learning new environments and languages. 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.

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.

@ddw_music said:

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

@MikeMorenoDSP I think the author of plug-data said that only the plugin version of plug-data didn't support externals, the standalone should.

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

@seb-harmonik.ar I suspect that kind of arc is really common. I found BASIC to be impenetrable and HyperTalk to be magical. LISP made more sense to me than C did by a long shot.

@MikeMorenoDSP

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.

@JoshuaACNewman said:

@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

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

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

@ddw_music in the intro to programming class I took in college my teacher used processing which is a pretty good intro to java.
Though java seems a bit pointless to me tbh. (Not to mention everything gets messed up when the VM doesn't work right)
Personally I actually like super collider more as well, but pd is somewhat easier if you aren't doing things that require text programming (tho you can use pdlua) and I've already put the work into it.
Not just for the reasons you mention but also bc the architecture is far superior/more efficient

@seb-harmonik.ar Irrespective of whether it's more efficient in terms of processor overhead or whatever, the important thing is that it's more efficient conceptually for a large number of beginners. And, unlike, say, Scratch, it's really worth becoming an expert in it. There's a LOT you can do, and for certain creative directions, it's far closer to optimal.

@JoshuaACNewman said:

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!

@JoshuaACNewman said:

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