Phys Osc

8/10/2019 Phys Osc

1/51

Phys-Osc: An Interactive Physics basedenvironment that controls Sound Synthesis

Jason Doyle10048464

Faculty of Science and Engineering

Department of Computer Science & Information Systems

University of Limerick

BSc in Music Media and Performance Technology

Submitted on 17th April 2014
mailto:%[email protected]://www.scieng.ul.ie/http://www.csis.ul.ie/http://www.ul.ie/http://www.ul.ie/http://www.csis.ul.ie/http://www.scieng.ul.ie/mailto:%[email protected]

8/10/2019 Phys Osc

2/51

1. Supervisor: Dr. Kerry HaganDepartment of Computer Science & Information SystemsUniversity of LimerickIreland

Supervisors signature:

2. Second Reader: Mr. Nicholas WardDepartment of Computer Science & Information SystemsUniversity of LimerickIreland

Second Readers signature:

ii

8/10/2019 Phys Osc

3/51

Abstract

The projects aim is to nd new mediums for controlling sound synthe-sis, transforming the the desktop paradigm of point and click. It aimsto provide sonication alongside visualization of systems commonlyseen in nature such as the ocking behavior of birds. Implementationof these systems will allow for the acquisition of control data which isto be sent to the host Granular Synthesis engine over the Open SoundControl (OSC) network protocol creating a dynamic audiovisual ex-perience for the user.

8/10/2019 Phys Osc

4/51

Declaration

I herewith declare that I have produced this paper without the pro-hibited assistance of third parties and without making use of aidsother than those specied; notions taken over directly or indirectlyfrom other sources have been identied as such. This paper has notpreviously been presented in identical or similar form to any otherIrish or foreign examination board.

The thesis work was conducted under the supervision of Dr. KerryHagan at University of Limerick.

Limerick, 2014

8/10/2019 Phys Osc

5/51

Acknowledgements

I wish to acknowledge the knowledge and guidance provided by myadvisor Dr. Kerry Hagan throughout the development of this project.I would also like to thank the faculty of the Computer Science de-partment for their time and assistance throughout the course of mystudies. I also wish to acknowledge my colleagues in the MMPT classof 2014 for their assistance and encouragement throughout.

8/10/2019 Phys Osc

6/51

For my parents Michael and Loretta, my sister Lisa, and my partnerSara for their support and encouragement throughout the course of

my studies.

8/10/2019 Phys Osc

7/51

Contents

List of Figures v

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Research 6

2.1 The Nature of Code & Indeterministic Algorithms . . . . . . . . . 72.2 Granular Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Existing Products . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1 Konkreet Performer . . . . . . . . . . . . . . . . . . . . . . 102.4.2 GBoids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Overview of Technology 14

3.1 Android Development Tools . . . . . . . . . . . . . . . . . . . . . 14

3.2 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.1 oscP5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.2 controlP5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.3 Ketai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.4 APWidgets . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Max MSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 CSound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iii

8/10/2019 Phys Osc

8/51

CONTENTS

4 Implementation 194.1 Early Android Prototypes . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Prototype 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.2 Prototype 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Final Android Implementation . . . . . . . . . . . . . . . . . . . . 244.3 Audio Engine Implementation . . . . . . . . . . . . . . . . . . . . 24

4.3.1 Max MSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.2 CSound . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.1 Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Conclusions and Future Directions 27

5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Appendix A: Application Screenshots 31

Appendix B: Java Implementation of the Boids Algorithm 35

Appendix C: Max MSP GUI 37

Appendix D: Granular Implementation in CSound 40

References 41

iv

8/10/2019 Phys Osc

9/51

List of Figures

2.1 Konkreet Performer . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Gboids Max Msp Interface . . . . . . . . . . . . . . . . . . . . . . 13

4.1 Android OSC Settings . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Boids Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1 Nexus 7 Tablet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Nexus 4 Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Max MSP Router . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

v

8/10/2019 Phys Osc

10/51

1

Introduction

The project investigates the application of the Boids algorithm to sound synthe-sis. The type of Boids algorithm used is Daniel Shiffmans processing port of Craig Reynolds original algorithm. In this report I will describe the process of developing an Android application that sends the Boids location and accelerom-eter data over Open Sound Control (OSC) to a host audio synthesizer that hasbeen constructed in Max and Csound. The audio synthesizer utilises synchronousgranular synthesis techniques to granulate sampled sound. Synthesis parametersare updated in real-time across a wireless network creating audiovisual synchronybetween the visual and audio algorithms.

1.1 Background

Mobile Processors have come a long way since the early days of the Androidplatform, but some problems do still exist. Peter Kirn (2013) discussed Androidlatency indept stating that Google has deserved some criticism. Years of subse-quent updates saw the company remain silent or unresponsive about critical audioissues. The critical audio issues Peter discusses are namely related to latency.The Dalvik runtime system that Android employs has issues with threading whenit comes to audio performance. While this has certainly improved over time, it

1

8/10/2019 Phys Osc

11/51

1.1 Background

still has a long way to go to compared to the iOS model.

LibPD seemed like a good place to start from, rather than dealing with thecomplexities of building an audio system that when ne tuned may still have issueswith latency. After testing some basic functionality from Peter Brinkmans book,Mapping Musical Apps Brinkman (2012), it was decided that implementations of granular synthesis would require too much polyphony to operate efficiently as anandroid application. A simple Wavetable, Additive, FM or AM synthesis method

can be easily built because polyphony is not really a problem when using twoto ve voices at any one time. Problems would most certainly arise when usingone hundred instances of the patch which would be a requirement for an effectivegranular synthesis patch.

Upon consultation with my advisor it was decided that a more effective so-lution was to create a granular synthesis patch in Max and use the Open SoundControl protocol to send data from the mobile device to the granular engine.Discussions also took place as to suitable visual algorithms to drive the granularengine. It was decided that the Boids algorithm would be a good match sinceit can generate a large amount of dynamic data that a granular implementationrequires.

The Boids algorithm was created by Craig Reynolds in 1987, it sought tosimulate systems found in nature such as the behaviour and ocking patterns of birds and shoals of sh. Reynolds (1987) based the algorithm on three dimen-sional computational geometry of the sort normally used in animation. Each Boiduses three basic forces, Separation, Cohesion and Alignment to dene its positionin a three dimensional space. The ocking animation that occurs shifts dynami-cally across the screen updating each Boids location. The algorithm, which is animplementation of Daniel Shiffmans Foundation (2013) Boids algorithm, whichin itself is an implementation of the Reynolds (1987) model that provides thevisual feedback component of the application. Modication of Shiffmans imple-mentation occurred to make it more suitable for a mobile devices screensize and

2

8/10/2019 Phys Osc

12/51

1.2 Motivation

to supply accelerometer data alongside the data being gathering from the Boidsocking pattern.

1.2 Motivation

There were numerous motivations to build this product. The rst one being thatthis type of product doesnt exist on the Android Platform. There are manyproducts that use the OSC protocol such as TouchOSC, Touch Daw, Control,

QuickOSC, and Kontrolleur, but none of these products offer the use of inde-terministic algorithms to generate control data in order to send over a wirelessnetwork. The aforementioned programs merely respond to touch activities in theinterface and send that data to the host computer. PhysOsc generates its owncontrol data which then can be tailored or modied to the users needs. The ideaof continuous sonic and visual variation also appealed to me. Granular Synthesisprovides a very rich timbral backdrop to the algorithms visual complexities. Thesynthesis parameters benet from a wide range of control data that an algorithm

like Boids can provide.

