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

@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