• Nenhum resultado encontrado

3.4 Related Technologies

3.4.5 Pure Data

As we have mentioned,Pure Datais not a game audio middleware, although it has been used for game audio [Pau03]. It is a visual programming language which follows the data flow paradigm and is intended for developing real-time DSP and multimedia applications. It was developed by Miller Puckette in the 1990s as an open source version of the Max programming language,

3.4 RELATED TECHNOLOGIES 63

Figure 3.23: Pure Data’s logo [Puc16].

which was later derived into the Max/MSP language. Pure Data has many uses, among which interactive music stands out. It has an active community of programmers and musicians alike, even though its uses are usually more common in experimental music and academic research than in popular commercial music. Since Puckette’s original release, there have been a number of different distributions ofPure Data. The versions distributed by Puckette himself are normally referred to asPure Data “vanilla”. Examples of other distributions arePure Data Extended38and Pd-L2Ork39. In this thesis, we will always refer toPure Data “vanilla”.

Pure Data is provided as a stand-alone application whose interface allows the creation of DSP programs called Patches. These Patches are interpreted by the Pure Data application itself, being possibly executed in real-time and on-the-fly as the programmer or sound designer

“writes” the Patch. Since this is the intended workflow of the tool, it was not developed to be embedded in other applications, and thus its use on games is rather limited. Thanks tolibpd40, there are a few less known titles in the market that do usePure Datafor the game soundtrack. An example of that is the iOS gameWave Trip(Lucky Frame, 2013) [Lib16]. Here we give a very brief description of the corePure Datafeatures along with some others that are particularly pertinent to our research. There are, however, other more adequate reference materials for those who wish to deepen their knowledge in the language. ThePure Data manual is one such alternative, but we also recommend a selection of chapters from Farnell’sDesigning Sound [Far10, Chapters 8-14].

System Description

Every Patch inPure Data consists of a bi-dimensionalCanvaswhereObjectscan be placed at any integer position and thenConnectionscan be traced between them. Objects are represented by a filled rectangle (with slight visual variations) and can be treated as programming functions.

Each Object has a name, a list of creation arguments, a set of zero or more Inlets and a set of zero or more Outlets, all of which are visible in the rectangle representation. The Object name determines the Object type, which in turn determines how it uses its creation arguments and how many Inlets and Outlets it has.Inlets stay on the top edge of the Object, and work as the input gate for the Object function. Outlets stay on the bottom edge and work as the output gate.Connectionscan only be made from an Outlet to an Inlet, and the receiving Inlet must be compatible with theConnection Type. There are two Connection Types: Message

38https://puredata.info/downloads/pd-extended

39https://puredata.info/downloads/Pd-L2Ork

40http://libpd.cc/

Connections(thin lines) and Signal Connections(thick lines)41. The Outlet determines the Connection Type, since the user always starts a Connection by clicking on the Outlet of an Object, then dragging the other Connection end to an adequate Inlet. Figure 3.24illustrates a classic “Hello World” patch in Pure Data, where a sinusoidal wave is played.

Figure 3.24: A simple Pure Data Patch that connects the sinusoidal oscillator object [osc~] to a digital-to-analog converter[dac~]through a Signal Connection. This effectively produces the sound of a sine wave at 440 Hz.

The Connection Types determine how and when data flows between the Objects in a Pure Data patch.Message Connectionsmust be triggered by the Object whose Outlet it connects.

When this happens, the results of the parent object are sent through the Connection to the corresponding Inlet in the child object. This might, in turn, trigger other messages to be sent through the Connections in the child Object. This process behaves in a depth-first manner. Some Objects can trigger their Message Connections “spontaneously”, by being clicked by the user (like the[bng] Object), by receiving a packet from the network, etc. There is also a special kind of Object calledMessage. It has a single Outlet, no Inlets, and can be assigned a character string.

Whenever it is pressed, a Message Object sends its content to its Outlet, possibly starting a whole chain of Messages down the Patch. Figure 3.25 shows an example of a Message Object and a Message Connection. A special kind of Message, simply containing the string “bang”, is often used to trigger effects in child Objects without really sending any real information.

Figure 3.25: A Message Object connected to the [print] Object. Clicking the Message sends the string “This is a message” to the child Object, which prints it in thePure Data console.