Implementing a higher level control scheme such as Boids takes the focus fromdata creation and shifts the focus to controlling geometric shapes. I wanted tocreate an interface that allowed for the attention of the user to be focused onthe animations movements and their correlation with the sonic output, Most mu-sical interfaces concentrate on one-to one mappings, whereby the user touchesthe screen and creates a direct response in the interface that usually changes oneparameter at a time.

The project was born from the idea that the equal temperament scale coupledwith one-to-one mappings does not provide adequate control over the many pa-rameters a granular synthesis engine needs. Higher level control of musical datais not a new concept having being explored in the Serialist works of KarlheinzStockhausen and Stochastic work of Iannis Xenakis. Although different in con-cept the principles stay the same, to leave the creation aspect of musical data to

3

8/10/2019 Phys Osc

13/51

1.2 Motivation

a pre-dened set of rules.

Another motivation to build this product is the use of audiovisual synchronythrough the algorithm. The application displays the visual feedback of the al-gorithm on a mobile device whilst the sonication occurs through Max MSP ona desktop computer. Keeping the visualization and sonication algorithms sep-arate holds many advantages in that the user can use this software to controlany program that uses the OSC protocol, This includes Reaktor, Pure Data,

Supercollider, Csound, Iannix, Processing and vvvv. The number of programsincreases by the month, leading to OSC becoming a standard for communicationin audio and visual programs since its inception in 2001.

4

8/10/2019 Phys Osc

14/51

1.3 Thesis Outline

1.3 Thesis OutlineThe remaining chapters of this dissertation are as follows:

Chapter Two ResearchChapter Three Overview Of TechnologyChapter Four ImplementationChapter Five Conclusions and Future Directions

A series of documents have been included in the Appendix section of thisdissertation. These are:

Appendix A includes application screenshots from an android phone andtablet

Appendix B presents the Java code from the Android application

Appendix C includes application screenshots from the Max MSP GUI

Attached to this dissertation is a CD containing the following items:

folder 1 : Android Application

folder 2 : Max MSP and CSound les

5

8/10/2019 Phys Osc

15/51

2

Research

In the four years since our college course commenced, Mobile Technologies havebecome an integral part of everyday life. These devices offer huge potential for fur-ther development. With that in mind, research was carried out on many differentlibraries and tools with a view to the construction of an audiovisual application.During this period of development many tools were road-tested through tutorials.

The development tools in question include Processing, Android SDK, Max MSP,Phonegap, and also many web technologies such as the WebAudio API. Thesecross platform tools can allow for rapid prototyping of applications which thencan be scaled up in a professional grade IDE such as Androids Eclipse or ApplesXcode.

The end goal of this period was to transfer the knowledge learned from thecourse alongside the extra curricular activities and apply that to mobile technol-ogy development. Research began on the audio capabilities of the current cropof Mobile Devices in the summer of 2013. LibPD, Csound, and Processing offercross platform visual and audio capabilities. All three are ideal prototyping plat-forms as the same code will work on both desktop and mobile which makes allthree very valuable when working with multiple platforms and hardware devices.

6

8/10/2019 Phys Osc

16/51

2.1 The Nature of Code & Indeterministic Algorithms

2.1 The Nature of Code & Indeterministic Al-gorithms

Coding systems seen in nature using algorithms has been an area of particularinterest to me throughout the course of my studies. Daniel Shiffman calls thisThe Nature of Code , he has been one of the leading proponents of this typeof programming in the last decade. His selfpublished book of the same nameShiffman (2012), detailed ways to simulate the physical world with the program-

ming library Processing. His book covers many aspects of the systems of naturerecreated through computational media. Of particular interest to me is his workwith Physics libraries such as Toxilibs or Box 2D. There are also many excellentchapters on Forces, Fractals, Particle Systems and Genetic Algorithms. I planto use these algorithms to generate control data for the granular synthesis engine.

My research began with an implementation of the Boids algorithm. The algo-rithm exhibits fascinating lifelike patterns from nature with its creator Reynolds

(1987) stating A ock exhibits many contrasts. It is made up of discrete birdsyet overall motion seems uid; it is simple in concept yet is so visually com-plex.These complexities that are contained within the algorithm have generatedmany avenues for research, specically the sonication of each boids movementswithin the ock. Reynolds dened three forces which determined the behavior of each ock member. These forces are Alignment, Separation, and Cohesion. Eachforce provides a unique opportunity to transform each components data into auseable stream of information for sonication purposes.

Reynolds (1987) states the simulation of the ock is an elaboration of a par-ticle system. He denes the ock as having many contrasts and thatit is madeup of discrete birds yet overall motion seems uid. This seemed a familiar con-cept to that of Granular Synthesis. In the case of Granular Synthesis thousandsof simple grains combine to create a uid motion. Truax (1990) put it best whenhe made the analogy of granular synthesis to that of a river whose power is basedon accumulation of countless droplets of water. The common ground betweenboth paradigms already seemed useful for mapping to each other.

7

8/10/2019 Phys Osc

17/51

2.2 Granular Synthesis

2.2 Granular SynthesisBritish physicist Denis Gabor (1946) rst proposed the idea of sound grains in1946. His work proved very inuential to Iannis Xenakis who proposed an ex-pansion on that theory in his book Formalized Music. Opie (2003) hypothesizedthat Xenakis set out to design ways he could arrange grains of sound to cre-ate complex and beautiful textures. Iannis Xenakis hypothesized the theory of granular synthesis and laid the framework for future research in this area. Xe-nakis (1992) states, All sound is an integration of grains, of elementary sonicparticles, of sonic quanta. Each of these elementary grains has a threefold na-ture: duration, frequency, and intensity. All sound, even all continuous sonicvariation, is conceived as an assemblage of a large number of elementary grainsadequately disposed in time. He was particularly interested in spatialisation, inthree dimensional soundscapes composed of sonic clouds all with 3D trajectories.He integrated his vast mathematical knowledge to associate this elementary grainidea with stochastic methods for arrangement. Moving on from this lineage, Cur-tis Roads and Barry Traux have provided extraordinary insight into Granular

Synthesis techniques for the last three decades and remain the leading opinionson the subject.

Research was carried out to understand the concepts of Granular Synthesis, todetermine which method would be the most useful to implement in the prototype.The classic text on the theory side of this is Curtis Roads book Mircrosound . Inthe book Roads (2001) describes a grain as a brief microacoustic event, with aduration near the threshold of human auditory perception, typically between one

thousandth of a second and one tenth of a second (from 1 to 100 ms). Each graincontains a waveform shaped by an amplitude envelope. Each of these individualgrains has an amplitude envelope, Commonly used envelopes are Gaussian, Han-ning, Trapezoidal and Triangular. The Gaussian curve is the classic describedin Gabors text. Roads states that this is the smoothest from a mathematicalpoint of view. The typical parameters of granular synthesis include grain size,grain shape, envelope shape, grain spacing over time and grain density. Whenthese thousands of sonic events get assimilated and are combined, we can hear

8

8/10/2019 Phys Osc

18/51

2.3 Mapping

an animated texture at play.

There are many granular synthesis methods. The methods focused on areSynchronous Streams, Quasi-Synchronous Streams and Asynchronous Clouds.Roads (2001) denes the Synchronous Granular Synthesis method as grains thatfollow each other at regular intervals, He also notes that density parametercontrols the frequency of grain emission, so grains per second can be interpretedas a frequency value in Hertz. When emitting grains at regular intervals, lower

densities lead to a rhythmic, metric feel. This repetition at a constant rate leadsto what Scavone (2013) calls an audible frame rate, He also notes that Vi-brato can be created by slowly by varying the time spacing between grains. Aneffective mapping method would need to be employed from the Boids Algorithmto ensure that the datas not changing too quickly to achieve this effect in myimplementation.

