CNMAT / Music-and-Computing

Materials built for MUS158A, MUS158B (B is only io area of patchers)
Other
6 stars 3 forks source link

lesson 14 updates #89

Open equilet opened 6 years ago

equilet commented 6 years ago

Should we consider renaming this to feedback? The term loopback seems to be relegated to usages with virtual network interfaces, and in telecommunications, etc. "Feedback" is also used throughout the Max tutorials, which makes it feel a bit more consistent.

equilet commented 6 years ago

general:

mouseharp:

tab/section names:

ramagottfried commented 6 years ago

I agree maybe feedback is better -- or something like "uses of state in odot".

I just discovered the demo adrian made where he refers to it as "recurrence" -- which covers pretty similar material, I believe referring to "recurrence relation" ( https://en.wikipedia.org/wiki/Recurrence_relation ).

It's a decent demo with some interesting bits not included in the course lesson 14 -- I think maybe it should be cleaned up a little, and updated to show how to use the () parenthesis shorthand for apply() which reads a bit easier to me. As in lesson 14, there seems to be a close connection between the feedback patching design with calling stored functions : )

so, I think I vote to call it "feedback" in the lesson but also mention "recurrence", and add a link to to adrian's demo (even if it's basically the same thing).

ramagottfried commented 6 years ago

re: mouseharp

the [/~ 12] at the bottom is a tad problematic, only because it makes every voice quieter, rather than looking at the number of active elements based on the delegation

my general rule of thumb is keep it simple -- and I've found it's a bit safer to scale for the maximum possible value, since the number of voices playing could change at anytime, but feel free to make an improved version!

mouseharp area: why aren't the [p players] abstractions? Is each one uniquely edited? the name for that abstraction could be something like cnmat.testvoi.delegate~ or similar

I usually use subpatchers rather than abstractions except for when I need patcher args, or if a patch is a really reusable tool -- the paste-replace command makes it pretty easy to update everything after an edit, and then there are fewer dependencies, etc. so you can share it easier? no objections to making it an abstraction here though if you want.

can the mouseharp example also be included as one of many examples in a package /examples folder? Or is this typically the way things are showcased in the course? Do we have more examples like this that could be thought of as more general than the lesson plan?

I guess most of the examples are already part of the lesson plan -- that was the idea of the lesson plan development meetings way back when, that the lessons should be strongly musical examples.

if you think the examples folder is more appropriate for the lessons, maybe we could make patches for the extras menu that just load the file from the example folder and then close themselves. Or a Lesson Navigator patch in the extras folder. Or have the students look at the folders rather than the extras menu? idk what the best layout is -- extras seems not bad, but not sure where most people look for things.