9
edits
PDCON:Conference/A collaboration workflow from sound-based composition to performance of electroacoustic music using Pd as a framework: Difference between revisions
PDCON:Conference/A collaboration workflow from sound-based composition to performance of electroacoustic music using Pd as a framework (view source)
Revision as of 10:53, 9 July 2011
, 9 July 2011→A collaboration workflow from sound-based composition to performance of electroacoustic music using Pure Data as a framework
Ktsoukalas (talk | contribs) No edit summary |
Ktsoukalas (talk | contribs) |
||
| Line 4: | Line 4: | ||
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 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. | 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 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 | 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 PD or external libraries and abstractions to shorten development time. | 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. | ||