Asynchronous Granular Clouds does away with the idea of linear streams.Roads (2001) states the Asynchronous method scatters the grains over a spec-ied duration within regions inscribed on the time-frequency plane. The Asyn-chronous method certainly has benets when using an algorithm like Boids tocontrol it. The major difference in this method as opposed to the Sychronous oneis that this method uses a stochastic or chaotic algorithm to control the grainstreams and also produces irregular stream as opposed to the constant stream forthe Synchronous method. Asynchronous granular synthesis has many benetsin terms of precision control and more variety in the sonic output. However, Iplan to use the Synchronous form because its better suited to real-time granularimplementations.

2.3 Mapping

The link that exists when mapping electronic devices, such as computers, to oneanother can be dened as active. An active link provides for two way communi-cation between both devices. Chadabe (2002) states the link can be a computer

9

8/10/2019 Phys Osc

19/51

2.4 Existing Products

that can generate information, run algorithms, or act in any way as an interme-diary between a performers controls and the variables of a sound generator.Theperformers controls in this case are controlled by the Boids algorithm runningon an Android tablet, with an exception being the accelerometer data, which isdetermined by the users movement. The tablet is the intermediary that controlsthe variables of my sound generator.

Phys-Osc takes the generative approach to mapping. Hunt and Wanderly

(2002) state, Mapping using neural networks can allow the designer to benetfrom the self-organising capabilities of the model.The Flock will act as the modelwith Separation, Alignment, and Cohesion driving each Boids acceleration pointsto new locations within the Flock. It is envisaged that Separation, Alignment,and Cohesion parameters will have dedicated sliders. This element of the GUI willutilise a one-to-many mapping strategy, with simple parameter changes resultingin directional changes in each Boids movement. Mapping strategies in the audioengine will involve positional data from each Boid being mapped to frequency andplayback position in the Boids corresponding Granular instrument. A one-to-onemapping is used to reinforce the synchronicity between both audio and visualdata streams.


2.4.1 Konkreet Performer

Konkreet Performer is closely related related to Phys-Osc in that it uses a physics

engine to control data that is sent over an OSC network to a host computer. Theperformance interface is designed to use the devices multitouch capability toshape the control data output. The program allows the user to alter shapes onscreen to dynamically control the type of OSC data sent to its local host. Theuser merely alters the existing indeterministic algorithm to shape the sound ex-perience accordingly.

10

8/10/2019 Phys Osc

20/51


It takes a non traditional approach to interface design. Historically controllersrelied on midi knobs in a skeuomorphic design that mimics real world constraints.It implements a physics engine that allows for inertia control of individual controlnodes. The inertia can be sped up to allow for smooth musical transitions. Itproved an inspiration to my design because it uses an unconventional approach tocontrol data. It provides the mechanisms that allow the user to interact with thesoftware using different gestural movements to shape the resulting data streamin new ways.

Figure 2.1: Konkreet Performer - OSC Performance interface with nodes thatare controlled by inertia and the users touch. [Source: ( Visnjic 2013)]

11

8/10/2019 Phys Osc

21/51


2.4.2 GBoids

Gboids is a Max MSP patch that uses an implementation of Craig ReynoldsBoids algorithm to drive a granular synthesis engine. Each agent represents agrain scrubbing an audio sample as it moves in a two dimensional space. TheBoids algorithm in this implementation, is written in Javascript. It is used toscrub areas of a pre-recorded sampled sound. The algorithm drives change to thesynthesis implementation, with its position changing parameters such as inertia,alignment and separation. Parameter controls can dene the number of agentsthat scrub the audio, size and velocity of those agents, and the classic Boids pa-rameters Separation, Alignment, and Cohesion. In this implementation the Boidsalgorithm also introduces Friction and Gravity parameters.

The important aspect of this application with regard to my own design wasthat it used the Boids algorithm to scrub a preloaded audio sample which en-ables the granulator to play the sample at different points both backwards andforwards in time. It allows for an interesting rhythmic variation to occur with

separate Boids playing the same sample with varying frequencies to create a denseanimated texture.

12

8/10/2019 Phys Osc

22/51


Figure 2.2: Gboids Max Msp Interface - A granular synthesizer thats con-trolled by a javascript implementation of the Boids algorithm, which scrubs theaudio sample. [Source: ( Angelo 2010)]

13

8/10/2019 Phys Osc

23/51

3

Overview of Technology

I chose to develop the application for the Android platform because of its opensource nature and all the tools I needed, including libraries, were freely available.Using this platform also allows me to have a wider reach of potential users withBusiness-Insider (2013) claiming the operating system has exceeded one billionactivations as of this year. Android is built upon the Java framework, which

I studied in rst year at college. We also used the open source programminglanguage Processing for animating visuals in second year. This library is basedon Java so it can be used as a library within the Eclipse environment. It haspre-built methods which simplies the animation process and cuts down on largeamounts of code needed to do simple functions.

3.1 Android Development Tools

The Android Developer tools provide a fully professional grade environment toconstruct Android Applications. Included in the software suite is the EclipseIDE, along with Googles Software Development Kit, and Emulator. Eclipse initself is a powerful code editor allowing one to build complex Java programs withfeatures like error protection and Lint warnings, which can prove invaluable to anovice Android programmer.

14

8/10/2019 Phys Osc

24/51

3.2 Processing

3.2 ProcessingProcessing is a visual programming framework developed in MIT during the2000s. It was conceived to enable artists to easily create interesting computationalmedia without having to learn the Java programming language from scratch. It isbased on the Java programming language and therefore can be easily integratedinto my Android development suite as a Java library.

3.2.1 oscP5

The application will use the Open Sound Control (OSC) messaging transfer pro-tocol to relay information over a wireless network. The reason for using thisprotocol is that it will enable me to use the substantial computing power of adesktop computer. This is necessary because of the limited processing power in-herent on mobile devices. There are other Android related issues such as bufferingaudio to take into account as well. After some initial research I discovered thatthe Android platform does not have API related to the Open Sound Control for-

mat.

It became clear that I needed to use a third-party library in order to sendthe data in the format I needed. After some initial research with the librariesLusidOSC and javaOSC, I chose the Oscp5 library from Andreas Schlegel (2011).It has added benets in that its code base is small and it can also query anIP address without having to call the Android Wi Manager within an activity.It was built for Processing so it can be used as a Java library alongside theProcessing core and the Ketai sensor library. Initial tests with sending sensordata and touchscreen activities proved successful.

3.2.2 controlP5

Controlp5 is a library created for Processing to enable the use of UI elements likesliders, knobs and check boxes. When using Processing as an activity, one majordisadvantage is that the program cannot access Androids UI elements such asthe action bar or menu buttons. Controlp5 can be used as a replacement. Its sole

15

8/10/2019 Phys Osc

25/51

3.3 Max MSP

purpose is to provide UI objects to enable GUI interactions to change parameterswithin the program. Control elements include Flock Speed, switching on and off sensors, and controlling Separation, Alignment, and Cohesion parameters.

3.2.3 Ketai

The Ketai Sensor library was created to work in Android mode in the ProcessingIDE. Ketai (2012) can be used to detect sensor activity on a mobile device. Thelibrary can detect data from mobile devices humidity, proximity, accelerometer,orientation and light sensors. The code base is light, enabling me to program anAndroids device sensors and use that data and send it over oscP5 in a few linesof code. The library allows me to program extra features into the app which willcontrol parameters in the Granular Synthesis Engine.

3.2.4 APWidgets

A major downside in using the Processing platform for Android Development is

that one does not get access to the Android UI framework. This doesnt helpapplications wanting to conform to Android best practice UI guidelines. Researchwas carried out as to a suitable alternative. APWidget provides all AndroidsUI Widgets like text boxes, and buttons in one simple and easy to use library.Im using a textedit box widget and a button to set a new IP address withinProcessing.

