OLW: An Extension to MSP for the Implementation of
Overlap-Windowing Techniques
Francois Thibault, Philippe Depalle
Music Technology Group, McGill University, Montreal
email: thibault,depalle @music.mcgill.ca
Abstract
Many important audio DSP algorithms are based on
overlap-windowing techniques. Despite the fact that
MSP provides a basic mechanism to handle
overlapping windows, there is still a need for an
explicit and flexible way to handle such data flow.
This paper presents an extension to MSP called OLW
(for OverLap-Windowing), which allows an easy
implementation of techniques such as STFT, LPC,
pitch detection, and formant tracking. In this paper
we present the OLW framework that includes OLW
objects for data flow transfer, a set of OLW objects
dedicated to sound analysis, and a very simple
Software Development Kit that allows the
implementation of new OLW objects. We also discuss
the smooth integration of OLW within MSP, and
show that OLW objects behave as standard MSP
objects when not used in an overlap-windowing
context.
1 Introduction
This paper presents an extension to the
MAX/MSP environment called OLW (for OverLapWindowing) that allows an explicit implementation of
overlap-windowing techniques.
Continuous research and development efforts
made in conjunction with computing power increase
over the last decade have allowed a drastic evolution
of real-time music and audio programming
environments such as MSP (Zicarelli 1998), jMax
(Dechelle et al. 1998), Pd (Puckette 1997), and
SuperCollider (McCartney 1998). Despite the
availability of such powerful environments to the
computer music community, a fairly small number of
powerful DSP analysis methods have been
developed, likely due to a significant complexity gap
that results from a lack of appropriate and explicit
overlap-windowing technique management.
The current overlap-windowing techniques that
are available in MSP fall into two categories. The
first consists of programming ad-hoc external objects
that hide the overlap-windowing management to the
user. This is the case for important third party objects
such as fiddle- (Puckette and Zicarelli 1998), cpt
(Cirotteau et al. 2001), and lpc- (designed at
IRCAM). Although these objects work well, they do
not allow access to intermediate steps of the DSP
algorithms, and they do not provide the user with the
appropriate level of modularity for an easy
implementation of various complex signal-processing
techniques.
The second category implements unconventional
approaches using existing MSP tools. Good examples
of such designs lead to interesting spectral processing
applications (Settel and Lippe 1998), (Dobrian 1999).
However, this approach results in complex patches
and non-intuitive designs. Furthermore, since these
types of patches do not benefit from a flexible data
flow management, patches must be rebuilt each time
the user changes structural parameters such as the
overlap factor.
On the other hand, Pd supports overlapwindowing techniques through two built-in objects
called block- and reblock- (Puckette 1997). The
most recent release of MSP includes the pfft- object
(Dobrian 2001), constituting a first step towards
using overlap-windowing techniques. However pfftis essentially limited to Fourier-based techniques. In
spite of these improvements, a general-purpose
approach that would provide more flexible access to
signal data flow still lacks in MSP. The OLW
framework described in this paper, shows equivalent
results to those devised in Pd, using data transfer
concepts similar to the ones presented by Wright et
al. in the integration of SDIF format within MSP
(1999).
2 Overlap-Windowing Technique
MSP implements a vector approach to signal
processing in which sound signals are processed by
blocks of a given size. The block size (called the
"vector size" in MSP) can be changed to favor either
computation efficiency (with large vector sizes), or
low latency (with small vector sizes). Despite careful
selection of this parameter, a compromise must be
made between the two, depending on the particular
demands of the application. For example, for a
parameter extracted from a block of 64 samples at a
sampling rate of 44.1 kHz, the refresh rate is less than
538
