Proceedings of the International Conference on New Interfaces for Musical Expression, Baton Rouge, LA, USA, May 31-June 3, 2015

Orchestrating Your Cloud-

Abram Hindle Department of Computing Science University of Alberta Edmonton, Alberta, Canada [email protected]

ABSTRACT often have reasonable bandwidth; performers who exploit Cloud computing potentially ushers in a new era of com- cloud services avoid bringing lots of computer equipment puter music performance with exceptionally large computer to a performance venue [10]; networked computers enabled music instruments consisting of 10s to 100s of virtual ma- centralized and decentralized collaborative instruments [12]. chines which we propose to call a ‘cloud-orchestra’. Cloud The cloud has been leveraged for perfor- computing allows for the rapid provisioning of resources, mance [10]. While the authors succeed at a demoing the but to deploy such a complicated and interconnected net- feasibility of cloud instruments, they also demonstrated the work of software in the cloud requires a lot complexity and frustration of organizing and orchestrating of manual work, system administration knowledge, and de- synthesizers in the cloud. Organizing these synthesizers re- veloper/operator skills. This is a barrier to computer mu- quires much knowledge about cloud computers, networking, sicians whose goal is to produce and perform music, and systems administration, Unix-like systems, shell scripting not to administer 100s of computers. This work discusses and programming. Essentially such a prerequisite knowl- the issues facing cloud-orchestra deployment and o↵ers an edge is a large barrier to the adoption of cloud computing abstract solution and a concrete implementation. The ab- for computer music performance. stract solution is to generate cloud-orchestra deployment Requiring a computer musician to play the role of sys- plans by allowing computer musicians to model their net- tem administrators or developer/operators is too high a work of synthesizers and to describe their resources. A barrier. This work seeks to enable the generation and de- model optimizer will compute near-optimal deployment plans ployment of a cloud-orchestra. We define a cloud-orchestra to synchronize, deploy, and orchestrate the start-up of a as a network of software synthesizers deployed to multiple complex network of synthesizers deployed to many comput- networked computers (usually on a cloud). We envisage ers. This model driven development approach frees com- cloud- to be composed of multiple virtual ma- puter musicians from much of the hassle of deployment and chines running software synthesizers connected together by allocation. Computer musicians can focus on the configura- network audio links. tion of musical components and leave the resource allocation Deployment is an ardous task that requires much net- up to the modelling software to optimize. working, programming, and shell scripting knowledge – un- less it is automated. Systems can be built that take both a model of a cloud-orchestra and a list of resources as input to Author Keywords produce a coherent, runnable deployment plan. Once the cloud computing, cloud instruments, cloud-orchestra deployment plan is generated the computer musician can deploy/start a cloud-orchestra upon request. Model Driven Development (MDD) [9] allows for the rapid 1. INTRODUCTION modelling (defining) and generation of runnable code that With the flick of a switch your lights turn on. With the implements such a model. We propose to abstractly model click of the mouse your computation can turn on too. Cloud a cloud-orchestra and rely upon model optimizers to fit such computing promises utility computing: computing treated a network near-optimally to available resources as a utility and billed like a utility – even provisioned like a such as cores, virtual machines, etc. utility such as electricity [5]. This demand-based dynamic This work addresses: the diculty of configuring and de- provisioning of virtual machines is what makes it possible ploying a cloud-orchestra; and the ecient allocation of re- for cloud providers to allow clients to scale computation to sources for cloud-orchestras. These problems motivate the their needs. Cloud computing promises much flexibility but following contributions described in this paper: these promises are often wrapped in intense complexity [5]. The benefits of using cloud computing are clear: one does Propose and define cloud-orchestras; • not need to own the hardware to run their software; cloud Define a model of cloud-orchestras; • computing enables experimentation with large allocations of Argue for a declarative model driven development ap- resources for short periods of time; cloud service providers • proach to cloud-orchestras; Provide a prototype that defines, generates, and de- • ploys a cloud-orchestra; Permission to make digital or hard copies of all or part of this work for Address cloud-orchestra deployment abstractly and con- personal or classroom use is granted without fee provided that copies are • cretely. not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific 2. PREVIOUS WORK permission and/or a fee. NIME’15, May 31-June 3, 2015, Louisiana State Univ., Baton Rouge, LA. Cloud-orchestras can employ model driven development, Copyright remains with the author(s). cloud computing, cloud deployment, networked audio, net-