3.3 Max MSP

Max MSP is a graphical programming language created by Miller Puckette in IR-CAM. The Max paradigm can be described as a way of combining pre-designedbuilding blocks into congurations useful for real time computer music ( Puckette,2002). The program has proved an invaluable learning tool for computer musicand computer vision paradigms with its in-built Jitter objects. It was a naturalchoice for the granular synthesis implementation in that throughout the collegeterm it was used in teaching fundamental concepts in Amplitude Modulation,

16

8/10/2019 Phys Osc

26/51

3.4 CSound

Ring Modulation, and Frequency Modulation synthesis techniques.

The program really excels in its handling of multiple types of data be thatintegers, oats, UDP messages and can convert that data in to almost any otherkind. An example of this is how the program is used to read in the OSC datathats being transferred from the Android application and apply it through clevermapping strategies to the granular synthesis engine. The Max external Open-soundcontrol from CNMAT is used to read in the different message addresses and

data. The data from the CNMAT object allows me to map data to my soundengine within the Max environment and has many advantages over the in-builtUDP object allowing one to add time tags for certain functions.

It was decided that Csound would be a more viable alternative to Max MSPfor the audio engine. Max MSP can also be used to implement a granular syn-thesis engine, but its implementation is difficult and it can get quiet confusedvisually because of the sheer amount of objects it takes to construct the granularsynthesizer, especially an implementation that needs a great deal of polyphony.In order to make Max MSP adaptable enough for a granular synthesis implemen-tation a max external would need to be created in the C programming language,In the end Csound was chosen for the task.

3.4 CSound

CSound was chosen as my sound engine because of the history it has with Granu-lar Synthesis. Many opcodes have been written on the platform for the purpose of granularization of sound, these include Partikkle, Syncgrain, Granule and manyothers. CSound can be dened as a sound design, music synthesis and signalprocessing system, providing facilities for composition and performance over awide range of platforms( Csounds.com , 2013). The ability to use CSound onmany platforms such as iOS, Android, Linux, Windows and OSX makes it a ver-satile choice for rapid development of prototypes.

17

8/10/2019 Phys Osc

27/51

3.4 CSound

CSounds ability to interface directly with Max MSP through the use of anexternal has proved very useful to a multiplatform project such as PhysOsc. Itssound engine is capable of producing better sound quality than its counterpartMax MSP.

18

8/10/2019 Phys Osc

28/51

4

Implementation

4.1 Early Android Prototypes

The rst steps in this project trace back to the summer of 2012 when I was tryingto get the Visual Language Processing, which is based on Java, to work withinthe Android Developer tools as a library. Processings own IDE offers an Android

Mode, but this does not allow for extensive modication of the Android servicesavailable in the Eclipse IDE. My goal at this time was to use Processing in com-bination with the Android SDK to create the animations and UI for the look andfeel of the application. I found Processings forum very benecial and gained theknowledge there on how to run Processing as a library. This involves nding theprocessing-core.jar le in Processing application and adding it to the build pathof your Android Application.

At the beginning of my project I wanted to implement the sound synthesison the mobile device itself. I quickly learned that Granular Synthesis is veryprocessor intensive. Therefore, a mobile devices limited CPU might cause issueswhen running intensive patches. Roads (2001) states If n is the number of pa-rameters per grain, and d is the density of grains per second, it takes n times dparameter values to specify one second of sound. Since n is usually greater thanten and d can exceed one thousand, it is clear that a global unit of organizationis necessary for practical work. Each type of Granular Synthesis organizes the

19

8/10/2019 Phys Osc

29/51


grains differently according to different algorithms.

After consultation with my advisor, we decided that a better option for myproject would be to build the Granular Synthesis engine in Max Msp whilst let-ting OSC (Open Sound Control) handle the data transmission from my AndroidApplication to the desktop Granular Patch. Androids own developer tools doesnot include an OSC library so embedding the oscp5 library is a prerequisite.

4.1.1 Prototype 1My rst Android prototype began development in September. The rst task wasto build a multi-page application that could navigate to a page by selecting abutton. I created the main screen, called an Activity which in turn would triggertwo further Activities. One screen for the Boids algorithm and another for OSCSettings. I created two buttons on the home screen which allows for the user toclick into another aspect of the program. These buttons trigger a chosen Activitythrough the use of intents. The Android Developer website denes intents as a

facility for performing late runtime binding between the code in different appli-cations. Its most signicant use is in the launching of activities. It is basicallya passive data structure holding an abstract description of an action to be per-formed( Google, 2013).

In Android 4.0 and above the menu structure has changed. The UI guidelinesrequire an implementation of an action bar at the top of the application screen.This housed all top level functions such as a Done button which saves data upon

exit and an option to get back to the home page. The return to home page buttonis used as the application icon ( Google, 2013). The Android Developer websitestates Icons need to be supplied in different sizes to support multiple screendensities. Google have implemented it in this way so that a tablet or phone canchoose which icons resolution suits the screen size best. The early prototype iconswere created with the open-source picture editor Gimp.

20

8/10/2019 Phys Osc

30/51


The next process of the prototype design required me to build an OSC Settingsscreen which would store the data input by the user and remember those settingswhen the user returned to the settings screen. Android handles its layout in theXML format which has some similarities with CSS. I used a table to constructthe menu with clickable text boxes that allow for the input of numerical data.

Figure 4.1: Android OSC Settings - Screenshot from the OSC Settings menu,that allows the user to congure preferences.

Another important function of the settings screen was to allow for the returnof the local IP address. This is important in that the OSC host, which is MaxMSP in my case, needs to know what IP to send and receive data on. A popuptoast message can be used to display this information, but I plan on returning

21

8/10/2019 Phys Osc

31/51


this data to the local IP text box from the menu in a future revision. This ensuresthe user does not have to use a third party tool to ascertain their local addresson the network.

The in-built Android API Wi Info was used to gather this information. Whenthis data was displayed via Toast message it was displayed in Little Endian for-mat, this format then needed to be converted to a readable one for ease of use.After some initial research I stumbled upon a blog post by Damien Flannery

(2010) which detailed an efficient way to translate the returned Wi Info datainto its component string IP address. A requirement of the Android operatingsystem is that permissions are required in the xml le of the program. In thiscase, main.xml was altered to allow it to access data from the network.

4.1.2 Prototype 2

The next requirement needed to be the visualization of the Boids algorithm. Iused Processing as a library within the Eclipse environment and added this to the

applications build path ( Doyle, 2013). When an Android project initializes anactivity it extends the Main Activity class. When using Processing you need toextend the Papplet class so that the Processing library can communicate with thebase Java code and understand the methods being called. The next step of theprocess required me to to use import statements for the libraries that I intendedon using. In the PhysOsc program, I implement Oscp5 for Wi, Processing-Corefor visuals, Controlp5 for UI elements, and the Ketai library for grabbing sen-sor data. I chose to use an implementation of the Boids algorithm by Daniel

Shiffman Foundation (2013) which in turn is an implementation of the originalBoids algorithm ( Reynolds , 1987). When the algorithm was rst imported intomy Eclipse workspace, I needed to alter the algorithm so that it would compilein a correct manner.

Within the Processing IDE, methods generally do not need to be public. Mostmethods start with the void declaration which means the method does not returnany data. In Android all of these methods need to be modied to include public

22

8/10/2019 Phys Osc

32/51


Figure 4.2: Boids Visualisation - An early implementation of the Boids algo-rithm with the Processing library.

23

8/10/2019 Phys Osc

33/51

4.2 Final Android Implementation

