daemon@bartok.Eng.Sun.COM (02/10/90)
Music-Research Digest Thu, 8 Feb 90 Volume 5 : Issue 13
Today's Topics:
Announcing...
Knowledge Acquisition
*** Send contributions to Music-Research@uk.ac.oxford.prg
*** Send administrative requests to Music-Research-Request
*** Overseas users should reverse UK addresses and give gateway if necessary
*** e.g. Music-Research@prg.oxford.ac.uk
*** or Music-Research%prg.oxford.ac.uk@nsfnet-relay.ac.uk
----------------------------------------------------------------------
Date: 8 Feb 90 00:25:10 GMT
From: Pete Yadlowsky <pmy%vivaldi.acc.virginia.edu%murdoch%uvaarpa%haven%aplcen%uakari.primate.wisc.edu%zaphod.mps.@uk.ac.oxford.prg>
Subject: Announcing...
To: music-research@uk.ac.oxford.prg
...the release of LPC, a NeXT adaptation of Paul Lansky's
linear predictive analysis and pitch tracking programs.
LPC reads a NeXT or CSound-NeXT format soundfile and produces
a data file which codes the sound in terms of its time-varying
formant characteristics and the RMS levels of a residual excitation
signal. To resynthesize the audio signal, this LPC-derived dynamic
filter is excited with a spectrally rich driver, such as
white noise or a pulse train, though many interesting effects can
be produced with other types of signals. Also, there is a pitch
tracking utility which produces data that may be merged with
the LP analysis data. This pitch information may then be used
to control the pitch of the driving signal during resynthesis.
CSound (Barry Vercoe's software synthesis system) provides signal
modification units which read LPC analysis files and resonate
specified signals through the LP-encoded filters. CSound has also
been ported to the NeXT. The next release of CSound-NeXT (sigh) will
have hooks for launching and communicating with LPC-NeXT, thus
adding another application to the CSound-NeXT integrated tool set.
Due out shortly.
CSound-NeXT and LPC-NeXT are both NeXTStep applications, meaning
that their front ends are built on the NeXT graphic user interface
for clear, intuitive interaction.
For a detailed explanation of the workings of linear predictive
analysis, try "Computer Music" by Dodge and Jerse. Hal Chamberlin's
"Musical Applications of Microprocessors" also has a few paragraphs
on this.
ftp:
uvaarpa.acc.virginia.edu:/pub/next/Apps/LPC.tar.Z
uvaarpa.acc.virginia.edu:/pub/next/source/LPC-source.tar.Z
Piece-wise uuencoded mailings can be arranged for those who do not have
ftp access.
Pete Yadlowsky
Academic Computing Center
University of Virginia
pmy@Virginia.EDU
--
Peter M. Yadlowsky | "Pay no attention to that man
Academic Computing Center | behind the curtain!"
University of Virginia |
pmy@Virginia.EDU |
------------------------------
Date: Tue, 6 Feb 90 15:34:59 EST
From: Robert Rowe <rowe@edu.mit.media.ems>
Subject: Knowledge Acquisition
To: music-research@com.sun.eng.bartok
In reply to my query about the knowledge acquisition process in
PRECOMP, Otto Laske makes some observations and asks for comment.
I would like to explore further some of his remarks, such as
>Why is knowledge acquisition (KA) important? It is the only way
>to get away from the ad hoc stipulations now reigning supreme in
>"music research" (a nice neutral term that says nothing).
Why is KA the only way to improve music programs? This is what I
fundamentally do not understand about your position, and the
above statement does not help me.
>In fact, such monitoring and knowledge acquisition modules
>should be part of every tool built today, since only with such
>material--rather than the informal musings of users--tools
>can be systematically improved, and criteria for their evaluation
>can be developed.
You have built a knowledge acquisition section into PRECOMP, which
records how an expert user chooses to segment musical material generated
by the other parts. I'm sure you realize that it is a trivial step
to add a protocol recorder to a composition program - the reason no
one does it is that it is so unclear why it is worth saving all those
megabytes of data. Recording a protocol in itself, in any case, is
hardly knowledge acquisition. You save the interesting part of the
process for the cognitive musicologist who will examine and evaluate
the data later on, and for the designer who sets up the task in the
first place.
>As in OBSERVER, the session log --protocol--needs to be inter-
>preted by a cognitive musicologist
The kind of decision-making you will find recorded by
your segmentation advisor is, I wonder if you would agree, highly
directed by the structure of the task. Anyway, you have this data which says
which parameters an expert uses to segment musical material. So - what are
they? If you tell me what parameters your users favored to segment material,
that is information I could use as I continue development of my system. If
you tell me I have to record protocols of people using my system, save
the data, and hand it over to a cognitive musicologist so he can interpret
that "knowledge" for me, that is considerably less informative.
>What are the results from work with PRECOMP. Yeah, everybody
>wants results, before even having understood the purpose.
Guilty on both counts. I know you think the purpose is glaringly,
painfully obvious, but I am genuinely having trouble discerning it. Let
me try to outline what I take you to be saying: Composition tools are
inadequate because they do not reflect the cognitive processes composers
use. Knowledge acquisition is the only way to uncover those processes,
and, thereby, improve the tools. I am writing a computer program for
composition and performance. I have been doing such things for many years.
As the program is used for more compositions, and by more musicians, it
improves. Score of other composers are in the same state of affairs.
Still, I do not believe that the operations I encode will be
useful for all composers. I do expect that the knowledge representations
and manipulations I take myself to be developing will be of interest to
other composers and musicians involved in similar pursuits; I do expect,
and in fact, have seen, other musicians use the system to make music.
But I do not expect that the knowledge acquisition process as you describe
it would have any particular impact on the development of my, or many
other composers', tools. According to you, knowledge acquisition has to
provide us with a substrate of tools capturing the common compositional
cognitive heritage for anyone to make any progress.
>What interests me in this research is not only the abstract
>theoretical insights into expert's knowledge, but equally, if not
>more, the insights that lead to better composition tools. The SA
>in PRECOMP, for instance, could be used for any score-generating
>program, to aid the composer in designing a definitive score. It
>is thus an aid in compositional design.
>Similar tools are possible for other musical tasks, there is
>no limit.
This is where the purpose becomes unclear to me. Do you believe that
the segmentation advisor captures a universal cognitive skill, applicable
to the tasks of all composers? If you do believe it, what are other such
universal, or at least, very widespread compositional strategies? If you
do not believe it, why is any one composer's structuring of a musical
task supposed to provide useful tools for all the others?
- Robert Rowe
- Music & Cognition Group
- MIT Media Laboratory
------------------------------
End of Music-Research Digest