Hm, €45, could be promising though.

https://www.contemponet.com/en/shop/pure-data-electronic-music-and-sound-design-1/

hjh

@seb-harmonik.ar said:

I think the simplest things to build are simple enveloped saw (phasor~) & sine waves & noise, ...

Continuing the analogy to music theory: "Start with simple things like modes, triads, then chord functions, non-harmonic tones, secondary dominants..." but the devil is in the specific decisions about what is given and what is left to the student. Those "complete the 4 part chorale" exercises don't design themselves based on vague descriptions. It takes a lot longer than you think.

I don't think it's quite enough to tell them to replicate something I demonstrated in class -- I want them to show some comprehension -- but it gets very tricky. If you just give it to them whole, they can copy without understanding. If there is connective tissue that was presented but they have to finish, it's very very easy to forget some crucial details in class. Then they get frustrated with the assignments and stop doing them. So it's either out of their grasp, or boring.

Maybe I'm making a wrong assumption and maybe having them duplicate structures is enough.

I would say gear assignments around techniques they have to use rather than things they have to build. That's how my electronic music classes were taught iirc.

I wish I were blessed with a larger number of students with the vision to see the connection between techniques for their own sake and artistic applications of techniques... but that is sadly a small percentage in this department. They need a bit more guidance to have something functioning at the end.

also iirc I mostly learned pd from, johannes kreidler's book which does have some exercises http://www.pd-tutorial.com/english/index.html

Thanks, will have a look.

hjh

One of the hardest things I'm finding about using Pd in the classroom is that I have to invent every homework exercise by myself.

If I were teaching music theory, I would have a textbook with exercises at the end of each section.

I have looked at a few Pd books and nobody -- nobody -- has bothered to leave anything for students to do. (MSPuckette's Theory and Practice book has theoretical questions, but not so much in the way of "build x in Pd.") So the learning model is primarily passive -- "look at how to do x" -- without much in the way of progressively graded active assignments.

Which leads to the conclusion that the state of graphical patching pedagogy may be surprisingly underdeveloped for a 25 35 year old paradigm that is more popular than code in music-academic settings.

What am I missing? Apart from being exhausted, with health side effects, by the labor of developing course material from scratch (without being paid extra for the extra labor).

hjh

@Obineg said:

in max we dont have a [symbol] object ...
so it seems a bit strange that it doesnt work with [symbol] either.

because... what is its purpose then?

Off topic, but the punchline I found most recently in Max is that [swap] allows only ints for the left inlet / right outlet

Plenty of inconsistencies to be found in both platforms

hjh

In any case, after a bout of exhaustion this morning, I decided I need to stay with Gem for now. It's not a significant enough part of the curriculum that it's worth killing myself to rewrite all the lectures.

Fiddling with chroma-key in the other thread also showed me the reality of taking on the responsibility of maintaining a shader library for the 60Hz abstractions. I don't have the expertise to do it well, and no time or energy for it either. I'll publish what I have on github, should be a good starting point for someone else. But that rules it out for my course. I've been quite overworked for a few years now; it would be unwise to commit to both a significant course rewrite and a large development effort to prepare image processors.

hjh

Actually -- a Processing example suggests that the shader doesn't need two image inputs. All you really need to do is draw two layers: 1, a background layer, and 2, use the shader to generate alpha on the foreground layer, and draw on top of the background.

That can be done with the work that I did on shaders before.

I had a crack at it, and I'm afraid I got only as far as not crashing. This is probably because I don't understand the math that's being done on the pixel colors, and didn't take time to figure it out. (Most of the fragment shader is copied directly from Processing example.)

You would need the shader-support branch of my fork of 60Hz's abstractions: https://github.com/jamshark70/Ofelia-Fast-Prototyping/tree/topic/shader-support -- don't use the main branch! This is all still experimental and not ready to merge.

Then the foreground layer looks like this (haven't added background yet): 0801-chromakey-test.pd

The problem at this point is that I can't find HSV settings to make the green bits actually transparent. I would have expected that setting the range slider to 1.0 would make everything transparent, but it isn't even doing that. So there must be a logic error in the fragment shader, but I'm out of time for now. Maybe you can figure it out.

At least -- having a template that doesn't crash is a good step forward.

hjh

Thanks all -- I ended up using pdcontrol because the final target is a message box (so in fact it could be either a number or a symbol).

I'm glad to hear it's been discussed. Hope it doesn't disappear into that abyss from which pull requests never return.

hjh

[bang(
|
[symbol 1]
|
[print]

... prints only "symbol."

It's illegal to have an ASCII representation of a number stored in a symbol object?

Well, I disagree with that. If it's an abstraction argument that could be either numeric or symbolic, then... the only way is [pdcontrol], right? Because you don't know in advance whether it should be [f $1] or [symbol $1]. (Come on... ftoa() isn't hard.)

hjh

I just had another quick look at this.

A green screen requires two input images. Currently [of.shader] doesn't support that... and it would be difficult to disambiguate which image is which.

Needs a bit more thought.

hjh

@seb-harmonik.ar said:

@ddw_music agreed. though it's generally more intuitive at first especially for audio imo

At some point, I realized that code requires you to have a mental map of the expected state at every step in the code sequence. Without this mental map, basically you're just throwing tokens at the wall and hoping something sticks. It's a little easier to visualize with patch cables, except for the ever-present risk of spaghetti patching (and this risk increases dramatically as algorithmic complexity rises).

But, though state is invisible in code, it scales up easily to very complex processes in a way that I don't see happen in patching very often. (Perhaps patching seems more intuitive because it implicitly discourages complexity.)

For audio, I'd agree in that new SC users do have trouble visualizing the signal graphs when they're specified in code. (But it's much easier to create large numbers of parallel chains in code, too.)

hjh