methods so that different parts of the program can access those methods, numbersand data types also needed to cast, so that, Eclipse could understand what typeof data it was handling.

4.2 Final Android Implementation

In order to run the Processing library as an all encompassing Android applica-tion, extra libraries were needed. To this end, Controlp5 was used to implement

UI features such as text, sliders, and checkboxes. They allow for the Boids al-gorithm parameters to be modied by touching the appropriate area on screen.The graphics were congured to grayscale to ensure the colour scheme remainedconsistent with the desktop application. The Ketai library was used to grab ac-celerometer info. When the sensor is initialised it sends that data to CSound andis mapped to global reverb frequency.

4.3 Audio Engine Implementation

An active link between the mobile application and desktop application was estab-lished to change granular synthesis parameters in real-time. To this end I usedMax MSP as an OSC hub to route information from the Android applicationin real-time to CSound. All granular synthesis implementations were created inCSound.

4.3.1 Max MSP

Max MSP was chosen as the intermediary between the visual engine of the An-droid application and the sound synthesis engine in CSound. It allowed for con-struction of UI features and acts as a frontend for my CSound program. Itassumes the important function of parsing the OSC packets received from theAndroid application into K-rate CSound variables. Max also provides UI func-tions to act as a transport bar for the CSound score. It allows for the starting,stopping, resetting, and the recording of CSounds audio output. Its UI featuresalso provide a visual feedback mechanism from the resulting CSound audio signal.

24

8/10/2019 Phys Osc

34/51

4.4 Mapping

4.3.2 CSound

Csound was chosen as the synthesis engine because of its long association withGranular Synthesis methods. Opcodes are the basic building blocks of CSoundand they provide many uses such as time based effects, and signal generators.Many granular opcodes exist such as Partikkel, Granule, and the Grain family.For the purposes of my research I chose to use Syncrain. Syncgrain employs asynchronous granular method and is adaptable and extendable because most of its parameters allow for the use of K-rate variables meaning that parameters canchange in real-time. Its also not processor intensive, allowing for the stacking of 20 such Syncgrain instruments, allowing them to be operated simultaneously.

Each Boid has a corresponding granular instrument created in CSound. Allinstruments preload the same source sample into an ftable. A particularly shortsample of the Spanish phoneme U was chosen in order to create an interestingrhythmic dynamic in the resulting audio output. A Hanning windowing functionwas chosen and implemented in the CSound score le and global reverb was

applied to overall audio output with individual send levels from each CSoundinstrument. Accelerometer data from the host tablet is mapped to control theglobal CSound reverb cut off rate, this facilitates the creation of ltering effectswhen the tablet is moved in 3D space.

4.4 Mapping

Information from each Boids on screen location is sent as data packets over a

wireless network to a host computer. Two separate OSC message streams areemployed, one for the y information of each Boid and one for the x information.OSC message streams are received by Max and translated into readable informa-tion for the purposes of mapping to sonic parameters. The Max MSP externalOSC-Route deciphers the messages into oating point and string information.String information is then converted to a symbol and back into an integer inorder to separate each Boids information stream and trigger a bang to send itslocation data to CSound as a K-rate variable.

25

8/10/2019 Phys Osc

35/51

4.4 Mapping

4.4.1 Strategies

When a Flock is born each Flock member accelerates away from each other ina multitude of directions. It was decided that from a perception perspectivepitch would resonate most with movement on the y axis. Although a one-to-onemapping can often yield limited results in this case it helped initialise audiovisualsynchrony between the visual and sonic algorithms. Often when the Flock is leftin a static state the entire Flock movement appears to move along the x axisand for this reason it was decided that this data set could be best utilised fortraversing the sample moving forward and backward in time from a range of -1 to1. X data is unpacked from the OSC message and reads in the range of 0 to 1280which then needs to be scaled from -1 - 1 to ensure CSounds K-Rate variablereceives the correct data.

26

8/10/2019 Phys Osc

36/51

5

Conclusions and FutureDirections

5.1 Summary

The aim of the project was to develop a sound synthesizer based on the Boids

algorithm. Detailed background research into both the Boids algorithm and gran-ular synthesis techniques was carried out as well as research into the necessarytools and processes required to complete a multiplatform project such as this.A number of different approaches were investigated for the android applicationand audio engine before a nal product was decided upon.

5.2 Conclusions

There were many reasons to undertake a project of this nature. I saw this projectas the perfect vehicle to show my knowledge of the curriculum taught through-out the four years. Programming concepts in Java, Max MSP, Processing, andCSound were of great benet throughout the curriculum. The aim was to takethe methodologies thaught forward to produce a product that posed many chal-lenges both from a coding and conceptual point of view.

Indeterministic algorithms such as Boids provide a rich source of data that can

27

8/10/2019 Phys Osc

37/51

5.3 Future Work

be used to create compelling sonic narratives. PhysOsc applies this methodologyto control a granular synthesis implementation so that the user doesnt have tochange each of the many parameters required to create the sonic output. Thishas many advantages in that the user of the software has the option to use amacroscopic approach rather than microscopic.

The higher level of control allows the user to concentrate on the creativeaspects of music creation rather than getting bogged down at the microscopic level

with the vast array of parameter changes needed to create a dense granular sound.In this regard, the point and click paradigm of music creation with granularsynthesis can be seen as a counter intuitive process. A conscious decision wasmade at the start of the development cycle to keep the sound engine and graphicaluser interface separate allowing the user to concentrate on moving shapes todifferent locations on screen, which takes the focus off the underlying granularsynthesis process.

5.3 Future WorkUltimately the android application could be rened further with many new fea-tures added. Accelerometer data can be easily obtained using the Ketai Javalibrary, this data could be further rened and scaled with x, y, and z controllingcohesion, separation and alignment parameters of the Boids algorithm. Furtherautomatization of parameters could be utilised through various other sensors suchas the promixity sensor for grain size.

The sonic output from the granular implementation would benet from theuse of surround sound. This would allow the movement of the Flock to be bettersonically realized in a three dimensional space. It would also allow for the signalof each Boid to have better separation so that panning movements would becomemore apparent in a 360 degree listening space. The use of an attractor with theBoids algorithm could function as a ock positioner within the 360 degree eldadding another level of control to the android application.

28

8/10/2019 Phys Osc

38/51

5.3 Future Work

In a future revision I plan to use Javascript in Max MSP to actively createand delete audio channels when Boids are added and subtracted in the Androidapplication. This would allow the user to have control over how many soundobjects are on screen.

29

8/10/2019 Phys Osc

39/51

Appendix A

Nexus 7 Screenshot

Figure 1: Nexus 7 Tablet - PhysOsc on a 7 inch Tablet screen.

30

8/10/2019 Phys Osc

40/51

Nexus 4 Screenshot

Figure 2: Nexus 4 Phone - PhysOsc on a 4.65 inch Mobile Screen. The Pro-cessing library does not allow for the loading of multiple XML les for layout, so adesign that complements both tablet and phone needed to be implemented.

31

8/10/2019 Phys Osc

41/51

Appendix B

Java Implementation of the Boids Algorithm

ThirdActivity.javapackage com. example . physo sc ;

// L i b r a r y I m p o r ts

impor t j a v a . u t i l . A r r a y L i s t ;impor t k e t a i . s e n s o r s . K e t a i S e n s o r ;impor t oscP5 . ;impor t netP5 . NetAddress ;impor t p r o c e s s i n g . c o r e . ;impor t c o n t r o l P 5 . ;impor t a n d r o i d . u t i l . L og ;impor t apwidgets . ;

// Ma in A c t i v i t y

