The four chapters we read this week were very inspiring as I reflect on the experience of my digital music workshop.

:: In “The DJ Factor,” Mike Challis describes a curriculum for at-risk 14-16 year olds in the UK who have not had any previous music experience. The key to his experience is to start from music that the students are interested in, which is novel for students who often have a sharp divide between music in and out of school. In the UK, kids listen to electronic music, UK garage and hip-hop. The first stage is to put music into their hands as DJs, and through a 4-step process of removing elements to fill with original elements, they produce a piece of original music.

In Stage 1, beatmatching is used as a way to learn about beats and bars. I’ve struggled a bit to teach this concept to the kids in my workshop, and despite the fact that they are much younger (some are as young as 7), I can’t think of a more hands-on approach than using two turntables and a mixer.

In Stage 2, Reason is introduced as a beat-making tool, and students create original beats to layer over their DJ mixes. The main lesson here for me is that the students aren’t given a comprehensive overview of how the program works, but instead they just dive in to figure it out on their own. Reason gives immediate feedback, so it may in fact be easier to learn from diving right in than by a general tutorial. The instructor’s role is to answer questions, monitor, intervene when necessary and provide feedback.

In Stage 3, students add a bassline either with a live performance using MIDI, or by sequencing each step of the melody. And in stage 4, structure is introduced by listening to the music that the students brought to the program. At this point, the original mix can even be removed to leave each student with a completely original composition (not to stay that remixed elements couldn’t also be used in original ways). The article mentioned that Dizzee Rascal had this type of opportunity when he was a teenager, I found this to be really inspiring.

:: The next chapter, “Composing & Graphical Technologies” by Kevin Jennings, gave me a lot to think about as I design my web-based audio editor. I’m working on the design, and the visual representation of sound will have a significant impact on how people use this tool.

Graphical interfaces can provide novel ways for young people to dive into composing without needing to learn notation or a sequencer. However, music is not visual, so any attempt to represent it visually biases and affords certain types of uses, whether it’s traditional notation or sequencers or Finale or Logic or the original programs Hyperscore and Drum Steps mentioned in this paper.

I’m really inspired by idea idea of Hyperscore, in which ‘motives’ can be brought into a ‘sketch.’ The author believes that this particular interface is best-suited to teaching rhythmic concepts, texture and form, but despite his efforts, questions concerning pitch did not come about as naturally.

If you set a young person free to explore music composition in an environment with certain affordances, they will come to understand many different types of musical concepts on their own. After an initial stage of “bricolage” or “just messing around” to become familiar with the interface, Jennings observes the way students settle on a clearer idea to explore. This bricolage is an important part of the process that reminds me of Mike Challis’ approach in teaching Reason. The questions come up as part of the exploration process, and in the case of Hyperscore, concepts like inversion, repetition, and variation appear in students’ composition without any mention of these concepts by the teacher. In short, musical concepts don’t need to be explained as long as the system affords the potential to discover them through exploration.

In contrast to HyperScore, Drum-Step as a graphical interface that students seem more likely to interpret in non-musical ways. Their motivations are more about making things that look cool than by the musical inspiration. So graphical interfaces can have drawbacks. Interfaces need to incorporate non-musical elements, and there is a point where those might eclipse the musical elements. If the goal is music education, then it’s best to design an accessible path into musical understanding.

In the case of my web-based audio editor, there is a question of whether to follow the established ways to represent sound, or invent my own. There is also a question of how to describe the various effects that can be used. If an effect is offered, it will be used, is the message of Jennings’ article. However, in the case of a “feature-bloated” program like Microsoft Word, only a small percentage of the program’s features are actually used on a regular basis by most users. That is the problem I’m trying to solve by creating a program that streamlines some of the audio editing features available in other programs like Audacity. But I need to think very carefully about how they are represented visually.

:: Reading Steve Dillon and Andrew Brown’s 2005 chapter on networked collaborative music-making  here in the year 2013, I’m struck by the way they approach “computer as instrument,” “cyberspace as venue” and “network as ensemble” with such novelty. The trick for this type of program to work is to send data (i.e. MIDI notes, OSC messages) instead of the actual audio (which is also data, but a different kind that takes more memory).

Some of the benefits of networked jam2jam are that this type of experience invites listening and creating at the same time. Participants need to use musical terms to communicate their ideas, and jam2jam provides chat boxes that facilitate.

Dillon & Brown identify three ways that students collaborate without being in the same physical space (country, even), : Disputational involves individual decisions without agreement. Cumulative collaborators largely agree, but avoid confrontation. Exploratory is a give-and-take, modifying each others ideas to build something that is greater than the sum of its parts, and that seems like the goal here.

A simple audio editor that works in the browser.

Audience: 2nd-8th graders in an afterschool workshop. I’m interested in designing (and ideally building some kind of technology) that supports this curriculum:

• Explore timbre. One exercise could have us draw shapes that we turn into sounds, inspired by Daphne Oram’s ‘Oramics.’ I know of a Max/MSP patch that can do this, so we could develop the software/experience.
• Create samples by editing+modifying our own original recordings (using Audacity because it’s free until we can find/build something better)
• Make MIDI instruments to play kid-made samples (possibly using MaKey MaKey + conductive ink + found objects…and Garageband?)
• Group improvisation with kid-made instruments in a system where each participant gets a chance to be the conductor/mixer/producer of a recording (possibly the soundtrack to a film made by another workshop)
• Record/sequence loops (in Garageband unless we can find a simpler way). Layer/arrange loops to create songs. Remix each other’s loops to create new songs / remixes.

I’ve decided to focus on an in-browser audio editor. Why? Because Audacity is too confusing:

All the features we need:

Functions:

• Upload a file (windows pcm wav)
• Save a file (windows pcm wav)
• Play a file
• Reverse
• Change amplitude
• Select a piece of the waveform –> Cut, Copy, Paste
• Pitch shift
• Time shift
• Fades at the beginning/end of file (created automatically before saving)

UI

• Buttons to upload a file and save current file
• View waveform (possibly also include frequency spectrum)
• Spacebar to play / pause
• Click to set start point
• Select to set start/end point
• keyboard shortcuts: –> Cut, Copy, Paste
• Effects menu to modify selection with effects (pitch shift, time shift, reverse)
• Zoom in / out (with keyboard shortcuts and buttons?)

Sketch:

 

Technology:

I have been looking at SoX and I think it is possible to do all of the editing on the server side. On the browser side, I’m looking at representing the waveform data visually in processing.js and also delving into the HTML5 web audio API

The following is an outline of notes/observations from this weeks’ readings for Technological Trends in Music Education.

Continue reading →

FLOW The Psychology of Optimal Experience (Mihaly Csikszentmihalyi). Continue reading →

Mitchel Resnick is the director of MIT Media Lab’s Lifelong Kindergarten Group. In a paper called All I Really Need to Know (About Creative Thinking) I Learned (By Studying How Children Learn) in Kindergarten, Resnick defines “Kindergarten-style learning” and explains why he believes it is essential for people of all ages—it even guides his own approach to designing educational technology like Scatch and Cricket.

Resnick defines the Kindergarten approach as a cycle, pictured at left, and I’ll reflect on each component below:

Imagine – Resnick’s role is to design for designers—kindergarteners of all ages. he is inspired by Friedrich Froebel’s pioneering vision of the first Kindergarten, where he presented a room full of materials (“Froebel’s Gifts”) that serve as the building blocks for creativity.

Here, Resnick identifies an interesting design challenge: the environment and its gifts must be general enough to allow for creative applications beyond what Froebel himself could have imagined. But there need to be some boundaries; the environment  also be specific enough to be easily understand so that learning can take place.

Create – design environments made up of building blocks (i.e. Froebel’s Gifts) for designers to construct

Play – Resnick critiques other approaches like “Edutainment” which seem to view education as if it were a bitter-pill that must be sugarcoated in entertainment. Edutainment combines two passive things that we might expect people to provide for us. By contrast, Kindergarten style is active, emphasizing learning through play. Resnick believes that play is “intimately linked” with learning because both involve “experimentation, exploration, and testing the boundaries.” Scratch, encouraged to “Play with code”

Share – important in what Henry Jenkins calls our increasingly “Participatory Culture.” Learn from each other, as a community, exemplified by Scatch’s website of open source games. So not only play/tinker with your own code, but with each other’s.

Reflect – document the process. Reminds me of ITP where we’re encouraged to document everything, hence this blog. It’s one thing to get something working once, but another to be able to recreate it and tinker with it down the line. I love these reflections from children who participated in a workshop utilizing Cricket workshop, who observed that it’s important to…

Start simple 
Work on things that you like 
If you have no clue what to do, fiddle around 
Don’t be afraid to experiment 
Find a friend to work with, share ideas! 
It’s OK to copy stuff (to give you an idea) 
Keep your ideas in a sketch book 
Build, take apart, rebuild 
Lots of things can go wrong, stick with it

…Failed experiments can be part of the learning process as long as they are supported by these sorts of encouraging reflections. Resnick called the workshop a success because the children not only learned, but learned how to learn.

Resnick’s approach to learning isn’t limited to kindergartners, but geared to learners of all ages, and he follows this approach himself when designing software like Scratch and Cricket. There are a lot of parallels to the way we approach learning at ITP, a program that provides a community of learners with certain building blocks and then encourages us to play with these tools, we share our work with each other often through open source code, and share skills through group prototyping, we document/reflect on everything, and then we iterate in an imaginative cycle.

Resnick’s “Kindergarten approach to learning” reminds me of Chris Crawford’s definition of “Interaction,” which I read for this week’s Physical Computing course at ITP. Both authors call for iteration through a cycle of steps. Crawford defines interaction as two actors Listening, Thinking, and Speaking. Resnick adds step because he wants to see learning take place through interaction. Crawford is writing for interaction designers, while Resnick is writing for what I might call “education designers” who are designing experiences/environments for young designers to take part in the programming. Interaction Designers are different from User Interface Designers because the former tweak the “thinking” aspect of the interaction, i.e. core functionality that is not traditionally made available to User Interface Designers. Resnick takes things a step further because he believes that if we can put “thinking” into the hands of the people who are interacting with the technology, that is the key to learning.

