daemon@bartok.Sun.COM (04/13/90)
Music-Research Digest Thu, 12 Apr 90 Volume 5 : Issue 36
Today's Topics:
Compact Disks with Musical Instruments on them
Handelman quoting Laske quoting Bel
Intonation
Midi Driver
non computerized music: help
Richard Dawkins and music
*** 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: 9 Apr 90 19:29:05 GMT
From: Greg Sandell <sandell@edu.ohio-state.cis.tut>
Subject: Compact Disks with Musical Instruments on them
To: music-research@prg
Message-ID: <6184@accuvax.nwu.edu>
Recently I purchased four of the compact disks in the McGill University
Master Samples series. For those of you who don't know them, they
include an individual recording of every instrument of the orchestra
playing every note in its available range. `Non-clasical' sounds
are available as well, such as Rock drums and guitar chords.
I am also thinking of buying discs from the Pro Sonus series. From
what I know of them, they have similar `classical' sounds, although
they have recorded only every fourth note of the available scale
for each instrument. They are obviously targeted more exclusively
to the needs of Digital Sampler keyboard users, rather than
those with research interests.
Has anybody else used any of the ProSonus disks? I would be interested
in hearing your evaluation of them.
I have been doing spectral analyses of entire instruments in the
McGill series, and, having seen tremendous note-to-note differences,
am convinced that a strategy of recording only every fourth note
is a real error. As an example, when english horn goes from F4 to
F#4 (sounding pitches) there is dramatic change in fingering from
all keys closed to all keys open (roughly). This corresponds to
a dramatic change in spectral envelope between these two tones.
Clearly such timbral discontinuities are critical to the
essential character of the instrument. I am not a Sampling Keyboard
user, but it strikes me that just because the current memory
capacities of these devices only allow the sampling of every fourth
note, it is extremely shortsighted to go through the trouble of
recording such tones at great expense and releasing them on CDs when
it's only a matter of time before memory is so cheap that the current
limitations of Sampling Keyboards will be a joke.
Here are some brief evaluations of some of the instruments. As you
can see, the playing quality is not consistent; I think that this
is a major drawback in the McGill series. I hear that the current
issue of CMJ contains a review of the McGill tones, but I haven't
seen it yet.
1. Excellent tone quality and evenness of tone productions in the
performances of:
violin bowed vibrato
double bass bowed
flute non-vibrato
English Horn
tenor trombone
tuba
2. Less satisfactory tone quality or evenness:
viola non-vibrato (very scratchy)
Bassoon (weak in mid-high registers; very high notes omitted)
french horn (the user's manual does not describe the mike placement
of these tones; I suspect that the mike was place right by
the bell, which may not effectively capture the sound we
usually hear in this instrument, since the bells do not
face the listener.)
Bb clarinet (very `hooty')
3. Poor tone quality, very uneven
All trumpets (most notes not even recognizable as a trumpet)
4. E2 missing from tuba series; A#1 missing from 9' grand piano, right
pedal depressed (volume 9)
5. celesta recording is very noisy (volume 9)
****************************************************************
* Greg Sandell (sandell@ils.nwu.edu) *
* Institute for the Learning Sciences, Northwestern University *
****************************************************************
------------------------------
Date: Mon, 09 Apr 90 19:03:25 GMT
From: Bernard Bel <BEL@EARN.FRMOP11>
Subject: Handelman quoting Laske quoting Bel
To: music-research@prg
Re: Handelman quoting Laske quoting Bel
Your translation is OK, thanks; except perhaps I don't understand the "(sic)"
you appended to "opinion courante"...
"Learning by imitation": this relates to teaching methods in India. It was
always the teaching process for children, but in the traditional educational
system when a disciple would grow older a systematic teaching was given.
If grown-ups learn by imitation they don't imbibe explicit rules. For instance
I learned French by imitation, therefore I am tempted to say "French spelling i
different if I am requested to formulate the rules.
"Neural nets are only good for perception and memorization": I didn't write tha
although it might prove true in the end.
I wrote that there is an attraction of researchers to the neural computation
paradigm because they pay more attention
to perceptual and memorization processes in music. I agree with you that in
doing so there is a tendency to reduce perception to "pattern recognition" or "
I agree that we can't say anything about networks doing good music until we've
heard something that claims to be network music... Yet it sound a bit like the
joke: "Can you play piano? -- I don't
know, I never tried...". It is
useful to think ahead of empiricists,
taking the risk of underestimating the
value of new methods (e.g. Minsky-Papert's "Perceptrons"). Again, science
learns from its own failures.
("Perceptrons" wasn't a real mistake, but it mistakenly closed a field of
research for a while. There is much to learn from that story...)
"The systematization of creativity through knowledge engineering". My experien
is limited to the modelling of
improvisation schemata in North Indian drumming. My associate Jim Kippen has
shown that this process is less simplistic than assumed by musicologists and
some musicians belonging to that tradition,
although in the end it turns to be
highly systematic and very complex.
I'll send a bibliography of our publications along with the announcement of
the release of the Bol Processor (the
software we used for that study).
LAST COMMENT: I was in India during the discussion on KA. The first message I
found was Laske's good-bye and my quote...
Therefore I cannot sayto what extent
my prose relates to the discussion...
Bernard Bel
------------------------------
Date: 11 Apr 90 21:39:43 GMT
From: Keith Mund <keithm%ashtate%hacgate%elroy.jpl.nasa.gov%sdd.hp.com@edu.ucsd>
Subject: Intonation
To: music-research@prg
Message-ID: <878@ashton.UUCP>
I am seeking information on analysing intonation using a
computer.
Keith Mund
------------------------------
Date: Fri, 6 Apr 90 23:05 EDT
From: FNELSON@edu.oberlin.cc.ocvaxa
Subject: Midi Driver
To: music-research@com.sun.eng.bartok
Message-ID: <9004070333.AA15526@Sun.COM>
Bernard Bel posted a request for help on midi applications. I recently
downloaded a lovely new driver from media-lab.media.mit.edu. It is Joe
Chung's revision of a driver written originally by Lee Boynton. This
driver uses the TimeMgr and can resolve time to 1ms. Here is Joe's
doc file on the subject.
preFORM 3.0 MIDI Driver Source Code
) 1988 Lee Boynton, MIT Media Lab.
The file "MIDI Driver.c" is a source file for THINK C version 3.0p2.
The file "midi.rsrc" contains the current driver resource.
To MAKE a driver:
1. Create a project with Lightspeed C.
2. Choose "Set Project TypeI" from the "Project" menu.
3. Choose "Device Driver". Set the Name to be ".MIDI" and the ID to be 23.
4. Add the Lightspeed C library file "MacTraps"
5. Add the file "MIDI Driver.c"
6. Select "Build Device DriverI" in the "Project" menu.
The resulting file (that you choose contains the driver in its resource fork.
Info about driver:
This driver is a standard Macintosh driver, and should be accessed
through the _Open, _Read, _Write, _Status and _Control traps (these
are the "low level" driver interface calls. They are also known
as PBOpen, PBRead, etc). See Inside Mac for details.
The driver must must be loaded using the resource manager before use.
You first call OpenResFile with the filename "midi.rsrc" (or in Lightspeed,
you name the driver's file the same as your current project + ".rsrc"). Then
you have to call the PBOpen trap with the name of the driver: ".MIDI".
Once you've successfully opened the driver, you must open one or both
of the serial ports (A=Modem or B=Printer). Nothing will happen until you do.
You open these through the a DriverControl call with the control code
OPEN_CODEA or OPEN_CODEB. Now you can read and write to your heart's content.
To read or write to the driver, you pass a pointer to a MIDI_Event (defined
in midi.h) which is a longword time, followed by an event type byte and then
the three MIDI bytes. For reading, the time is the clock time (in 1/100th's of
a second since the driver was opened) that the last byte of the event was
received. For writing, the time is the time that the event should be written.
If the time is in the past or 0, the event is written immediately, otherwise
it is scheduled.
The three types of events are normal, raw, and null. The remaining three bytes
have different meaning depending on whether the event is normal or raw (null
events are only used for reading, and indicate that there is no pending
data). Raw events are for reading or writing raw, unparsed, MIDI bytes. There
is only one byte per raw event, and it is contained in the third byte following
the type byte (i.e. you can think of a whole MIDI_Event as two longwords, the t
ime
is the first, and the event is the second. In this case, the raw byte will be
the lowest order byte of the second longword). More info on raw events below.
If the event is a normal event, then the next byte is always the status byte,
and any data bytes follow in the next two bytes. For example, if the event
has only one data byte (like a monophonic pressure event), then the third byte
following the type byte is just garbage.
The type byte has one additional bit, bit 5 which indicates which port, A or B,
the event originated from or is destined for. In the case of writing, if the
appropriate port is not opened, the event is directed to the open port.
The most common use for raw events are for Sysex. To write a raw event,
specify the RAW_EVENT as the type (the RAW_EVENT type is 0, so that if you
simply blast a single byte at the driver it will blast it out the modem port).
To read a raw event, you must set the read mode of the driver (with the
control call with code READMODE_CODEA or READMODE_CODEB) to be RAW_EVENT.
If the read mode is NORMAL_EVENT, the driver will eat & bury any sysex
received. Thus to receive sysex in the general case, you must change the
read mode of the driver to RAW_EVENT as soon as you see the start of sysex
event. As soon as you see the end of sysex, you should change back to
NORMAL_EVENT. NOTE THAT YOU WILL NEVER SEE THE START OF SYSEX EVENTS AT
ALL UNLESS YOU SET THE INPUT FILTER TO ALLOW THEM!!! (read on).
[There's definitely a bug here. If the sysex stream is interrupted by
a new status byte that is not the end of sysex byte, which can happen in
a merge situation, then the driver is hosed. The right solution is to
pass sysex bytes as raw data if the input filter allows sysex at all. -joe]
The driver has the ability to filter which events are read in NORMAL_EVENT
read mode. This filter defaults to MIDI channel messages only, but you
can set the filter easily enough. The filter is a longword with the bits
defined as follows:
Midi Event Bit No.
Note Off 0
Note ON 1
PolyTouch 2
ControlType 3
ProgramType 4
Aftertouch 5 (MONO of course)
PitchBend 6
SysEx 7
TimeCode 8
Songpos 9
SongSel 10
TuneType 13
EnsSysEx 14
ClockType 15
StartType 17
ContType 18
StopType 19
ActiveSense 21
Reset 22
A high bit means pass that event, a 0 means filter it. Thus the default longwor
d
is: 0x7fL which means filter all messages from Sysex through Reset. You set
the filter through a control call with FILTER_CODEA or FILTER_CODEB.For the
complete list of control and status codes see midi.h and the DriverControl
and DriverStatus functions in Midi Driver.c.
The driver is also capable of running at different clock speeds, down to a
single millisecond. This can be set via TICKSIZE_CODE with the length of a
tick in milliseconds as a longword.
The driver has a few unsupported features such as 25fps MIDI time
code sync, and pitch bend sampling. If you don't use them they won't
bother you.
There is also an example file called Driver Example.c which shows how to
perform the basic driver functions from Lightspeed C. Good luck.
Questions, bugs, etc to :
Joe Chung
MIT Media Lab
20 Ames St
Cambridge, 02139
joe@media-lab.media.mit.edu
The file is mac-midi.sit.hqx on media-lab.media.mit.edu.
==============================
I have incorporated this driver into an application and a desk accessory
with no problems. Joe is using it in a lisp environment and has set the
clock resolution to 10ms. I have used 2ms without problems. Boynton's
earlier driver didn't work well at 1ms because of irregularities in the
TimeMgr. I haven't tried 1ms yet.
Bernard Bel...I tried to reach you directly but couldn't find a path.
Send me mail as fnelson@oberlin.edu or fnelson@ocvaxa and I will tell
you more about what I am doing and, if you like send you some examples.
Gary Nelson
Oberlin College
------------------------------
Date: 9 Apr 90 11:42:14 GMT
From: APPEL Ron <appel%cui%ugun2b%chx400%cernvax%mcsun@net.uu.uunet>
Subject: non computerized music: help
To: music-research@prg
Message-ID: <1770@cui.unige.ch>
What are the news groups dealing with (non computerized) music and opera.
####################################################################
Ron D. Appel appel@medsun.unige.ch
Unite d'Imagerie Numerique appel@cgehcu61.bitnet
Centre d'Informatique Hospitaliere
Hopital Cantonal Universitaire de Geneve
24, rue Micheli-du-Crest ###
CH-1211 Geneve 4 ########
Switzerland ###############
tel.: 41-22-229254 or 229257 ###################
fax : 41-22-476486 ##########################
####################################################################
------------------------------
Date: Mon, 09 Apr 90 07:34:32 PDT
From: Stephen Smoliar <smoliar@edu.isi.vaxa>
Subject: Richard Dawkins and music
To: Music-Research@prg
Cc: alife-request@edu.indiana.cs.iuvax
Message-ID: <9004091434.AA22380@vaxa.isi.edu>
The applicability of systems such as those described by Richard Dawkins in THE
BLIND WATCHMAKER to music have been discussed to a modest extent my members of
the artificial life community. This community has its own electronic
newsletter and some of this material is probably in the newsletter archives.
Further information may be obtained by sending mail to the maintainers of the
newsletter at Internet address alife-request@iuvax.cs.indiana.edu. (Dawkins
is a subscriber, by the way.) Since there are only a few articles on the
subject and since the newsletter is not even half a year old yet, I am
cross-posting this to the list maintainers in the hope that they might
put these articles in a package and submit it to
Music-Research@prg.Oxford.AC.UK.
------------------------------
End of Music-Research Digestlseltzer@phoenix.Princeton.EDU (Linda Ann Seltzer) (04/15/90)
>I am seeking information on analysing intonation using a >computer. > >Keith Mund You need a pitch detector that has enough of a percentage accuracy to be meaningful. That means, you have to test the accuracy of the pitch detector or your results will be meaningless. If you want to measure pitch variations of less than a semitone, then you need to demonstrate that your pitch detector is that accurate. Be prepared for outliers and subharmonics.