121 Proceedings of the International Conference on New Interfaces for Musical Expression, Baton Rouge, LA, USA, May 31-June 3, 2015 worked computer music, networking latency, streaming tech- model. This model may be optimized by model optimiz- nology and networked orchestras. ers which search for an ecient configuration. Once such Model Driven Development (MDD) and Model Driven a configuration has been found, templates can be executed Engineering [9] are methods of specifying software and sys- to generate a working deployment plan. This deployment tems as models and then relying on model checkers, and plan can be executed and the cloud-orchestra will be in- model generators to generate skeletal stub code, or fully stantiated, configured, and executed eventually producing working systems. Model Driven Development is often used music in near real-time streamed over a network. in fields which have computation but are limited to certain Cloud-orchestras and their potential resources can be mod- problem domains, often allowing end-users to customize a elled and these models can be used to develop a deployment system without much programming experience. plan to deploy a cloud-orchestra on resources available to Barbosa et al. [3] surveyed networked computer music you. The fundamental problem of a declarative model of a since the 1970s. This body of work lead to the jack [7] low cloud-orchestra is how to match a set of resources (hosts) latency sound server, netjack [7] and Jacktrip [6]. The Net- with the workload (cloud-orchestra) proposed. jack and Jacktrip [6] send synchronized jack audio streams The inputs to this problem are a set of usable host vir- over a LANs and the internet. tual machines and a synthesizer network model (the cloud- One reason to employ cloud computing in a computer orchestra). The model we use is partially described in the music instrument is to provide user interfaces to mobile de- model package of Figure 2. Synthesizers are modelled as vices over the web, thereby allowing audience participation. SynthModules or modules. An instance of a module is a Oh et al. [13] demonstrate the use of smartphones in audi- SynthBlock. The distinction is similar to the distinction ence participatory music and performance. Jord`a[11] de- between a class and an object. The SynthBlock has a Syn- scribes many patterns of collective control and multi-user thModule, a name and a host will be associated with it. instruments as well as the management of musicality of in- These Synthblocks are collected within a SynthDef, which struments. Cloud computing was indirectly used by Dahl et is the definition of the entire cloud-orchestra. The SynthDef al. [8] in TweetDreams. TweetDreams allows an audience to also contains connections that join the inputs and outputs participate with a by tweeting at a twit- of a SynthBlock together. In the next section we formalize ter account that aggregates audience tweets using Twitter’s this model for the purposes of optimization. own message delivery cloud. These recommendations would be valuable for anyone creating an audience-participatory 3.1 Modeling and optimization instrument with a cloud-orchestra. In general one can model the resource allocation problem as Jesse Allison et al. [1, 2] describe the Nexus framework a cost minimization problem.One can formalize this prob- to allow for user-interface distribution via the web. While lem as an Integer Linear Programming problem, and po- Weitzner et al. [17] built massMobile that allows the cre- tentially minimize it using tools such as GNU Linear Pro- ation of a web interface to interact with /MSP via the gramming Kit 1. This formulation enables search methods web. Both works emphasize the value of HTML5 interfaces to produce optimal or near-optimal configurations. as they are both standardized and ubiquitous. Exposing Regardless, given available resources or a resource alloca- these user-interfaces from a cloud-orchestra would prove in- tion one must allocate synthesizers (synthBlocks) to hosts. valuable as it would allow fine grained control of a synthe- For a cloud-orchestra deployment one should consider opti- sizer running on a VM. mizing for: Cloud-orchestras share many of the same problems and Locality: the more synths communicating on the same diculties as laptop orchestras [15, 14]. Laptop orchestras • are composed of laptop synthesizer users who are connected VM the less latency and network bandwidth required. jack CPU load: too many synths will overload a CPU ham- together over OpenSound Control or . The main dif- • ference between a laptop orchestra and a cloud-orchestra is per near-realtime performance. that a cloud-orchestra doesn’t necessarily have more than Remote Links: The number of remote links between • 1 performer or musician, much of the orchestra is under synths should be reduced, di↵erent allocations of synths computer control. to di↵erent hosts can increase or decrease the number Lee et al. [12] describe many opportunities for live net- of remote links. work coding. They argue that networked live coded music Bandwidth: network bandwidth use decreases as lo- allows for interesting mixes of centralized and decentralized • cality of synths increases and the number of remote synthesis and control – all amenable to cloud-orchestras. links decreases. Ansible, Chef and Puppet [16] are common configuration management and automation framework tools. These tools Other costs could be considered such as the monetary tend to be used to install software, synchronize software, cost to provision cores, VMs, memory, and bandwidth. One bring up servers and automate tasks. In this research we could add another level of modeling to model provisioning use Ansible to run commands on multiple VMs. to determine the minimum resources required to deploy a Beck et al. [4] first used grid-computing and generated cloud-orchestra. deployment plans for interactive performances. Hindle [10] The optimizer’s main task is to take the available hosts describes using the cloud [5] for computer music and the is- and allocate the synthesizer instances (synthBlocks) to these sues one encounters, exporting audio from the cloud. Cloud- hosts based on the cores and bandwidth available. The al- orchestras su↵er from this problem, in the cloud no one can location should be optimal in the sense that it increases hear unless you stream. This work seeks to elaborate on the locality and reduces the number of remote links. Reducing prior work and focuses more on synthesizers in the cloud. remote links limits the potential latency. Given synthBlocks from S, connections can be repre- sented as a set of edges Cs,t from C : S S where s and t ⇥ 3. MODEL OF A SYNTH NETWORK are synthBlocks and a connection from s to t is represented by set membership. The UML in Figure 2 is labelled with The proposed solution to the cloud-orchestra deployment our mathematical definitions. problem is to leverage model driven development to define a cloud-orchestra. A definition of a cloud-orchestra is a 1https://www.gnu.org/software/glpk/

122 Proceedings of the International Conference on New Interfaces for Musical Expression, Baton Rouge, LA, USA, May 31-June 3, 2015

slaves.json [ { "name":"VagrantHost", clicking here Web User Generated "host":"172.17.0.4", will execute "username":"ubuntu", steps 3-5 Interface Deployment "cores":1, }, Plan { "name":"DockerHost", "host":"172.17.0.5", "username":"ubuntu", "cores":2, } ] 1) Define resources 2) Define and deploy cloud orchestra 3) Generate deployment plan

Deploying to hosts Connecting audio and running Synths from cloud to Jack

4) Run deployment plan 5) Connect to Cloud Orchestra 6) Use Cloud Orchestra

Figure 1: Example of defining and deploying a cloud-orchestra using the concrete implementation synth- cloud-orchestra.

This synthDef model tuple (H, S, C, A) can formalized cern. A tuning parameter ↵ (↵ R) can be used to indi- 2 and optimized using the following definitions and mappings: cate the importance of overflowall versus remotesall.An optimal optimizer function will meet the requirements of H is the set of hosts. Equation 1 below: • S is the set of SynthBlocks. • C : S S is the set of connections between synth- • ⇥ optimize(H, S, C) = arg min f(A) Blocks. Cs,t where s and t are synthBlocks represents A (1) a connection between s and t. This set is constant f : A R = ↵ overflowall + remotesall throughout optimization. 7! · Naively one could generate all permutations of the legal A : H S is the allocation of synthBlocks to hosts • ⇥ sets A, matching SynthBlocks and Hosts, and rank them by where Ah,s, h H and s S, represents an allocation 2 2 function f described in Equation 1, choosing the minimum of a synth s to a host h. This set is the set to be result. There are likely more ecient methods of determin- optimized. + ing optimal configurations, such as employing linear pro- cores : H Z is a function returning the number of • 7! gramming. At this point, once an optimal or near-optimal cores of a host. configuration of hosts and synthBlocks is found, the deploy- blocks : H Z = Ah,s s S returns the number ment can be generated or executed. • of synthblocks7! allocated|{ to| 2 the}| host in A. overflow : H Z = max(0,blocks(h) cores(h)) 3.2 Deploying a synth network • 7! The number of allocated synthBlocks beyond the cores In this section we describe a general process to start and of the host. deploy a cloud-orchestra. Any concrete implementation will overflowall = h H overflow(h) The number of over- follow this process. After generating all the code necessary • 2 flowing hosts for the whole network. to deploy and run a cloud-orchestra from the model, one P connections : H Z = Cu,x + Cx,u where x S has to deploy and run the synth network. • and u s s S 7!A .| The| number| | of connections2 h,s 1. First the synthesizer source code and cloud-orchestra to/from2{ synthBlocks| 2 ^ of} host h. model are synchronized to all synth hosts (rsync). locals : H = C A A C The Z s,t h,s h,t s,t 2. Then the sound server (jackd) is started on each synth • number of connections7! |{ internal| to^ host h^. }| host. remotes : H Z = connections(host) locals(h) • 7! 3. Remote network audio connectors are started (jacktrip The number of remote connections to and from host or netjack). h. 4. For every synth host, their synthBlocks’ associated remotesall = h h remotes(h) The sum of remote synthesizers are started. • connections over all2 hosts. P 5. All audio connections are disconnected on all hosts to avoid interference and to start in a disconnected state. An optimizer for this problem should be a function that 6. SynthBlock synthesizers are connected to their appro- at least takes in a current configuration optimize :(H priate jack audio ports per each synth host. S C) (A : H S) and produces a host to synthBlock⇥ 7. An audio exporter is started (e.g., icecast (mp3), jack- mapping⇥ 7!A. When⇥ implemented it could potentially take a trip, or cloudorch [10] (websocket streaming)). partial initial allocation A if needed. The goal of the optimize function should be to minimize To halt or tear down the cloud-orchestra each host is con- overflowall first and then to minimize remotesall. A syn- tacted and all sound servers, remote network audio connec- thDef that needs more resources than are available is a con- tors, and all synthesizers and audio exporters are killed.

123 Proceedings of the International Conference on New Interfaces for Musical Expression, Baton Rouge, LA, USA, May 31-June 3, 2015

Defining resources:. A slaves.json (an example is in Figure 1) lists all ma- chines potentially under the cloud-orchestra’s control. Each definition is named and also details the ssh username used H for access, the hostnames, and the number of cores.

A C 4.1 Defining the cloud-orchestra S By seperating the cloud-orchestra definitions from the re- cores sources, the model optimizer is enabled to come up with many solutions and choose the best ones based on the re- locals remotes sources available and the optimization heuristics which em- phasize locality preserving configurations. Figure 1 shows how the webUI represents and generates a JSON definition. The user can define cloud-orchestras in either pure JSON or with the webUI that comes with synth-cloud-orchestra. Figure 1 depicts part of the web-based user interface pro- vided by synth-cloud-orchestra. The boxes are instances Figure 2: Architecture of an example cloud- of synthesizers, synthBlocks, and the arrows are the direc- orchestra tional links between the synthBlocks. By dragging from the boxes on the synthBlocks to the other synthBlocks them- selves one can connect the synthBlocks together. The syn- The responsibilities of a concrete framework based on this thBlocks are specified by first specifying a name of that abstract will be: to elicit a definition from a user; to elicit instance of the synthesizer and then the kind of synthesizer resources and resource constraints; to search for optimal it is. Double clicking deletes connections and synthesizers. deployment plans; to generate or execute such a deployment New synthBlocks are added by clicking the new button. plan; to enable the end-user to listen to the cloud-orchestra This method is flexible and allows optional parameters to once it is deployed. These responsibilities will be discussed be specified. For instance the host parameter in the Syn- in the next section. thBlocks can be specified, this allows the user to override the optimizer and assign a particular synthblock to a par- 4. A CONCRETE IMPLEMENTATION ticular host, perhaps for performance reasons. Hosts that Our concrete cloud-orchestra generator is called synth-cloud- do not reference particular slave hosts will be automatically orchestra and it is freely available 2. The hope is that the allocated from the slaves.json file. compute music community can take advantage of this oper- Synth-cloud-orchestra comes with some default synthesiz- able framework and start building cloud-orchestras without ers including ADC and DAC, these are meant to represent the hassle that the authors went through to get the cloud- general inputs and outputs that might be in the cloud or orchestra to run. actual computers. Audio maybe exported from this cloud- A dockerfile is provided with synth-cloud-orchestra and orchestra using jacktrip, but cloudorch [10] – the soundcard acts as instructions to setup hosts consistently so they can in the cloud – or icecast can also be used. Currently syn- act as synth hosts. This implementation currently makes chronization is the responsibility to the audio transport: some assumptions: jack and jacktrip. Control signals can use OSC but are not synchronized. The cloud-orchestra user has write access to a home • directory of the hosts they will employ. 4.2 Adding synthesizers The hosts already have the main software synthesizers • Each custom synthesizer is considered a synthModule or needed installed (, Chuck, Supercollider, Pd). module. An optional manifest file, manifest.json defines The hosts allow for passwordless login via ssh or ssh- • module’s name and the synthesizers source code. For in- agents. stance the example fm synthesizer is a csound synthesizer The hosts can access each other over ports used by with the fm.csd as the synthesizer to run and its module • jack and jacktrip. name is fm. The hosts need bash and ruby installed. A user can add a custom synth to their cloud-orchestra by • The head node needs ansible, bash, and ruby installed. creating a directory that will serve as their module. This di- • rectory will contain all assets and code required by their syn- The current implementation generates a series a bash thesizer including Csound orchestras, SuperCollider source scripts that allows for the synchronization of files, deploy- code, and sound assets. These modules will be synchronized ment, and the startup and connecting of synthesizers. Once to the appropriate hosts and executed as needed. generated all an end-user needs to run is gen/run.sh which By using templates one can avoid hard-coding IP ad- will execute all of the steps described in Section 3.2 on de- dresses in the synthesizer’s definition one can treat the syn- ployment. thesizer source code as a template to parameterize. Thus Throughout this section we will use an example of a FM at generation time, the appropriate configuration will be synthesizer and microphone (ADC) chained through a low- inserted into the source code of the synthesizer, as well as pass filter to a DAC. While these are not expensive opera- dynamicly into environment variables. tions they can be run on separate machines. Figure 1 (b) This pattern of user-defined synthesizers allows for the shows a graphical configuration the full webUI and shows computer musician to rely on their own synthesizers and some of the JSON definition of the synthdef. also leverage the hard work of the makers of CSound, Su- perCollider, Chuck, Pd, and other software synthesizers. 2Demo and source code: https://archive.org/details/ CloudOrchestraDemo http://github.com/abramhindle/ synth-cloud-orchestra 4.3 Deploying a cloud-orchestra

124 Proceedings of the International Conference on New Interfaces for Musical Expression, Baton Rouge, LA, USA, May 31-June 3, 2015

The program synthdefrunner is run within the directory formance related to cloud-orchestras, and the exploitation defining the cloud-orchestra. This program reads the def- of cloud computing in computer music. One area of re- initions of the cloud-orchestra and available resources. It search includes optimal and near optimal resource allocation then optimizes the network according to heuristics meant heuristics that could potentially optimize according to psy- to improve locality. If there are not enough cores for all choacoustic models with respect to latency. The integration of the synthesizers then it tries not overload the cores too of other sources of information into the models is another much and tries to increase locality. The current implemen- area. Work should be done to create real-time/run-time tation is naive and assumes at peak utilization 1 synthesizer configuration and re-configuration of the cloud-orchestra needs at least 1 core, and cores are not shared. Regard- much like modifying a max/MSP or Pd patch live, except less, the best suggested network configuration is chosen and with numerous machines. OSC support should be included recorded. Based on this configuration, the Templater that in the model as well. More work should be done on system generates the gen directory from the gen.erb templates. liveness and awareness as well as enabling the distribution These are shell scripts, written as very portable bash scripts of user interfaces. Currently there is much work to be done that define how to run the synthesizers and how to connect on easing the provisioning of a cloud-orchestra and estimat- the audio links together. ing the minimum resources needed to provision a cloud- Once gen is created the user can simply run gen/run.sh orchestra. This current approach generates a static cloud- to synchronize, deploy, instantiate and use their cloud-orch- orchestra, further work could be done to generate dynamic estra as per Section 3.2 on deployment. The WebUI lets a and fail-safe cloud-orchestras. Synchronization of audio and user define a cloud-orchestra synthdef and deploy it in one control signals within the cloud should be investigated. step, clicking submit query in part 2 of Figure 1 causes the generation, deployment and running of the cloud-orchestra 6. REFERENCES – the execution of steps 3 to 5 in Figure 1. In this implemen- [1] J. Allison. Distributed performance systems using html5 tation we provide a means of listening by quickly starting and rails. In Proceedings of the 26th Annual Conference of up a jacktrip connection with the cloud, and connecting all the Society for Electro-Acoustic Music,2011. of the synths connected to the DAC to the this connection. [2] J. Allison, Y. Oh, and B. Taylor. Nexus: Collaborative performance for the masses, handling instrument interface teardown.sh will shutdown the cloud-orchestra. distribution through the web. In NIME,2013. [3] A.´ Barbosa. Displaced soundscapes: A survey of network 4.4 Experience with the cloud-orchestra systems for music and sonic art creation. Leonardo Music Connecting to the cloud-orchestra with jacktrip [6] results Journal,13:53–59,2003. in relatively low latency. The overhead is not excessive and [4] S. D. Beck, S. Jha, B. Ullmer, C. Branton, and like jack, jacktrip was well made, with the concerns of the S. Maddineni. Grendl: Grid enabled distribution and music community in mind. Streaming over websockets [10] control for laptop orchestras. In ACM SIGGRAPH Posters,2010. increases latency considerably as any jitter or fluctations in [5] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and the network can harm the latency of the TCP connection. I. Brandic. Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 4.5 Recommendations 5th utility. Future Generation computer systems, It is recommended [10] to maintain master and slave im- 25(6):599–616, 2009. ages that can be easily duplicated and deployed as instances [6] J.-P. C´aceres and C. Chafe. Jacktrip/soundwire meets (synth-cloud-orchestra includes a dockerfile). Debugging server farm. Computer Music Journal,34(3):29–34,2010. is often best done locally using docker (http://docker.io) [7] A. Carˆot, T. Hohn, and C. Werner. Netjack–remote music collaboration with electronic sequencers on the internet. In and/or vagrant (http://vagrantup.com) to build local clouds. Proceedings of the Linux Audio Conference,2009. Locality tends to improve performance so network audio [8] L. Dahl, J. Herrera, and C. Wilkerson. Tweetdreams: links should be avoided to reduce latency; star-network for- Making music with the audience and the world using mations [6] for audio can flood switches and knock out local real-time twitter data. In International Conference on New network abilities while tree formations do not. We empha- Interfaces For Musical Expression,Oslo,Norway,2011. size the value of optimizing for locality as latency within [9] A. V. Deursen, E. Visser, and J. Warmer. Model-driven VMs is less than latency between VMs. software evolution: A research agenda. In International Workshop on Model Driven Software Evolution,2007. [10] A. Hindle. Cloudorch: A portable soundcard in the cloud. 5. CONCLUSIONS AND FUTURE WORK Proceedings of New Interfaces for Musical Expression Leveraging the cloud is dicult and leads to complicated (NIME), London, United Kingdom,2014. orchestration and deployment. To address this diculty we [11] S. Jord`a.Multi-user Instruments: Models, Examples and have described an abstract and concrete framework that en- Promises. In NIME’05,pages23–26,2005. ables computer musicians to define, create, and run cloud- [12] S. W. Lee and G. Essl. Models and opportunities for orchestras. By leveraging model driven development one networked live coding. Live Coding and Collaboration Symposium 2014,1001:48109–2121,2014. can allow end-user programmers, such as computer musi- [13] J. Oh and G. Wang. Audience-participation techniques cians, to focus on programming synthesizers rather than based on social mobile computing. In Proceedings of the administering the cloud computers they rent. Model driven International Computer Music Conference 2011 (ICMC development allows musicians to avoid tedious manual con- 2011),Huddersfield,Kirkless,UK,2011. figuration, and define their cloud-orchestra as a network of [14] S. Smallwood, D. Trueman, P. R. Cook, and G. Wang. connected synthesizers and then deploy an optimized ver- Composing for laptop orchestra. Computer Music Journal, sion of that network to existing resources. 32(1):9–25, 2008. Abstractly a method of assigning resources to a cloud- [15] D. Trueman. Why a laptop orchestra? Organised Sound, 12(02):171–179, 2007. orchestra has been presented. Concretely, the example im- [16] P. Venezia. Review: Puppet vs. chef vs. ansible vs. salt. plementation synth-cloud-orchestra allows single-click de- http://www.infoworld.com/article/2609482/data-center/ ployment of cloud-orchestras defined by drag and drop. This review--puppet-vs--chef-vs--ansible-vs--salt.html,2013. work provides a novel user interface to design, define, de- [17] N. Weitzner, J. Freeman, S. Garrett, and Y.-L. Chen. ploy, and run cloud-orchestras. massMobile - an Audience Participation Framework. In This work opens up new areas for computer music per- NIME’12,AnnArbor,Michigan,May21-232012.

125