When Resnick refers to “designing for designers,” sometimes I wonder if this is always the best approach to learning? It’s not like all children are going to grow up to become designers…

:: Dale Dougherty has some persuasive answers to this question in his article The Maker Mindset. The founder of MAKE Magazine and, more recently, the nonprofit Maker Education Initiative, Dougherty believes that the Maker Mindset can transform education.

The Maker Mindset builds off of Carol Dweck’s book Mindsets in which the Stanford psychology professor found that some people have “Fixed Mindsets”—meaning they believe that their knowledge/abilities have a limit and they’re pretty close to maxed out—while others have “Growth Mindsets.” People with a Growth Mindset believe  they can do anything they put their mind to, and Dougherty emphasizes how essential this becomes in a world that is constantly changing. The Maker Mindset is a type of Growth Mindset through which people believe they can turn their ideas into reality. This is achieved by constantly experimenting, tinkering, and pushing the boundaries of what’s possible using what you already know. In the process, you’ll expand your own body of knowledge and probably create some cool things. Dougherty acknowledges that makers are not mainstream these days, driven largely by internal goals rather than external/social rewards. But he believes that Make can be even more of a social mindset if it is built around sharing, and that this starts with education.

To bring the Maker Mindset to education, Dougherty calls for the development of projects, kits and curricula. He wants young people to take leadership roles and join communities outside of school. Communities can provide exhibition space for makers that invites and inspires further participation. Dougherty believes that a record of participation in maker communities could be a valuable part of a young person’s résumé. What Resnick described as passive “edutainment,” Dougherty might call “consuming” and he believes that education by making things is the best way forward.

I’m not sure how I feel about the way Dougherty has built a brand out of the word “MAKE”, but I certainly do admire his mindset!

:: In Designing For Tinkerability, co-authors Resnick and Eric Rosenbaum critique Make’s approach because it is sometime narrowly misinterpreted as “making” physical things when really, for these guys, it’s more about the broad approach to making no matter the form. Tinkering is too often in the shadow of the more logical Planning, they argue, but in fact the ability to improvise and incorporate bricolage is increasingly essential. Resnick and Rosenbaum go on to share some of the thinking behind their respective tinkerable kits: Scatch and MaKey MaKey. Both kits are designed for tinkerability which in their veiw requires three things:

1.) Immediate Feedback – because tinkering means lots of quick experiments, and you’re not gonna sit around waiting for the results. Scratch shows the values of all variables (not the norm for programming languages) and lets you tinker while it’s running to see the results in real time. Makey has indicator lights to let you know what’s going on.

2.) Fluid Experimentation – it’s important to minimize the setup so that you can get started right away. Many programming languages require a lot of code just to get started and compiling and all this stuff that Scratch takes care of so that the user can focus on creating. Scratch has a “visual syntax” meaning that you can see if a certain object will take a type of input just by looking at the LEGO-like connector shapes. Like LEGO pieces, you can unplug blocks and leave them in your workspace and they won’t interfere with your other code the way that stray code would in most programming environments. Following the LEGO analogy, the kits may not be the sturdiest way to build something, but they aren’t designed for that, they’re designed to be tinkerable.

3.) Open Exploration – Both kits let you use a variety of materials to create projects that fall under a variety of genres. Scratch materials include the preloaded sprites and objects, but you can also make your own and find millions more sources of inspiration from the online community, all licensed under the tinkering-friendly Creative Commons Attribution-ShareAlike license. MaKey doesn’t come with anything preloaded, but with this tool “the world is your construction kit.” Both MaKey and Scratch are tools that can be used to play across genres (in more than just the musical sense) which is valuable because tinkerers tend to work “bottom-up” where they start out not knowing what they’re building and through many iterations they may touch upon a bunch of different genres before they determine the goal at the top.

Side note: I wonder if my application ought to encourage non-musical exploration…

In Resnick and Rosenbaum’s final note on this article, they touch upon the idea that the kits they’ve built can’t encourage tinkerability on their own; they need to be used in a tinker-friendly context. Educators looking to get the most out of their kits are advised to emphasize the process over the product…themes over challenges (broad enough so that each person cares about what they’re working on, but specific enough so that everybody feels it’s a shared experience…highlight examples for inspiration…give questions as answers. This is very inspiring to me because just the way we learn by doing, if we can answer our own questions, we’ll understand the answer better than if we’re given the answer through edutainment.

:: Some notes from What Develops in Musical Development? A View of Development As Learning by Jeanne Bamberger

• Hearing music is a performance because we reconstruct it in our minds. So the same tune can sound different when we hear it in different contexts.
• Cognitive developmental tracks how we organize perception and strategies to understand the world. Some are situational (context) and others are abstract (systems to categorize the world).
• When educators use just one organization symbol system (like musical notation) that privileges certain types of categorization (“ontological imperialism”) and it’s important to have a lot of different ways to understand the world/music. Interactions between these various understandings foster complexity.
• Trust musical intuition and embrace exceptions to “the rule”
• Whatever children do, there is reason. Explore…