Yahoo Tuning Groups Ultimate Backup mills-tuning-list Denis Atadan's Tuning-List Tape-Swap Tape vs. Neil's Proposed CD

In a recent posting, I said (in response to Neil's idea of doing
something kinda similar on CD):

> The tape-swap had several problems that a CD would solve. On the tape it's
> difficult to locate a particular composer and composition, which is espe-
> cially valuable on a contribution/collection work.

Somebody who just now read that replied to me directly, concerned that I
was kinda insensitive to criticize Denis Atadan's work in producing the
Tuning-List Tape-Swap Tape - his work on the liner notes especially.

Ziiiikes! I certainly hope that nobody else got that utterly false
impression. Let me assure all of you about two things:
1. In saying that, I was only referring to the fact that on a CD you can seek
a particular track by number, whereas on a cassette you obviously don't
have that option. I was not by any means suggesting that Denis did anything
wrong with the liner notes.
2. I am very pleased with and grateful for Denis' work on the Tuning-List tape.
I think (and I know that many others feel the same) that it was a wonderful,
pioneering effort. I wouldn't be distributing the tape further if I didn't
believe in it.

So I'll say "thanks Denis for your efforts". You did great!

SMTPOriginator: tuning@eartha.mills.edu
From: mr88cet@texas.net (Gary Morrison)
Subject: Re: instruments -- guitar tuning
PostedDate: 06-01-98 05:19:48
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 06-01-98 05:19:28-06-01-98 05:19:28,06-01-98 05:19:24-06-01-98 05:19:25
DeliveredDate: 06-01-98 05:19:25
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C1256584.0017BDA0; Tue, 6 Jan 1998 05:19:18 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA25759; Tue, 6 Jan 1998 05:19:48 +0100
Date: Tue, 6 Jan 1998 05:19:48 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA25772
Received: (qmail 1384 invoked from network); 5 Jan 1998 20:19:03 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 5 Jan 1998 20:19:03 -0800
Message-Id:
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗"jloffink" <jloffink@...>