p u bl i c c l a s s T h i r d A c t i v i t y e x t e n d s PApplet{

/ / O b je c t D e c l a r a t i o n sOscP5 oscP5 ;K e t a i Se n s o r s e n s o r ;C o n tr o l P5 c o n t r o l P 5 ;N e t Ad d r es s r e m o t e L o c a t i o n ;F l oc k f l o c k ;PFont p ;S t r i n g i p= 1 9 2 . 1 6 8 . 4 3 . 1 4 1 ; / /My l a p t o p s a d d r e s s o n t h e r o u t e rAPEdi tText tex tFi e l d ;APWidgetConta iner widgetCo nta iner ;APButton button1 ;

/ / G l ob al Va r i a bl e si n t c o h F a c to r = 8 ;i n t s e p F a c t o r = 1 2 ;i n t a l l i gn F a c to r = 7 ;i n t v i s i b l eB o i d s = 2 0 ;f l o a t a c c e l e r o m e t e r X , a c c e l e r o m e t e r Y , a c c e l e r o m e t e r Z ;b o o l e a n smooth = t r u e ;

b o o l e a n a c c e l e r = t r u e ;b o o l e a n Va l i d I P = t r u e ;

// C re at in g o f t he f l o c k@SuppressWarnings( d e p r e c a t i o n )p u b l i c v o id s e t u p ( ){

/ / S c r e en d i m e ns i o n ss i z e (7 2 0 , 1 2 8 0) ;

32

8/10/2019 Phys Osc

42/51

Appendix

// S et t h i s s o t he s ke t ch won t r e s e t a s t he p hone i s r o ta t ed :or i e n t a t i o n (LANDSCAPE) ;

/ / S k e t c h F ra me R at ef rameRate(45) ;smooth( ) ;/ /noSt roke ( ) ;f i l l (2 55) ;t e x t S i z e ( 2 8 ) ;

/ / A dd in g A n dr o i d C o re Wi dg e ts/ / T h es e a r e n ot a v a i l a b l e w h il e u s i ng t h e PAp pl et , im u s i ng a p wi d ge t s a s a w or k

aroundw i d g e t C o n t a i n e r = new APWidgetContainer( t h i s ) ;t e x t F i e l d = new APEdi tText ( 775 ,43 ,250 ,80) ;b u t t o n1 = new APButton(1 020 ,43 ,13 0 ,80 , h o s t ) ;widgetC onta ine r . addWidget ( tex t Fie ld ) ;

widgetC onta ine r . addWidget ( but ton1) ;

// C a l li n g a n i n s ta n c e o f t he F lo ck C l as sf l o c k = new Flock ( ) ;// Add an i n i t i a l s e t o f b oi d s i n t o t h e s y st emf o r ( i n t i = 0 ; i < v i s i b l e B o i d s ; i ++){

f l oc k . addBoid( new B oi d ( w i dt h / 2 , h e i g h t / 2 , i ) ) ;}

/ / s t a r t o sc P5 :o s c P5 = new OscP5( t h i s , 8 0 0 0) ; / /App l i s t e n e r l i s t e n on p or t 8 00 0/ / 1 9 2 . 1 6 8. 1 . 1 9 i s my l a p t op i p 4 a d d re s s / / 8 00 1 i s t h e p o r t n umber Max i s l i s t e n i n g o nr e m o t e L o c a t i o n = new N e t A d d r es s ( i p , 8 0 0 1 ) ;

s e n s o r = new K e t a i S e n s o r ( t h i s ) ; / / Tur n o n K e t a is e n s o r . e n a b l e A c c e l e r o m e t e r ( ) ; / / I n i t i a l i z e A cc el er om et er

/ / C r e at e C o n t ro l p 5 GUIc o n t r ol P 5 = new Contro lP5( t h i s ) ;/ / c h an ge t h e d e f a u l t f o n t t o Ver da naP Fo nt p = c r e a t e F o n t ( Verdana , 2 4 ) ;c o n t r o l P 5 . s e t C o n t r o l F o n t ( p ) ;c o n t r o l P 5 . s e t C o l o r L a b e l ( c o l o r ( 0 ) ) ;

c o n t r o l P 5 . s e t C o l o r F o r e g r o u n d ( c o l o r ( 2 5 5 ) ) ;cont ro lP5 . se tColorBackground( co lor (0) ) ;c o n t r o l P 5 . s e t C o l o r Va l u e ( c o l o r ( 0 ) ) ;c o n t r o l P 5 . s e t C o l o r A c t i v e ( c o l o r ( 2 2 4 ) ) ;

c o n t r o l P 5 . a d d S l i d e r ( s e t C o h F a c t o r ,0 ,20 , cohFactor ,50 , he ight 4 4 0 , 5 0 , 4 0 0 ) . s e t L a b e l ( Cohes ion ) ;

c o n t r o l P 5 . a d d S l i d e r ( s e t S e p F a c t o r ,0 ,20 , sepFactor , 200 , he ight 4 4 0 , 5 0 , 4 0 0 ) . s e t L a b e l ( S e p a r a t i o n ) ;

c o n t r o l P 5 . a d d S l i d e r ( s e t A l l i g n F a c t o r , 0 , 2 0 , a l l i g n F a c t o r , 3 5 0 , h e i g ht 4 4 0 , 5 0 , 4 0 0 ) .s e t L a b e l ( Al ignment ) ;

c o n t r o l P 5 . a d d S l i d e r ( se tFrameRate , 1 , 1 0 0 , 4 5 , 5 0 0 , h e i g h t 4 4 0 , 5 0 , 4 0 0 ) . s e t L a b e l ( Framera te ) ;

cont ro lP5 . addToggle( t o g g l e A c c e l e r , t rue , 5 0 , 1 5 5 , 1 2 0 , 5 0 ) . s e t L a b e l ( S en d S e n s o r ) ;cont ro lP5 . addToggle( toggleSmooth , t rue , 5 0 , 2 4 0 , 5 0 , 5 0 ) . s e t L a b e l ( Smooth ) ;

}

/ / S e t t i ng d at a f rom c o n tr o l p5 U I t o g l o ba l v a r i a bl e svoid se tFrameRate( i n t r a t e ){

f rameRate( ra te ) ;}

void s e t A l l i g n F a c t o r ( i n t f a c t o r ){

a l l i g n F a c t o r = f a c t o r ;

33

8/10/2019 Phys Osc

43/51

Appendix

}

v o i d s e t S e p F a c t o r ( i n t f a c t o r ){

s e p F a ct o r = f a c t o r ;}

v o i d s e t C o h F a c t o r ( i n t f a c t o r ){

c o h Fa c t or = f a c t o r ;}/ / S c al e i n t e ge r i np ut i n to f l o a tf l o a t s c a l e ( i n t f a c t o r ){

f l o a t s c a le d = ( f l o a t ) ( f a c t o r ) / 1 0 ;r e t u r n s c a l e d ;

}

/ / On / O ff S w i t c h f o r S mo ot h A n i m at i onv o i d toggleSmooth ( ){

i f (smooth == t r u e ){

smooth = f a l s e ;noSmooth() ;

}e l s e{

smooth = t r u e ;smooth( ) ;

}}

/ /On / O f f S w it c h f o r A c c e l e ro m e t e rv o i d t o g g l e A c c e l e r ( )

{i f ( a c c e l e r == f a l s e ){

a c c e l e r = t r u e ;s e n s o r . s t a r t ( ) ;

}e l s e{

a c c e l e r = f a l s e ;s e n s o r . s t o p ( ) ;

}}

/ / C l i c k in g i p a d dr e ss Wi dge t t o s t o r e i n f op u b l i c v o id onCl ickWidget (APWidget widget ){

i f ( w i d g e t == b u t t o n1 ){

i p = t e x t F i e l d . g e t Te xt ( ) ;r e m o t e L o c a t i on = new N e t A d d re s s ( i p , 8 0 0 1 ) ;

Va l i d I P = t r u e ;}

}

