Summary:

Creative Coding in its practical form and in “critical engagement with digital media has become a part of the art education curriculum” (1) in recent years, providing new material approaches to a Studio-based model of pedagogy in Art Schools. This newer material approach to the use of technology provides important potential for creative expression and pathways within creative industries for experiential approaches. However, there still remains a friction in how a materials, originating in instructional modes of delivery, can be translated to creative practices where there is an emphasis on reflection, process and practice.

This practice-based research examines the approach to teaching Creative Coding curricula specifically in Art Schools, through the term ‘Functional Error’. A Functional Error in this research is defined as as a piece of code that compiles without error in software yet in the physical environment, it results in a kinetic or visual error. Whilst systematic in its definition a Functional Error is also the result of a gap in conceptual understanding between established and new creative disciplines.

When transitioning from a predominantly screen-based exploration of creative code to electronic physical components, beginners are faced with three areas to troubleshoot; the software, the hardware, and the bridging of the two together. This research seeks to question how the bridge between software and hardware can be communicated more effectively for students in an Art School environment and if in doing so, what are the educational benefits of exploring these functional errors for staff and students?

When discussing the bridge between software and hardware the term bridge is defined in two parts. The first, a physical communication protocol between code (software) and an electronic circuit (hardware). The second, as the conceptual space that joins these elements. The bridge is often only made tangible via a cable joining software and hardware together and as such it can become difficult to troubleshoot from a conceptual and practical perspective.

In this research I will produce tangible tools focusing on three key areas; feedback, exploration and augmentation. Each practical prototype seeks to provide users access to metaphors, language and creative agency in an environment where “visually inclined practitioners—who are often guided by instinct encounter the formal and unforgiving world of syntax, algorithms,and logic.”(2)

Questions :

• How can the bridge between software and hardware be communicated more effectively for students and staff in an Art School environment and if in doing so, what are the educational benefits of exploring these functional errors for staff and students?
• If a greater understanding of electronic circuits and code can be obtained by not necessarily solving or removing friction points but by primarily only highlighting them, and in doing so can physical computing materials provide more expressive creative freedom when these barriers to learning are removed?
• How does the use of embodied interaction, via familiar Art School materials, inform our computational understanding?

Aims and Objectives :

• To demonstrate how the role of certain programming methods (such as timing) can affect the behavior of an output using augmented pedagogical approaches from Art School practices.
• To re-contextualise existing screen-based programming methods into physical materials to see if Art School staff and students can more easily comprehend such methods.
• To articulate in practical forms common pain points when bridging software with hardware to provide Art School staff and students with more creative agency in the long term.

Feedback :

Currently the focus of troubleshooting errors in programming languages is via highlighting syntax errors (linting) in the software or IDE. However, as Artists and Designers there are wide conceptual reasons for using code resulting in the pushing of creative and programmable boundaries. As Functional Errors also include conceptual misunderstandings of what outputs will result from certain programming methods, it is important to explore how this can be fedback to users.

When considering physical computing, students may find a visual or kinetic output that differs from what they expect from their code. As their code is technically correct it will not feedback any runtime errors. Therefore, this shield explores an alternate pedagogical method of providing legible, immediate feedback regarding what the microcontroller is actually executing.

An example would be a servo motor that is intended to move 0 -180 degrees but is only moving 0 - 60 degrees. The code compiles without error but the user has not considered the timing of the commands being executed. Therefore, the motor does not have enough time to fully move to 180 degrees before reaching then end of the loop function. Without the conceptual understanding of timing and kinetic movement it may be difficult for a user to debug this error.

The aim of this Arduino Uno shield is to listen to input and output activity on the Uno pins and provide visual colour coded feedback based on the behaviour executed.

• Digital pin is HIGH a light will be green
• Digital pin is LOW a light will be red
• PWM pin is pulsing a light will be blue at the intensity and timing of that value

As such the example above would be illustrated as a very fast pulsing blue LED signifying the message is being executed far faster than the servo motor can move.

Should a user be accidentally sending a message out of a different pin to which a component is plugged into then this should also be evident via the number LED that is on or off.