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

   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.

   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.

   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.