/ / Draw B oi ds t o t h e s c r e e np u b l i c v o id draw(){

background( 128 ,128 ,128) ;w i d g e t C o n t a i n e r . s h ow ( ) ;r e m o t e L o c a t i o n = new N e t Ad d r es s ( i p , 8 0 0 1 ) ;f l oc k . run ( ) ;

f i l l ( c o l o r ( 0 , 0 , 0 ) ) ;t e x t (

X : + n f p ( a c c el e ro me t er X , 1 , 3 ) + \ n +Y: + n f p ( a c c el e ro me t er Y , 1 , 3 ) + \ n +

34

8/10/2019 Phys Osc

44/51

Z : + n fp ( a c ce l er o me t er Z , 1 , 3 ) , 5 0 , 5 0 , w id th , h e i gh t );

O s cM e ss a ge a c c e l x = new OscMessage( / a c c e l x ) ;a c c e l x . a dd ( a c c e l e r o m e t e r X ) ;a c c e l x . a d d ( A c c e l e r o m e t e r X ) ;oscP5 . send( acce lx , remoteLoca t ion ) ;

O s cM e ss a ge a c c e l y = new OscMessage( / a c c e l y ) ;a c c e l y . a dd ( a c c e l e r o m e t e r Y ) ;a c c e l y . a d d ( A c c e l e r o m e t e r Y ) ;oscP5 . send( acce ly , remoteLoca t ion ) ;

O sc Me ss ag e a c c e l z = new OscMessage( / a c c e l z ) ;a c c e l z . a dd ( a c c e l e r o m e t e r Z ) ;a c c e l z . a dd ( A c c e l e r o m e t e r Z ) ;o s c P5 . s e n d ( a c c e l z , r e m o t e L o c a t i o n ) ;

}

p u b l i c v o id mousePressed ( ){

OscMessage myMessage = new OscMessage( / t e s t ) ;myMessage . add( r e c e i v i ng l ou d a nd c l e a r : ) ) ;oscP5 . send(myMessage , remoteLocat ion ) ;f l oc k . addBoid( new Boid( mouseX, mouseY, 1)) ;

}

p u b l i c v o id o n A c c e l e r o m e t e r E v e n t ( f l o a t x , f l o a t y , f l o a t z ){

a c c e l e r o m e t e r X = x ;a c c e l e r o m e t e r Y = y ;a c c e l e r o m e te r Z = z ;

}

// The B o i d s C l a s s c r e a t e d b y D a n i e l S h if f ma n

/ / P hyOs c F u l l J av a C od e i s a v a i l a b l e o n t h e a t t a ch e d DVD

35

8/10/2019 Phys Osc

45/51

Appendix C

Max MSP GUI

Figure 3: Max MSP Router - Max patch used as an OSC hub to receive

incoming messages and send them to CSound

36

8/10/2019 Phys Osc

46/51

Appendix D

Granular Implementation in CSound

SyncGrain2.csd< CsoundSynthes izer >< CsOptions >; S e l e ct a ud io / mi di f l a g s h er e a c co r di n g t o p la tf or m

o da c ; ; ; r e a l t i m e a ud i o o ut; o s y n c g r a i n . w av W ; ; ; f o r f i l e o u t p ut a ny p l a t f o r m

< /CsOptions >< CsIns t ruments >

s r = 4 4 1 00ksmps = 320 db fs = 1n c h n l s = 2

c h n k b o i d 0 x , 1c h n k b o i d 0 y , 1c h n k b o i d 1 x , 1c h n k b o i d 1 y , 1c h n k b o i d 2 x , 1c h n k b o i d 2 y , 1c h n k b o i d 3 x , 1c h n k b o i d 3 y , 1c h n k b o i d 4 x , 1hn k b o i d 4 y , 1

c h n k a c c e l x , 1

; Zak I n i t i a l i z a t i o n 1 a r a t e and o ne k r a t e v a r i ab l ez a ki n it 1 , 1

i n s t r 1

i ol ap s = 2i g r s i z e = 0 . 10

k fr eq = i ol a ps / i g r s iz ekps = 1/ i ol ap s

k s t r c h ng e t b o i d 0 x g k s t r c h n ge t b o i d 0 x g k s t r = . 3 / t i m e s c a l e /k en v a d s r p 3 . 1 , p 3 . 3 , . 4 , p3 . 4k p i t c h c h n ge t b o i d 0 y g k p i t ch c h n ge t b o i d 0 y g kp i tc h = p4 / p i t c h s c a l e /

37

8/10/2019 Phys Osc

47/51

Appendix

a si g s yn c gr ai n 0 .1 ke nv , k f re q , k p it c h , i g r s i z e , k ps k st r , 1 , 2 , i o l ap so u ts a s i g , a s i g

i Rv bS en dA mt = 0 . 3 ; r e v e r b s e n d a m ou nt ( 0 1); w r i t e t o z ak a ud i o c h an n el 1 w it h m ix in g

zawm as i g iRvbSendAmt , 1

endin

i n s t r 2

i ol ap s = 2i g r s i z e = 0 . 10






endin

i n s t r 3

i ol ap s = 2i g r s i z e = 0 . 10






endin

i n s t r 4

i ol ap s = 2i g r s i z e = 0 . 10


k s t r c h ng e t b o i d 3 x g k s t r c h n ge t b o i d 3 x k s t r = . 3 / t i m e s c a l e /

38

8/10/2019 Phys Osc

48/51

Appendix

k en v a d s r p 3 . 1 , p 3 . 3 , . 4 , p3 . 4k p i t c h c h n ge t b o i d 3 y g k p i t ch c h n ge t b o i d 3 y g kp i tc h = p4 / p i t c h s c a l e /




endin

i n s t r 9 9 ; R ev er b A l wa ys On

a I nS i g z a r 1 ; r ea d f i r s t z ak a ud io c ha nn el

k Fb lv l i n i t 0 . 5 5 ; f ee db ac k l e v e l i . e . r e v e r b t i mek Fc o c h n g e t a c c e l x gkFco ch nget a c c e l x gkFco i n i t 6 00 0 ; c u t o f f f r e q . o f a f i l t e r w it h in t he r ev e rbaRvbL , aRvbR r e v e r b s c a I n S i g , a I n S i g , k F b l vl , k Fc o

o u t s aRvbL , aRvbR ; s e nd a u d io t o o u t pu t sz a cl 0 , 1 ; c l e ar z ak a ud io c ha nn el s

endin

< /CsIns t ruments >< CsScore >

f 1 0 0 1 U. wav 0 0 0 ; D ef er re d t ab l e f o r s o u r c e w av ef or mf 2 0 8 19 2 2 0 2 1 ; H an ni ng f u n c t io n f o r G r a i n E n v el o p e

i 1 0 2 0 00 1i 2 0 2 0 00 1i 3 0 2 0 00 1