All basic arithmetic and logic operations are already provided as native Objects inPure Data, as well as an extensive collection of DSP Objects such as [noise~] (white noise generator), [lop~] (low-pass filter), [hip~] (high-pass filter), [bp~] (band-pass filter), among many others. Users can define additional Objects with three different methods, described as follows.

• Abstractions.When an Object name does not correspond to any known type,Pure Data treats it as an Abstraction. It searches a number of predetermined paths for a *.pd file whose name matches the one written in the Object. Creation arguments are accessible inside it, and the [inlet], [inlet~], [outlet], and [outlet~] Objects can be used to add Inlets and Outlets to the Sub-Patch. Abstractions can be instanced multiple times. To differentiate each, a special symbol $0 can be used – it expands to a unique identifier as long as it is within the right Patch. We call this the Zero Dollar of the Patch.

41 ThePure Data manual calls them “Audio Connections”, but we believe that “Signal Connections” is more appropriate since not every signal represents a sound.

3.4 RELATED TECHNOLOGIES 65

• Sub-Patches.When a[pd <name>]Object is created, a new Canvas is associated to it, and the user can populate it as he or she sees fit. It then loads that Patch as the Object.

Creation arguments, Inlets and Outlets can be added the same way as with Abstractions.

However, Sub-Patches share the same Zero Dollar as their parent Patch.

• Externals. These work like Abstractions, except the loaded files must be a dynamically linked library containing the Object behavior implemented inC. This is used to allow more efficient implementations of heavy algorithms and data structures.

Another important type of Object is the Array type. It comes with a single Inlet that can be sent a few key Messages, but most of Array manipulation is actually done with the help of auxiliary Objects such as[array get]and [array set]. Every Array has a unique name, and the user must provide it to the auxiliary Objects for them to work. Arrays can be used to store signals, being the most direct method of storing and playing samples in Pure Data.

Pure Data, being designed for real-time DSP, provides per-Patch settings that determines the sample rate used and how many samples it processes perTick. The default Tick size for Pure Datais 64 samples long. Every Tick, the DSP engine iterates over all Signal Connections following a deterministic order, and transfers the corresponding amount of samples for that Tick, unless an Object outputs a different number of samples. This means even silent Signal Connections – that is, Connections that are carrying constant-value signals – still demand processing, costing CPU time for the Patch execution. Note how this differs from Message Connections, which are triggered only per demand.

Lastly, as we mentioned in the beginning of this section, libpd provides a way to embed Pure Data Patches into other applications. Essentially, this library links the host application to thePure Data engine and exposes its key features in aCAPI (with bindings to a number of other programming languages also available). Besides opening and loading Patches, libpd can also send and receive Messages to and from the loaded Patches, read and write to available Arrays and, most importantly, request DSP ticks and inspect the resulting output signals. That means it does not provide sound playback likePure Data does. The host application is responsible for forwarding the obtained audio signal to the appropriate low-level routines that ultimately lead it to the sound card.

Critical Analysis

Being a full-fledged programming language,Pure Data provides endless possibilities for real-time soundtracks. Both sample-based and procedural audio approaches are possible. One can even emulate old-school MIDI synthesizers and program algorithmic or stochastic melodies. Besides, the tools has a community with a long history, which means an active support for eventual issues the user may face. The downside of all this is the very fact that it is a programming language.

Programming is not easy, and sound designers might even take it as an abuse if it is demanded of them. Among all the tools presented here,Pure Data has definitely the steepest learning curve.

Another problem is that, being a free software mostly maintained by a single developer, its usability issues stand out as much as its potential, specially when compared to the other

com-mercial, high-budget projects we have discussed. The situation is even more aggravating for its use in games, since it was not designed to be used as an embedded library, but as a stand-alone application. Even though libpd circumvents that restriction, the internal implementation of Pure Data still leaks a number of difficulties through the wrapper libpd provides. For exam-ple, all of its internal states are kept in global scope. This immediately poses a hurdle for the development of games, since it demands some sort of mediatory code to allow safe multi-thread programming.

Nonetheless, it is the technology that comes closest to our research interests, for many reasons.

It is the only free software among the studied tools, which aligns with our own middleware license.

Pure Data is specifically designed for real-time DSP, thus consisting of a solid implementation reference. It also has a respectable user base, which indicates us that, despite the problems we have listed, Pure Data is rather good at what it does, or it is the only reasonable alternative available at the moment. Lastly, the data flow paradigm present in the language offers us yet another way to achieve a procedural mechanism for the user, where the other tools have preferred approaches closer to structured programming.