> As an Appendix to the discussion paper I had the idea of including a
> list of features/improvements that would specifically benefit
> composers and others who use MIDI and digital audio for alternative
> tunings.
>
> Anyhow, the gist of all this is : my wish list would include things
> like :
>
> Tuning resolution minimum 1 cent, preferably less (any thoughts on
> this?); Number of Partials (Keygroups, Zones) limited by memory only,
> not hard coded into the architecture; Include on-board absolute pitch
> meter (but would put the price up); Macro and template procedures for
> building unconventional `instruments';
>
Tuning resolution of sample/wavetable based instruments better than 1 cent
is questionable since no manufacturer will tune their own samples to better
accuracy than this. This is the issue much more than cost, since adding
the extra resolution in their custom ICs would be insignificant in terms of
design resources and transistors. DSP or Virtual Modeling type instruments
could do better though.

You have to remember that manufacturers need to make a profit in order to
stay in business, and most provide the bare minimum of features that they
can get away with. For instance, MIDI pitch bend has supported 14 bit
resolution for 15 years now, but nobody makes a 14 bit pitch bend
controller except Big Briar, 98% of them are 8 bit, the other 2% are 10
bit.

Building tunings into "Partials", Keygroups or Zones is tedious and
wasteful effort in my opinion. Today's synthesizers support hundreds of
patches/programs, doing it that way virtually hard codes the tuning into
the sample set and increases your memory requirements exponentially. I
don't think there's much question that most users prefer separate tuning
tables, the issues are:

Do you want octave based tables?
Do you want keyboard based tables? (Remember, these are virtually
impossible to retune note by note on the fly, ala Justonic Pitch Palette,
because of the limited MIDI bandwidth)
How many tables do you need?
Are the tables assigned globally or per MIDI channel?
Do you need to switch between tables or notes in realtime, and if so should
notes be updated immediately or on new notes only?
Is the MIDI Tuning Dump Standard supported?

Also, I believe any proposal to manufacturers must be presented in a
prioritized fashion. If given as an all or nothing situation, you're most
likely to get nothing, or else get a confused subset of the requested
features.

The on-board absolute pitch meter is a very, very interesting idea,
especially for a sampler. It would be a benefit for anyone creating their
own samples.

> A kind of `kit' mother keyboard with a large number of movable slots
> into which a user configurable number and arrangement of keys of
> different sizes and colours could be fitted_ And new types of control
> for keys (taking the idea of `after touch' further_)
>
Starr Labs is working on a generalized microtonal MIDI keyboard that
supports polyphonic aftertouch.

SMTPOriginator: tuning@eartha.mills.edu
From: "Patrick Ozzard-Low"
Subject: MIDI/Audio wish list
PostedDate: 08-01-98 14:48:50
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 08-01-98 14:48:28-08-01-98 14:48:28,08-01-98 14:48:22-08-01-98 14:48:23
DeliveredDate: 08-01-98 14:48:23
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C1256586.004BD529; Thu, 8 Jan 1998 14:48:46 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA20094; Thu, 8 Jan 1998 14:48:50 +0100
Date: Thu, 8 Jan 1998 14:48:50 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA20729
Received: (qmail 16262 invoked from network); 8 Jan 1998 05:48:40 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 8 Jan 1998 05:48:40 -0800
Message-Id: <199801081340.NAA11064@imail.norfolk.gov.uk>
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗"Patrick Ozzard-Low" <patrick.ozzard-low.itex@...>

Thanks for all very useful comments John.

> Tuning resolution of sample/wavetable based instruments better than 1 cent
> is questionable since no manufacturer will tune their own samples to better
> accuracy than this.

Yes, the tuning of library sample libraries is very unreliable. Of
course, since these libraries are created/edited with the
sampler units, (that is, unless an external reference is used) they
can be no better than the sampler. So is the argument circular?
Would better resolution therefore have a knock on effect? Probably
not, since the library makers aren't interested in exact tuning. The
question (as I see it) is - is better resolution only needed for
very special purposes, or do a considerable proportion of members of
this list feel it would be valuable? (If the members of this list
don't then surely few will).

> the extra resolution in their custom ICs would be insignificant in terms of
> design resources and transistors. DSP or Virtual Modeling type instruments
> could do better though.

Sorry, what's an IC?

> You have to remember that manufacturers need to make a profit in order to
> stay in business, and most provide the bare minimum of features that they
> can get away with.

Sure. Too bad microtonalist's haven't got alot of economic clout.
The discussion paper, in a round about way, is aiming to do a tiny
bit about that.

> For instance, MIDI pitch bend has supported 14 bit
> resolution for 15 years now, but nobody makes a 14 bit pitch bend
> controller except Big Briar, 98% of them are 8 bit, the other 2% are 10
> bit.

(Aside) Something I've always wondered about is why using pitchbend
from my keyboard (A80) (to the sampler) sounds poor. But retuning
the sample at partial level sounds fine. Please excuse my ignorance
of this stuff.

> Building tunings into "Partials", Keygroups or Zones is tedious and
> wasteful effort in my opinion.

Yes, it's extremely tedious - but my point is that it needn't be,
even on a sampler. Hence the idea of creating on-board macros or
templates to speed up the process. The reason why it's not a waste
of effort (for me) is that I'm creating simulations of acoustic
instruments. The difference between what one can achieve in this
respect on a sampler and a synth is enormous (IMO) - but of course
not everybody is interested in simulation.

>Today's synthesizers support hundreds of
> patches/programs, doing it that way virtually hard codes the tuning into
> the sample set and increases your memory requirements exponentially. I
> don't think there's much question that most users prefer separate tuning
> tables,

Agreed - so would I! And I don't think there's an immutable reason it
can't be done on a sampler! In fact the Roland does have something
which sort of works like this - but not well enough. Since a sampler
is a kind of relational database, there shouldn't be any reason why,
(given 1998 processors et al) the relational mappings need not be
much more flexible and friendly. So, (from my view at least, but I'd
be interested to know if others would like this too), it seems
worth arguing that updating the 'database architecture' would be a
great idea for making the best of the sonic benefits of sampling
(for specific purposes). But, maybe sampling technology will soon be
(successfully) surpassed - let's hope so.

>the issues are:

> Do you want octave based tables?
> Do you want keyboard based tables? (Remember, these are virtually
> impossible to retune note by note on the fly, ala Justonic Pitch Palette,
> because of the limited MIDI bandwidth)
> How many tables do you need?
> Are the tables assigned globally or per MIDI channel?
> Do you need to switch between tables or notes in realtime, and if so should
> notes be updated immediately or on new notes only?
> Is the MIDI Tuning Dump Standard supported?

Great stuff.

> Also, I believe any proposal to manufacturers must be presented in a
> prioritized fashion. If given as an all or nothing situation, you're most
> likely to get nothing, or else get a confused subset of the requested
> features.

Sure. The discussion paper is meant as a kind of think-tank document,
aimed at clarification and encouraging consensus (maybe!). It's not
a proposal to manufacturers.

> > A kind of `kit' mother keyboard with a large number of movable slots
> > into which a user configurable number and arrangement of keys of
> > different sizes and colours could be fitted_ And new types of control
> > for keys (taking the idea of `after touch' further_)
> >
> Starr Labs is working on a generalized microtonal MIDI keyboard that
> supports polyphonic aftertouch.

Do you mean the Microzone - or are Starr Labs producing another
keyboard as well? I hope the distinction between what I suggested
and the Microzone is clear.

Thanks!

Patrick Ozzard-Low

SMTPOriginator: tuning@eartha.mills.edu
From: "Patrick Ozzard-Low"
Subject: New Instruments
PostedDate: 08-01-98 15:02:15
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 08-01-98 15:01:47-08-01-98 15:01:48,08-01-98 15:01:41-08-01-98 15:01:42
DeliveredDate: 08-01-98 15:01:42
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C1256586.004D0F84; Thu, 8 Jan 1998 15:02:11 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA19561; Thu, 8 Jan 1998 15:02:15 +0100
Date: Thu, 8 Jan 1998 15:02:15 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA20997
Received: (qmail 16878 invoked from network); 8 Jan 1998 06:02:07 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 8 Jan 1998 06:02:07 -0800
Message-Id: <199801081355.NAA08526@imail.norfolk.gov.uk>
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗Prent Rodgers <prodgers@...>

My microtonal MIDI explorations began about 10 years ago on an IBM
Music Feature Card, which contained the same chip and fuctions, more
or less, as the Yamaha FB01 external box. This chip allowed for the
creation of up to 8 voices using a 4 operator FM synthesizer. The
sound is cheap and dull by today's standards, but it allowed for very
flexible microtonal work. For every note, you sent a system exclusive
to indicate the pitch and how many cents to detune it. It had no
problem keeping up with very fast passages, even on my 8086 vintage
computer driving it. It is a shame that Yamaha dropped support for
this format of microtonal support. If there still exists a better
sounding sampler or synthesizer that does support this protocol, I
would love to hear about it.

Here is some Pascal code from the program I wrote to drive the card:

WriteToCard(#$f0 + #$43 + #$75 + #$70);

{ Play all the notes you want for as long as you want }
Channel =3D 0;
Tone =3D 64; { 0-127 for each of the normal MIDI Notes }
Cents =3D 0; { 7 bit 2's complement -64 to +64 }
Velocity =3D 64; { normal MIDI velocity data }
WritetoCard(Channel,Tone,Cents,Velocity);

{ When finished, send the following to end the system exclusive }
WriteToCard(#$F7);

Prent Rodgers
Boise, ID
Internet: prodgers@us.ibm.com
=

SMTPOriginator: tuning@eartha.mills.edu
From: "Paul H. Erlich"
Subject: RE: 22TET
PostedDate: 09-01-98 20:55:02
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 09-01-98 20:54:36-09-01-98 20:54:37,09-01-98 20:54:29-09-01-98 20:54:29
DeliveredDate: 09-01-98 20:54:29
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C1256587.006D5C85; Fri, 9 Jan 1998 20:55:00 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA15872; Fri, 9 Jan 1998 20:55:02 +0100
Date: Fri, 9 Jan 1998 20:55:02 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA17702
Received: (qmail 16775 invoked from network); 9 Jan 1998 11:54:54 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 9 Jan 1998 11:54:54 -0800
Message-Id:
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗gbreed@cix.compulink.co.uk (Graham Breed)

Fred Kohler wrote:

> Here's an idea. How about having some "banks" predifined as tunings that
> are in common use such as 19 and 31 TET Valotti+Young and others specified
> as "user".

I think this is fairly common. There's no standard way of
assigning them, but there doesn't need to be!

My tuning priorities are:

1) At least 1/64 semitone steps
2) A full keyboard table
3) The ability to transpose that table differently for each channel
4) At least 0.1 cent steps
5) Multiple tables, easily swapped
6) More than one table active at a time

The TX81Z fulfils the first 3 criteria. The AWE64 Gold fulfils
all except (4) but, until Fred writes the supporting software, it
isn't easy to set up.

The TX81Z also has a good key velocity response, and the timbre
can change gradually as you go up the keyboard. If there are
sample based synths that can do this, they must be difficult to
program. The people who complain about digital synthesis should
really try FM. It's gone out of fashion because most people don't
program it right, and it's no good for imitating other instruments.
In terms of expressivity and versatility, though, it's unsurpassed
in my experience -- which is, admittedly, fairly limited.

SMTPOriginator: tuning@eartha.mills.edu
From: gbreed@cix.compulink.co.uk (Graham Breed)
Subject: Re: 22TET
PostedDate: 10-01-98 20:27:39
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 10-01-98 20:27:09-10-01-98 20:27:10,10-01-98 20:27:00-10-01-98 20:27:01
DeliveredDate: 10-01-98 20:27:01
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C1256588.006AD937; Sat, 10 Jan 1998 20:27:33 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA10038; Sat, 10 Jan 1998 20:27:39 +0100
Date: Sat, 10 Jan 1998 20:27:39 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA10041
Received: (qmail 14612 invoked from network); 10 Jan 1998 11:27:17 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 10 Jan 1998 11:27:17 -0800
Message-Id:
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗Jazzizjazz <Jazzizjazz@...>

On Thu, 8 Jan 1998 00:09:46 -060, "jloffink" wrote:

>Building tunings into "Partials", Keygroups or Zones is tedious and
>wasteful effort in my opinion...doing it that way virtually hard codes the
>tuning into the sample set and increases your memory requirements
>exponentially...

Acknowledging these very valid and important points, I have nevertheless :-)
written a proof-of-concept program to do just this for the AWE32/64 (SoundFont
2.0 banks) in Visual Basic for Win95. Octave-based, 12-tone-only, as the
purpose was to explore historical keyboard tunings. I'd be interested to
discuss (off the list, if that would be more appropriate) issues and ideas
concerning this approach with others of like mind.

Dave Fisher Rybarczyk
jazzizjazz@aol.com

SMTPOriginator: tuning@eartha.mills.edu
From: "Patrick Ozzard-Low"
Subject: MIDI/Audio wish list
PostedDate: 12-01-98 15:09:52
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 12-01-98 15:09:17-12-01-98 15:09:17,12-01-98 15:09:06-12-01-98 15:09:07
DeliveredDate: 12-01-98 15:09:07
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C125658A.004DBFE7; Mon, 12 Jan 1998 15:09:42 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA10851; Mon, 12 Jan 1998 15:09:52 +0100
Date: Mon, 12 Jan 1998 15:09:52 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA10880
Received: (qmail 20062 invoked from network); 12 Jan 1998 06:08:27 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 12 Jan 1998 06:08:27 -0800
Message-Id: <199801121400.OAA12432@imail.norfolk.gov.uk>
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗"Patrick Ozzard-Low" <patrick.ozzard-low.itex@...>

Dear All,

Many thanks for your thoughts on these...

Random, and (sorry) very hurried responses -

Graham Breed wrote

> My tuning priorities are:
>
> 1) At least 1/64 semitone steps
> 2) A full keyboard table
> 3) The ability to transpose that table differently for each channel
> 4) At least 0.1 cent steps
> 5) Multiple tables, easily swapped
> 6) More than one table active at a time

Graham, do you mean 1) and 4) refer to different things? (ie., 4
refers to 3?) Or am being very thick?

General question: How essential is it to differentiate between
sampler and synth 'wish lists'?

Fred Kohler (?) wrote:

> >I'm sure those that are exploring the non-octave based tunings such as Wendy
> >Carlos' Alpha and 88CET would prefer at least having an option other than
> >octave based tables.

Yes, this is an important consideration.

> Ensoniq defines its tuning tables very logically and easily. I would find
>that a good model for others.

> By the way, Ensoniq samplers have pretty good microtonal support.

Gary, would you mind very briefly outlining how the Ensoniq works for
ATS? Supposing you wanted to map the sampler for a '22-ET string
trio' (to use my previous example) - would it be easy?

John Loffink wrote:

>IC = Integrated Circuit =

Thanks John..... duuurrrrr

>I guess I'm confused whether you want more "Partials" to accomplish
>microtonal scales or better sampling.

I want 1) more partials and 2) a way of dealing with them so that a
patch ('instrument') can be set up easily. For example, suppose
you've got a set of 36 samples, one for each (12-ET) note of a three
octave range (say, of bowed violin strokes). And you want to 'build a
violin' in 22-ET (or something) over 3 octaves. Imagine this: select
range of samples (Sample Number 0-35); select range of partials
(Keygroups) 0-65 (3 octaves in 22-ET); select source tuning type
(12-ET); select destination tuning type (22-ET); select preferred
deviation (ie., whether sampler chooses nearest sample to map from
above or below desired destination frequency range - preferably from
above, so destination is not 'mickey mouse' ); press GO. Sampler
creates 66 partials, maps samples 0-35 to said 66 partials, and
retunes accordingly. Impossible?

Result would need to be checked/tweaked by user, but would save
trillions of hours. Window type interface would be nice, but not
essential.

>I was talking about the Microzone, but I can see now the
>distinction. The Microzone has just black or white keys, all one
>size, and no "new" types of control. I'm sure the reason is purely
>economics.

It was the 'Kit' bit that I wanted to emphasise. The idea that the
'slots' themselves would be moveable... I don't really know how
parctical this could be (?)

Must dash,

Patrick Ozzard-Low

SMTPOriginator: tuning@eartha.mills.edu
From: "Loffink, John"
Subject: RE: MIDI/Audio Wish List
PostedDate: 12-01-98 21:25:39
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 12-01-98 21:25:07-12-01-98 21:25:08,12-01-98 21:24:57-12-01-98 21:24:57
DeliveredDate: 12-01-98 21:24:57
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C125658A.00702761; Mon, 12 Jan 1998 21:25:30 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA07986; Mon, 12 Jan 1998 21:25:39 +0100
Date: Mon, 12 Jan 1998 21:25:39 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA17863
Received: (qmail 22230 invoked from network); 12 Jan 1998 12:25:37 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 12 Jan 1998 12:25:37 -0800
Message-Id:
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗mr88cet@texas.net (Gary Morrison)

>Gary, would you mind very briefly outlining how the Ensoniq works for
>ATS? Supposing you wanted to map the sampler for a '22-ET string
>trio' (to use my previous example) - would it be easy?

First of all, Ensoniq's "pitch tables" cover the full range of MIDI
key#s, each independent of the others. Each key may have any arbitrary
pitch you'd like it to, irrelevant of the pitches you assign to any of the
other keys. (Well, each key's pitch is arbitrary within available pitch
resolution of course.) Each instrument may have as many as 8 pitch tables
(although selecting more than four rapidly is a bit tricky).

To set up a repeating pattern of pitches, such as 12-Toned Ptolemaic JI
in C, you enter the pitches for the keys C4 through C5. You would set, for
example, E4 14 cents flat of the 12TET reference. (Actually, that's not
exactly true; you specify pitches between 0 and 99 cents above whatever
12TET pitch reference lies directly below it, so you'd define the E4 key
top play an Eb4 86 cents sharp.) Notice that you set the pitch of both of
the C4 and of the C5, the C5 being an octave higher than the C4.

You then tell it to "extrapolate" the pitch table from C4 to C5. That
causes it to duplicate the pattern of pitches between C4 and B4 upon the
pitch you chose for C5, and again on C6, C7, C3, C2, etc.

In my 88CET tuning scheme, what looks visually on the keyboard to be an
octave, instead spans a 7:4 (88CET's very-close approximation that is). So
in 88CET I set C4 and C5 to be 7:4 apart, and when I extrapolate the table,
I get something that repeats in 7:4s instead of octaves.

Now, 22TET... You have a very basic question to answer before you can
set it up. What keyboard mapping do you want? How do you want pitches in
the tuning to map to keys on the keyboard? A common way is to map them
"linearly", each key 1/22nd of an octave apart, mismatching octave
boundaries in the tuning with those on the keyboard. If that's the way you
want to map it, then set the pitches of the keys C4 through Bb5 to
successive 22nds of an octave, and extrapolate your table from C4 to Bb5.

Many of Ensoniq's "synthesizer" series, like their VFX (and
unfortunately unlike their samplers), have an additional pitch-table
function called "interpolate", which creates equal divisions. So, to tune
22TET on the VFX, you...
1. Tune Bb5 to an octave above C4.
2. Interpolate the tuning between C4 and Bb5. This sets the 22 pitches between
those two keys to successive 22nds of an octave apart.
3. Extrapolate the tuning from C4 to Bb5. This duplicates the 22TET tuning
that "interpolate" created between C4 and Bb5 across the whole MIDI range.

An alternative to mapping keys linearly is to break the tuning into
several 12-toned subsets that can be mapped on octave boundaries, and
switch off between them using the patch-select keys.

SMTPOriginator: tuning@eartha.mills.edu
From: mr88cet@texas.net (Gary Morrison)
Subject: Re: MIDI/Audio wish list
PostedDate: 13-01-98 03:24:53
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 13-01-98 03:24:17-13-01-98 03:24:18,13-01-98 03:24:07-13-01-98 03:24:07
DeliveredDate: 13-01-98 03:24:07
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C125658B.000D34AA; Tue, 13 Jan 1998 03:24:43 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA23219; Tue, 13 Jan 1998 03:24:53 +0100
Date: Tue, 13 Jan 1998 03:24:53 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA23293
Received: (qmail 23676 invoked from network); 12 Jan 1998 18:24:52 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 12 Jan 1998 18:24:52 -0800
Message-Id:
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗mr88cet@texas.net (Gary Morrison)

🔗gbreed@cix.compulink.co.uk (Graham Breed)

Dave Fisher Rybarczyk wrote:

> Acknowledging these very valid and important points, I have nevertheless :-)
> written a proof-of-concept program to do just this for the AWE32/64 (SoundFont
> 2.0 banks) in Visual Basic for Win95. Octave-based, 12-tone-only, as the
> purpose was to explore historical keyboard tunings. I'd be interested to
> discuss (off the list, if that would be more appropriate) issues and ideas
>concerning this approach with others of like mind.

This sounds like exactly what we've been looking for! Get it to
work with full keyboard tunings -- using Scala files as input
would be the simplest way.

The additional memory requirements won't be that great, because
you don't need any new samples. There may still be a problem
with the AWE32 because it has such a small RAM.

The program I want asks for a Sound Font file, a tuning file and
a destination bank. It then copies every preset from bank 0 into
the new bank, and alters it to implement the tuning. It sounds
like you've done the difficult work already.

When I posted a list on this thread before, I should have said
that it is prioritised. I use all the tuning features on my
TX81Z, so it would be inconvenient to work with anything less. It
would be nice to at least experiment with much higher precision,
but I don't expect it'll make much difference. It's possible that
I might one day start writing in highly complex JI that requires
more than one transposed table to be used in a piece, but that's
very much in the future.

SMTPOriginator: tuning@eartha.mills.edu
From: gbreed@cix.compulink.co.uk (Graham Breed)
Subject: Re: Tritone ratios
PostedDate: 13-01-98 19:49:01
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 13-01-98 19:48:29-13-01-98 19:48:29,13-01-98 19:48:17-13-01-98 19:48:17
DeliveredDate: 13-01-98 19:48:17
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C125658B.00674DD3; Tue, 13 Jan 1998 19:48:50 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA06055; Tue, 13 Jan 1998 19:49:01 +0100
Date: Tue, 13 Jan 1998 19:49:01 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA06039
Received: (qmail 29360 invoked from network); 13 Jan 1998 10:48:08 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 13 Jan 1998 10:48:08 -0800
Message-Id:
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu

🔗"Patrick Ozzard-Low" <patrick.ozzard-low.itex@...>

John Loffink wrote:

>> My point is that it is not
> >necessary to do this by using more "Partials" (I hate Roland's usage of that
> >term, which is why I always put it in quotes) or zones if the instrument
> >supports microtuning tables. The microtuning table, if implemented properly,
> >will do the mapping for you, automatically, without all the recompilation and
> >excessive memory usage. Granted, you will not have precise control at a less
> >than semitone level of how the samples are mapped, but is this really
> >necessary? You will get "mickey mouse" effects no matter where your base
> >sample was recorded at, this is the effect of shifting the formant (fixed
> >resonant) frequencies of the sample.

Regarding Mr Mickey Mouse: On the Roland, if you want to preserve a
any kind of realistic quality of timbre the upper limit of
transposing a sample from its original sampled pitch is about a
minor third (up), and a major third down - depending on the timbre.
In my own case, I typically use a sample mapped to no more than about
150 cents BELOW the original sampled pitch, but very seldom
transposed upward. This is more than adequate for my purposes
(local friends think I'm too fussy) and there is no 'mickey mouse'
effect within these limits.

(Of course, you can get away with more than this if realism
is not important, - or you can do away with realism altogether and
transpose up (as far a two octaves) - and down (as far as you like).
The E4 is slightly better better at preserving realism over a wider
range, but by no more than a semitone. It can also transpose upward
over a much greater range, I believe).

> >Increasing the number of "Partials" will not solve your problem,
> >because you'll have a new one -- the sampler's internal RAM will
> >not have enough storage to handle the increase. Program parameters
> >are most likely to be stored in 64K to 512K local RAM inside the
> >unit, not your 32M to 128M sample RAM. If you now ask
> >manufacturers to increase the local RAM just for microtonal
> >support, I can tell you that none of them will do it because that
> >increases the price of the hardware.

Sorry, John, this is wrong. Increasing the number of 'partials' has
no effect on the used sample RAM on the Roland or AKAI systems. (It
does on the EMU, but, as I understand, so little that it is
negligible). On the Roland - suppose there are 4 samples in memory,
of flute tones, Eb4, F#4, A4 and C5; and that they take up 2Mb. You
then create a 'one octave 41-ET' flute, by creating 41 'partials'
which map each of 3 samples to 10 divisions of the scale, and the 4th
sample to the remaining 11 divisions, such that you can now play this
scale over 3 and a bit standard-keyboard-octaves. The mapping from
sample to 'partial' is one-many, and you've still only used 2Mb RAM.
On the Roland there is no limit to the degree of one-many-ness,
excepting the limits on samples and 'partials' (512 and 255
respectively). (Actually this is not quite right - the relation is
many-many, except that the maximum number of samples that can be
associated with any one 'partial' is 4.)

For your interest, there is also a 'micro-key-follow'
tuning facility in the Roland S7XX series, whereby you can
'interpolate' (to use Gary's 'Ensoniq' terminology) a 'partial'
across the (any part of the) keyboard in 1/8ths of a semitone, 2/8 of
same, 3/8, 4/8 (quarter tones), 5/8,7/8, 8/8 (12-ET), 9/8, etc up to
16/8 of a semitone (whole tones).

> >I'm sorry if this is getting too technical again, but you can't really
> >understand the ramifications of your requests without a little understanding
> >on how today's synthesizers and samplers work. My points are 1) for
> >microtonal scales to be implemented in mass produced instruments it must be
> >economically realistic for the manufacturers to do so, and 2) for microtonal
> >scales to be used by non-specialists it must be as easy as possible for them
> >to be changed. You can't accomplish either of these by defining microtonal
> >scales at the "Partial" or zone level.

I agree entirely with the general points 1 and 2. I'm unconvinced
however about the last sentence of this paragraph. Samplers, if used
for anything approaching realism, will require significant amounts of
RAM whatever the 'partial'/zone architecture etc, at least until
some form of data compression of the 16 bit format is introduced (or
something). The fact that EMU have implemented 128Mb on the E4
seems to confirm this - they didn't build it for composers working
with ATS. More 'partials' does not mean more RAM; on the Roland
(at least) only samples take up sample RAM.

But I suspect you may have other (good) reasons for saying what you
do (?).

Gary Morrison wrote:

> To set up a repeating pattern of pitches, such as 12-Toned Ptolemaic JI
> in C, you enter the pitches for the keys C4 through C5. You would set, for
> example, E4 14 cents flat of the 12TET reference. (Actually, that's not
> exactly true; you specify pitches between 0 and 99 cents above whatever
> 12TET pitch reference lies directly below it, so you'd define the E4 key
> top play an Eb4 86 cents sharp.) Notice that you set the pitch of both of
> the C4 and of the C5, the C5 being an octave higher than the C4.

Thanks, Gary. I've seen this sort-of kind-of thing on various
synths. Can I ask a further question? I understand what you have
described, that is if you want one single sound (either a synthesised
sound or a sample) mapped to this kind of 'key-table'. But, on the
Ensoniq sampler, if you want to achieve some simulatory realism
do you have to laboriously map each sample to a point or points on
the key-table - or is that not something that can be done (or is nor
worth the trouble etc)? (Please excuse me, I'm aware of being
very biased toward wanting realism. I know that's not what everyone
wants - and it should not bias this discussion. But it's what
interests me about these machines!)

> Now, 22TET... You have a very basic question to answer before you can
> set it up. What keyboard mapping do you want? How do you want pitches in
> the tuning to map to keys on the keyboard? A common way is to map them
> "linearly", each key 1/22nd of an octave apart, mismatching octave
> boundaries in the tuning with those on the keyboard. If that's the way you
> want to map it, then set the pitches of the keys C4 through Bb5 to
> successive 22nds of an octave, and extrapolate your table from C4 to Bb5.

In my work I've created simulations of many of the standard
orchestral instruments for every n-ET between 13 and 36, (and some
others above, especially 41) in each case creating a single
partial-sample relationship for each pitch (!). Creating them is one
thing - learning to play them all is another! In most cases the
keyboard mapping I've used is simply 'keyboard-chromatic', since I
get used to re-remembering where the octaves (and everything else)
are. Anything less than but near to a multiple of 12, I cheat a bit,
and ditch a key somewhere.

Patrick Ozzard-Low

SMTPOriginator: tuning@eartha.mills.edu
From: Aline Surman
Subject: Surman/b5 ratios
PostedDate: 15-01-98 00:34:56
SendTo: CN=coul1358/OU=AT/O=EZH
ReplyTo: tuning@eartha.mills.edu
$MessageStorage: 0
$UpdatedBy: CN=notesrv2/OU=Server/O=EZH,CN=coul1358/OU=AT/O=EZH,CN=Manuel op de Coul/OU=AT/O=EZH
RouteServers: CN=notesrv2/OU=Server/O=EZH,CN=notesrv1/OU=Server/O=EZH
RouteTimes: 15-01-98 00:34:22-15-01-98 00:34:22,15-01-98 00:34:09-15-01-98 00:34:09
DeliveredDate: 15-01-98 00:34:09
Categories:
$Revisions:

Received: from ns.ezh.nl ([137.174.112.59]) by notesrv2.ezh.nl (Lotus SMTP MTA SMTP v4.6 (462.2
9-3-1997)) with SMTP id C125658C.00817A61; Thu, 15 Jan 1998 00:34:43 +0100
Received: by ns.ezh.nl; (5.65v3.2/1.3/10May95) id AA02348; Thu, 15 Jan 1998 00:34:56 +0100
Date: Thu, 15 Jan 1998 00:34:56 +0100
Received: from ella.mills.edu by ns (smtpxd); id XA02386
Received: (qmail 17326 invoked from network); 14 Jan 1998 15:34:52 -0800
Received: from localhost (HELO ella.mills.edu) (127.0.0.1)
by localhost with SMTP; 14 Jan 1998 15:34:52 -0800
Message-Id: <34BD5343.695@dnvr.uswest.net>
Errors-To: madole@mills.edu
Reply-To: tuning@eartha.mills.edu
Originator: tuning@eartha.mills.edu
Sender: tuning@eartha.mills.edu