i 4 0 2 0 00 1i 9 9 0 2 01 0e< /CsScore >< /CsoundSynthes izer >< MacOptions >Ve r s i on : 3Render : RealA sk : YesF u n ct i o n s : i o O b j e c tLis t i ng : WindowWindowBounds: 1072 9 24 5 7 2 4 2 4CurrentView : ioIOViewEdit : OnOpt ions : b128 A s m167 R< /MacOptions >< MacGUI >ioView background { 3 2 12 5 , 4 1 6 34 , 4 11 2 0 }i o S l i d e r { 2 66 , 7 } { 2 0 , 98 } 0 . 0 0 0 0 0 0 1 . 0 0 0 00 0 0 . 1 7 3 46 9 ampi o S l i d e r { 1 0 , 29 } { 2 39 , 2 2 } 1 0 0 . 00 0 0 0 0 1 0 0 0 .0 0 0 0 00 2 5 8 . 15 8 9 9 6 f r e qioGraph { 8 , 1 12 } { 2 65 , 1 16 } t a b l e 0 . 0 0 00 0 0 1 . 0 0 0 00 0i o L i s t i n g { 2 79 , 1 12 } { 2 6 6 , 2 66 }ioText { 2 9 3 , 4 4 } { 4 1 , 24 } l a b e l 0 . 00 0 00 0 0 . 00 1 00 l e f t Lucida Grande 8 { 0 , 0 , 0 } { 6 5 2 8 0 ,

6 5 2 80 , 6 5 28 0 } background noborder Amp:ioText { 3 3 3 , 4 4 } { 7 0 , 24 } d i s p l a y 0 . 0 0 00 0 0 0 . 0 0 1 00 amp l e f t Lucida Grande 8 { 0 , 0 , 0 }

{ 6 5 28 0 , 6 5 2 80 , 6 52 8 0 } b a ck g r ou n d n o b o r d er 0 . 1 8 3 7ioText { 6 6 , 5 7 } { 4 1 , 2 4 } l a b e l 0 . 00 0 00 0 0 . 00 1 00 l e f t Lucida Grande 8 { 0 , 0 , 0 } { 6 5 2 8 0 ,

6 5 2 80 , 6 5 28 0 } b a c kg r o un d n o b o r d e r F r eq :ioText { 1 0 6 , 5 7 } { 6 9 , 24 } d i s p l a y 0 . 0 0 00 0 0 0 . 0 0 1 00 f r e q l e f t Lucida Grande 8 { 0 , 0 , 0 }

{ 6 5 28 0 , 6 5 2 80 , 6 52 8 0 } b a ck g r ou n d n o b o r d er 2 6 1 . 9 2 4 7ioText { 4 25 , 6 } { 1 2 0 , 1 00 } l a b e l 0 . 00 0 00 0 0 . 0 01 0 0 l e f t Lucida Grande 8 { 0 , 0 , 0 } { 6 5 2 8 0 ,

6 5 2 80 , 6 5 28 0 } nobackground borderioText { 4 4 9 , 6 8 } { 7 8 , 24 } d i s p l a y 0 . 0 0 00 0 0 0 . 0 0 1 00 f r e q s w e e p c e n t e r DejaVu Sans 8 { 0 , 0 ,

0 } { 1 4 08 0 , 3 1 2 32 , 2 9 69 6 } b a ck g ro u n d b o r d e r 9 9 9 . 6 7 6 9ioBut ton { 4 35 , 2 4 } { 1 00 , 3 0 } e v e n t 1 . 0 0 00 0 0 B u t to n 1 S we ep / i 1 0 10

39

8/10/2019 Phys Osc

49/51

ioGraph { 8 , 2 33 } { 2 66 , 1 47 } s c o p e 2 . 0 0 00 0 0 1.000000< /MacGUI >

< EventPanel name= tempo= 6 0 . 0 0 0 0 0 0 0 0 loop= 8 . 0 0 0 0 0 0 0 0 x= 0 y= 0 width= 596 h e i g h t = 322>

< /EventPanel >

40

8/10/2019 Phys Osc

50/51

References

Angelo, T. (2010), Gboids, in www.cycling74.com [online], available: http://bit.ly/1hanw3Ul [accessed: 5 December 2013] .

Brinkman, P. (2012), Making Musical Apps: Real-time Audio Synthesis on Android and iOS , OReilly Media.

Business-Insider (2013), Chart Of The Day [online], available: http://read.bi/1ixMK1N [accessed: 4 September 2013].

Chadabe, J. (2002), The limitations of mapping as a structural descriptive in electronicinstruments, in Proceedings of the 2002 Conference on New Interfaces for MusicalExpression, NIME 02, National University of Singapore, Singapore, pp. 15.

Csounds.com (2013), Granular Synthesis [online], available: http://bit.ly/Pt7FGB[accessed: 20 December 2013].

Doyle, J. (2013), Using Processing In Eclipse [online], available: http://bit.ly/11g8lB9[accessed: 5 August 2013].

Flannery, D. (2010), Obtaining you ip address on Android [online], available: http://bit.ly/dxIQLJ [accessed: 21 October 2013].

Foundation, P. (2013), Examples [online], available: http://bit.ly/1nLJwX8 [accessed:14 September 2013].

Gabor, D. (1946), Theory of Communication, The Journal of the Institution Of Elec-trical Engineers 3(93), 429457.

Google (2013), Design [online], available: http://bit.ly/yROIVW [accessed: 23September 2013].

41
http://bit.ly/1hanw3Ulhttp://bit.ly/1hanw3Ulhttp://read.bi/1ixMK1Nhttp://read.bi/1ixMK1Nhttp://bit.ly/Pt7FGBhttp://bit.ly/11g8lB9http://bit.ly/dxIQLJhttp://bit.ly/dxIQLJhttp://bit.ly/1nLJwX8http://bit.ly/yROIVWhttp://bit.ly/yROIVWhttp://bit.ly/1nLJwX8http://bit.ly/dxIQLJhttp://bit.ly/dxIQLJhttp://bit.ly/11g8lB9http://bit.ly/Pt7FGBhttp://read.bi/1ixMK1Nhttp://read.bi/1ixMK1Nhttp://bit.ly/1hanw3Ulhttp://bit.ly/1hanw3Ul

8/10/2019 Phys Osc

51/51

REFERENCES

Hunt, A. and Wanderly, M. (2002), Mapping performance parameters to synthesisengines, Organised Sound 2(7), 97108.

Ketai (2012), Ketai [online], available: http://code.google.com/p/ketai/ [accessed:16 November 2013].

Kirn, P. (2013), Why mobile low latency is hard [online], available: http://bit.ly/MxNaXd [accessed: 5 August 2013].

Opie, T. (2003), Creation of a Real Time Granular Synthesis for Live Performance,

Masters thesis, Queensland University of Technology, Australia.

Puckette, M. (2002), Max at seventeen, Computer Music Journal 4(26), 3143.

Reynolds, C. (1987), Flocks, Herds, and Schools: A Distributed Behavioural Model,Computer Graphics 4(21), 2534.

Roads, C. (2001), Microsound , MIT Press.

Scavone, G. (2013), Granular Synthesis [online], available: http://bit.ly/Pt7FGB[accessed: 20 December 2013].

Schlegel, A. (2011), Libraries [online], available: http://bit.ly/PpHKPW [accessed:14 November 2013].

Shiffman, D. (2012), The Nature of Code Simulating Natural Systems with Processing ,Self Published.

Truax, B. (1990), Composing with Real-Time Granular Sound, Perspectives of New Music 2(28), 120134.

Visnjic, F. (2013), Konkreet Performer, in www.creativeapplications.net [online], avail-able: http://bit.ly/1nMpKuNl [accessed: 13 November 2013] .

Xenakis, I. (1992), Formalised Music: thought and mathematics in composition , Pen-dragon Press.
http://code.google.com/p/ketai/http://bit.ly/MxNaXdhttp://bit.ly/MxNaXdhttp://bit.ly/Pt7FGBhttp://bit.ly/PpHKPWhttp://bit.ly/1nMpKuNlhttp://bit.ly/1nMpKuNlhttp://bit.ly/PpHKPWhttp://bit.ly/Pt7FGBhttp://bit.ly/MxNaXdhttp://bit.ly/MxNaXdhttp://code.google.com/p/ketai/

Phys Osc

Documents

Transcript of Phys Osc