PDCON:Conference/A collaboration workflow from sound-based composition to performance of electroacoustic music using Pd as a framework: Difference between revisions
Ktsoukalas (talk | contribs) No edit summary |
mNo edit summary |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
Author: [[User:Ktsoukalas|Kyriakos Tsoukalas]] | Author: [[User:Ktsoukalas|Kyriakos Tsoukalas]] | ||
Download full paper: [[Media:A collaboration workflow of electroacoustic music using Pd.pdf]] | |||
By choosing | 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. | 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 | 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 | 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}} | |||
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
Author: Kyriakos Tsoukalas
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.
4th international Pure Data Convention 2011 Weimar ~ Berlin