PDCON:Conference/A collaboration workflow from sound-based composition to performance of electroacoustic music using Pd as a framework: Difference between revisions

Latest revision as of 21:20, 6 October 2011

A collaboration workflow from sound-based composition to performance of electroacoustic music using Pure Data as a framework

Download full paper: Media:A collaboration workflow of electroacoustic music using Pd.pdf

This paper describes a workflow for composers, engineers and performers to collaborate, using Pure Data as a framework, towards the design of electroacoustic musical instruments intended for live performances of sound-based music. Furthermore, it presents some considerations about live performance and ideas of creating collaboration tools, possibly as Pd GUI plugins.

By choosing Pd as DSP engine and automation software, users are able to program in a graphical programming environment. A programming project approach such as the «incremental-build model», may result in a more rapid development of a musical instrument, based on early performance testing, reuse of software and progressive refinement of modules. Τhe visual programming environment of Pd could be used by different users as a collaboration environment that combines a visual representation of the automation and DSP programming within a patch-file. When the case is that the composer, the engineer and the performer is the same person and assuming that this person is sufficiently knowledgeable in each domain of expertise, then the case seems to be ideal from a transfer of ideas point of view but enervates the energy that will be spent in each domain of expertise, since it will be a portion of the total energy of one person. In the case of an association of a composer, an engineer and a performer, the labor is divided to three people and the case becomes more complicated from a transfer of ideas point of view, but gain in knowledge diversity. Composers could design data-flow diagrams for the sound processing as planned by their composition ideas. Then engineers could validate and, in collaboration with composers, clarify the different parts of the diagrams. In order to program a sound synthesis engine as planned by a composer's diagram, engineers could develop new and use any available class of Pd or external libraries and abstractions to shorten development time. The performer's interface could be based on a separate device-focused (sensors-equipped, handheld, tangible, etc) (sub-)system, that would communicate with Pd. Such an approach should transfer to new projects the dexterity gained with certain devices and custom systems by the performers to succeed in embodiment of control parameters through effective mapping of dexterous gestural abilities. Furthermore, making available the mapping of control parameters for calibration by the performer himself, should help his practice gain in quality. Pd software is used by many electroacoustic composers and engineers, who share resources and publish their work and tools online. Exploring the field of electroacoustic music becomes more fruitful by succeeding in implementing new compositional ideas. The workflow ideas described in this paper aim at helping projects of collaboration in electroacoustic musical instrument creation, run with consistency to the initial idea.

Sponsors and partners of the 4th internationals Pure Data Convention in Weimar 2011

4^th international Pure Data Convention 2011 Weimar ~ Berlin

@@ Line 1: / Line 1: @@
-This paper describes a workflow for composers, engineers and performers to collaborate, using Pure Data (PD) as a framework, towards the design of electroacoustic musical instruments.
+== A collaboration workflow from sound-based composition to performance of electroacoustic music using Pure Data as a framework ==
-When an electroacoustic music composer decides to implement a composition idea in a way that fulfills certain aesthetic criteria, then a sound synthesis engine should be programmed to produce a desirable sound. When using PD for interface, DSP and automation programming, its users are able to use a visual programming environment to manage its methods. Through visual programming, a designer can easily provide prototype designs for consideration that would actually be part of the sound synthesis engine programming. This may result in more rapid development and better asynchronous collaboration of different designers, since every goal-describing design could be part of the implementation program.
+Author: [[User:Ktsoukalas|Kyriakos Tsoukalas]]
-In the case the composer, the engineer and the performer is the same person and assuming that this person is sufficiently knowledgeable in each domain of expertise, the case seems to be ideal from a transfer of ideas point of view but may reduce the possibility of aesthetics innovation, because there are less associations, therefore, possibly, less meditation on ideas and aesthetic criteria. Furthermore, such a case enervates the energy that will be spent in each domain of expertise, since it will be a portion of the total energy of one person. In the case of an association of a composer, an engineer and a performer, the work is divided to three people and becomes more complicated from a transfer of ideas point of view but gains in possibility of aesthetics innovation.
-Composers could use PD's visual programming environment to create data-flow diagrams for the sound processing as planned in their composition ideas. Then engineers could validate and, in collaboration with the composers, clarify any part of the diagrams. In order to program a sound synthesis engine as planned by a composer's digram, engineers could use any available method of PD or its external libraries, or develop new ones. The development of the performer's interface could be based on adaptive, device-focused (sensors-equipped, tangible etc.) data mining engines. Such an approach should not only support the development of performer specific interfaces but will also accelerate the process of the interface development and calibration. Furthermore, a performer gains dexterity on a certain interface by practice. Making available the mapped control parameters of the engine for calibration by the performer himself, should help his practice gain in quality.
+Download full paper: [[Media:A collaboration workflow of electroacoustic music using Pd.pdf]]
-PD software is used by many electroacoustic composers and engineers, who share resources and publish their work and tools online. Exploring the field of electroacoustic music becomes more fruitful by using FLOSS and interacting with its online supporters. It is common to hear from electroacoustic music artists/composers «I am a musician, not an engineer...» or the exact opposite from engineers. The workflow proposed in this paper aims at helping projects of collaboration in electroacoustic musical instrument creation, run with consistency to the initial idea and not end up wrapping around whatever technology available.
+This paper describes a workflow for composers, engineers and performers to collaborate, using [[Pure Data]] as a framework, towards the design of electroacoustic musical instruments intended for live performances of sound-based music. Furthermore, it presents some considerations about live performance and  ideas of creating collaboration tools, possibly as Pd GUI plugins.
+By choosing Pd as DSP engine and automation software, users are able to program in a graphical programming environment. A programming project approach such as the «incremental-build model», may result in a more rapid development of a musical instrument, based on early performance testing, reuse of software and progressive refinement of modules. Τhe visual programming environment of Pd could be used by different users as a collaboration environment that combines a visual representation of the automation and DSP programming within a patch-file.
+When the case is that the composer, the engineer and the performer is the same person and assuming that this person is sufficiently knowledgeable in each domain of expertise, then the case seems to be ideal from a transfer of ideas point of view but enervates the energy that will be spent in each domain of expertise, since it will be a portion of the total energy of one person. In the case of an association of a composer, an engineer and a performer, the labor is divided to three people and the case becomes more complicated from a transfer of ideas point of view, but gain in knowledge diversity.
+Composers could design data-flow diagrams for the sound processing as planned by their composition ideas. Then engineers could validate and, in collaboration with composers, clarify the different parts of the diagrams. In order to program a sound synthesis engine as planned by a composer's diagram, engineers could develop new and use any available class of Pd or external libraries and abstractions to shorten development time.
+The performer's interface could be based on a separate device-focused (sensors-equipped, handheld, tangible, etc) (sub-)system, that would communicate with Pd. Such an approach should transfer to new projects the dexterity gained with certain devices and custom systems by the performers to succeed in embodiment of control parameters through effective mapping of dexterous gestural abilities. Furthermore, making available the mapping of control parameters for calibration by the performer himself, should help his practice gain in quality.
+Pd software is used by many electroacoustic composers and engineers, who share resources and publish their work and tools online. Exploring the field of electroacoustic music becomes more fruitful by succeeding in implementing new compositional ideas. The workflow ideas described in this paper aim at helping projects of collaboration in electroacoustic musical instrument creation, run with consistency to the initial idea.
+[[File:workflow.png]]
+{{Template:PdCon11}}