Yahoo Tuning Groups Ultimate Backup makemicromusic Re: [MMM] ultimate instrument

> > We have a wishlist.
> > <http://www.microtonalsynthesis.com/architectures.html>
>
> OK, I'l be the first to start on talk about updating
> this, which I have seen before but am not sure where it
> came from or who the 'we' was that came up with it:

I generated the list based upon input from the tuning list. I realize
that opinions will differ. I wrote this after seeing some
recommendations implemented for very specific circumstances. In some
cases these requests can be counterproductive as manufacturers get
different requests from different users, some of them contradictory with
one another. The list was intended to make things easier for the
manufacturers while accommodating the widest range of needs. It was also
based upon my knowledge of how these instruments are usually designed,
so that everything in the list should be feasible.

> --
> > The advanced architecture
>
> >* 128 or more full keyboard or 12 note octave microtuning
> tables
>
> The word 'or' here really troubles me as a manufacturer
> will see that and say 'well then, we'll just do the 12
> note octave one since it uses less memory'. 12 note
> octave instruments are completely useless to me and
> many other microtonalists and I really don't think we
> should be encouraging ANYTHING other than full keyboard
> arbitrary microtuning. Nothing else is acceptable in
> the sense that I wouldn't buy it or be able to use it.
>

Sorry, this is a typo that obviously escaped me as even the moderate
architecture recommends both full keyboard and 12 note scales.

> >* tables are stored globally and assigned per part, track or
> MIDI channel
>
> I don't see why this is recommended. I would prefer by
> PATCH. That way my bagpipe has a bagpipe tuning and my
> gender is tuned to sulendro.
>

This one is easy. The Ensoniq EPS, EPS16+ and ASR-10 have patches
stored per patch. Guess what? Because these tables take up so much room
in RAM, they end up getting limited in quantity. Use more than eight
microtunings and you have to create an entirely new instrument
_including_all_samples_, which is a huge drawback. Yes, it'd be nice to
have as many tunings per patch as desired, but this would require
manufacturers to create their patches with a "linked list" type
structure, and most of them simply aren't architected that way. Asking
them to completely re-architect for microtuning support won't happen.

Global tunings assigned per patch also greatly simplifies housekeeping
of patches. If you have an instrument with 1000 patches, do you really
want to copy or create from scratch every tuning that you use?

> >* tables can be selected using short SysEx messages or the
> MIDI Tuning Standard
>
> OK, I believe this is part of the 2nd ed of the MIDI
> Tuning Standard.
>
> >* keyboard tables tunable per note over the entire MIDI range
>
> Certainly should be full keyboard retunable -- or at
> least over the range that the instrument uses. Absolute
> requirements on specific frequencies at the outlying
> range I caution against as such a demand will work
> against us here, requiring some instruments to
> implement new custom chips.
>

This would be a good clarification of the request, though in reality
most instruments can transpose as far as you want, it just won't sound
good.

> > * octave tables tunable +-100 cents per note including the
> tonic
>
> I think it is a bad idea even to suggest including such
> an extremely limited feature. Be careful what you ask
> for you might get it - and only it.
>

I should include some reasoning behind the 12 note per octave tunings.
This helps support adaptive tuning software such as Justonic's Pitch
Palette. You cannot do adaptive tunings using full keyboard tunings over
MIDI, because you cannot transfer that amount of MIDI data without
interrupting the note timings.

> >* octave tables include assignable tonic note
>
> > * 0.0061 cent or best pitch resolution
>
> This recommendation seems OK (that's the MIDI Tuning
> Standard resolution right?) but seems to work against
> the implication of 1 cent resolution contained in the
> +/-100 cent request. I'll note that the actual pitch
> *precision* will be determined by the resolution of the
> hardware's phase increment register, which is
> proportional to frequency.

I'm not sure why +-100 cent tuning implies 1 cent resolution.

I'm well aware of the phase increment limitations. The request for
.0061 cent resolution gives manufacturers a hint that these need finer
resolution. Perhaps I should just spell that out? However, that's
usually not the limiting factor. The majority of synthesizers on the
market are multi-sample based. These multisamples are tuned to
accuracies on the order of 1-3 cents typically. Once a multisample is
tuned this badly, you cannot correct it with a finer resolution tuning
table unless you want to fine tune every single instrument for every
single tuning.

>
> >* Fine pitch detuning for oscillators or samples can be
> specified in cents or Hertz
>
> OK -- but how would this work?
>
> You have Oscillator A & Oscillator B.
>
> Oscillator A is set to "freq=1.0 det=0.0" which
> -really- means A=440Hz. Now if we set Oscillator B to
> "freq=1.0 det=+6Hz" -- what does that mean?? Does that
> mean that *whatever* pitch the fundamental of
> oscillator A is generating, the fundamental of B should
> be 6 Hz above it? That means that B's pitch will *vary*
> in cents depending on the pitch height of oscillator A.
> This is a rather esoteric and difficult to implement
> feature, as well as being somewhat ambiguous in its
> realization.

Kurzweil K2x00 implements Hertz detuning as an option. It tracks over
the keyboard, so a constant rate of beating occurs over the entire
range.

>
> >* full keyboard tables can be dumped and loaded using the MIDI
> Tuning Dump Standard and to local storage
>
> OK.
>
> >* 12 note octave tables can be dumped and loaded using SysEx
> and also to local storage
>
> Please, no more talk of '12' and 'octave' in the
> context of "Advanced Tuning Features". One would not
> even be able to tune a piano patch properly with such a
> castrated 'feature'.
>

See my comments above about adaptive tunings. They simply cannot be
accomplished in real time over MIDI using full keyboard tables, so yes,
they are advanced features.

> >* tuning is updated either instantly or for new notes only
> when changing tables, selected globally
>
> Yes this is a nice feature. I think the reason that it
> is specified as optional in the MIDI Tuning Standard is
> that some of the hardware can not support it.
>
> Might be nice in a 'wish list' to make this choice a
> parameter that is included in the table change method
> so a composer can select either oen from his/her
> sequence, depending on the compositional needs.
>
> --------
>
> Now, I want to say that if this is really a wish list
> it's time to update it. Everything here is in the
> context of fixed gamut tunings. This is old news and
> not what is needed for the next generation of
> instruments.

Again, see the above about using 12 note tuning tables for adaptive
tuning.

>
> Here are bare requirements:
>
> 1. All instruments should provide support for midi mode
> 'omni on mono on' also known as 'guitar mode', where a
> single patch voice recieves note on and pitch bend
> messages on separate channels 'per string' instead of
> on one channel. And when recieving a pitch bend before
> a note on, the new note should not glide or squeak as
> it does in some instruments. This feature will allow
> programs like Robert's fts to take total control over
> tuning.
>
> 2. All 14 bits of pitch bend recieved over MIDI should
> be decoded and applied to tuning, even if the physical
> controller is only 7 or 8 bits.

While I might like to see these features, I do not agree that asking for
them in the context of microtuning requests is productive. If
manufacturers are going to implement features just for microtonalists,
why not just request tuning support instead of limited monophonic
support using pitch bends?

>
> Here are wish list requirements:
>
> All instruments should provide support for midi
> processing plugin modules using a standard API, and
> provide a developers kit for the development of such
> modules (ie compiler for the synth's controller chip)
> and a mechanism through sysex by mhich they can be
> updated. I strongly recommend VSTi as the API. These
> modules can be stored in an internal plugin patch area
> so that the extended functionality can exist in the
> instrument on stage, freed from a computer.
>
> This is what we really need. With this, people can
> write tuning processing modules that implement whatever
> realstime retuning system desired, and upload them to
> their instruments, and perform in public without having
> to use a unreliable crash prone PC.
>

This will never happen with hardware synths. Manufacturers will never
give access to the synth controller chip, as this would give away too
much of their intellectual property to their competitors. They will not
release developer kits because this implies support of a tool that they
have no resources to support. Finally, they will not re-architect their
entire synth/MIDI engine just to accommodate requests from
microtonalists. Making realistic requests based upon the lowest possible
impact to synthesizer engineering development gives us the best options
for success.

John Loffink
jloffink@...
one@...

> Hm, that's weird. When I think of per-patch support,
> what I mean is that there is a bank somewhere with your
> 12 or 16 or 128 tunings. Then, in each patch, there is
> a single byte that selects the tuning. So tuning # 41
> can be your usual bagpipe tuning & you have all your
> bagpipes set to tuning #41. If you want to change the
> tuning of all the bagpipe patchs, just change the
> tuning stored in tuning slot #41.

We're talking about the same thing.

> > Global tunings assigned per patch also greatly simplifies
> > housekeeping of patches.
>
> 'Assigned per patch' ... OK, so are you then suggesting
> on your page exactly what I just said? If so I agree
> with you but the way it is described didn't suggest to
> me that that's what it was...

Yes.

> I do understand that, but why limit it to 12 note
> octave tunings? Why not allow the user instead to send
> a message defining N notes, starting at any note number
> desired. The system then extrapolates the scale by
> transposing. Would take about the same bandwidth as the
> 12 octave thing but would be substantially more
> versatile. This should be the way the standard short
> tuning messages work instead of being constrained to an
> octave and 12 tones.

Theoretically this could be the best way to do it, but realistically the
more realtime processing you add the more unlikely it is that your
request will be met. Extrapolating scales on the fly seems simple in
conception but you have to understand the limited hardware that these
synthesizers run on. When they start managing execution of 64 to 128
voices they simply don't have extra processing time for more complicated
functions. That's why I recommend what amounts to simply move
instructions by use of a 12 note scale definition.

> > I'm not sure why +-100 cent tuning implies 1 cent resolution.
>
> As opposed to +/-100.0 or 100.000.
> I think that a manufacturer reading that could infer 1
> cent resolution unless made super clear.

Okay, good point. I did once have someone write to me that they
couldn't do the just intonation scales at my site because their
synthesizer couldn't be tuned to four decimal places as denoted in my
tuning tables.

> > However, that's usually not the limiting
> > factor. The majority of synthesizers on the market are
> > multi-sample based. These multisamples are tuned to
> > accuracies on the order of 1-3 cents typically. Once a
> > multisample is tuned this badly, you cannot correct it with a
> > finer resolution tuning table unless you want to fine tune
> > every single instrument for every single tuning.
>
> OK but that's a different issue.
> Not sure if its true that the majority of synthesizers
> on the market fit this 3 cent thing, but I can believe
> that its true of some or many.

It's true of every wavetable synthesizer and sampler on the market.
There is more hope for DSP Analog Modeled instruments, but most of these
don't even support tuning tables.

> > See my comments above about adaptive tunings. They simply
> > cannot be accomplished in real time over MIDI using full
> > keyboard tables, so yes, they are advanced features.
>
> They can be accomplished with single note retunings,
> which would be a more versatile thing to request.

I concur, single note retunings might be better, but it depends how you
want the notes to change over time. In practice it seems easier to
change the whole scale at once, otherwise you must individually insert
note retuning requests in your MIDI file. I will have to think about
this some as it should be a part of my recommended architectures.

> And I still think that the short tuning message should
> not be constrained to 12 or octave since there is no
> need to do so.

This one accommodates the manufacturer. Many of them use just 12 note
tables, then transpose for octaves. It is often built into the
synthesizer ASICs and may not be oversome by software. When bringing
out new synthesizers the same designs are leveraged over again.
Kurzweil, Emu, Roland, et al have basically been using the same designs
for over 10 years. This wills not change just based upon our requests.

> Yes I understand that issue but what do you think about
> my own perspective and suggestions?

Your suggestions are very good and valuable. From an ideal
implementation perspective they may be better than my recommendations.
I've tried to factor in the man-hours it will take manufacturers to
develop these ideas so that it's something that they can reasonably
accomplish.

> Because making sure the pitch bends work properly
> allows for the adaptive tuning and does not represent
> any additional hardware cost. I'm not suggesting that
> it be done to the exclusion of proper short and long
> fixed tuning table support, but this level of control
> is really the only way possible on a standard MIDI
> interface to get adaptive tuning without substantial
> delay -- even the simple 12 note tuning table has delay
> that a great many performers would find totally
> unacceptable. This is avoided using pitch bends which
> add a 1 ms delay to the notes but do so consistently,
> not destroying the groove like erratically interspersed
> tables do.

Then single note retuning commands would support the adaptive tunings
without the polyphony limitations.

You might approach the pitch bend request from a non-tuning perspective.
Everybody could benefit from this, as stair stepping is a side effect of
7-8 bit pitch bend resolution and a wide pitch bend range.

> Perhaps but many manufacturers buy their chips rather
> than roll their own. And in the future we may find all
> synths running standard risc chips anyway.

Yamaha, Korg, Roland, Emu-Ensoniq and Kurzweil all make their own chips.
Sound card companies may buy their chips rather than roll their own, but
to the best of my knowledge all of these chips have incorporated equal
tempered tuning into the ASICs. Microtuning won't be possible with
them.

> Besides, all the proprietary stuff is patented. Yamaha
> had no fears lending their OS listing for the DX7 to
> Grey Matter Response to add the tuning board add on.

No, all the proprietary stuff is not patented. It's too expensive to
patent everything. The Yamaha case you cite happened twenty years ago.

> Their are significant advantages to opening up the
> architecture. Consider video games. Let others design
> the content, the hardware company just sells the host.

See Chameleon.

> Anyway my suggestion only starts at the level of a
> plugin supporting midi filtering through the vst
> interface. Allowing vsti instruments would be a nice
> next step and I think this sort of thing will happen in
> the future but for the tuning stuff only need access to
> the midi stream.
>
> > They will not release developer kits because this implies
> > support of a tool that they have no resources to support.
>
> Not necessarily -- can let it out there as is without
> support. Some sound card manufacturers have done such a
> thing and created thriving add on development
> communities.

The sound card market is much different from hardware synthesizers. In
any case, note that no current sound card supports microtuning.

> > Finally, they will not re-architect their entire synth/MIDI
> > engine just to accommodate requests from microtonalists.
>
> We might as well give up now! Tuning support is jsut
> too hard!
>
> Why be so pessimisitic? Is this a wish list or not?

So for me the glass is half empty and for you it is half full. :-)

An ideal wish list, free of all constraints, would be an excellent idea.
That's not my list. Mine takes into account both perspectives, the
microtonalist and the manufacturer. It takes into account my knowledge
of how these instruments are built, as well as the business behind them.
Perhaps I could add one more advanced list considering the growing
popularity of software synthesizers and their open ended nature.

If you really want microtuning support, what we need are more well-known
microtonalists such as Wendy Carlos or Robert Rich selling thousands of
CDs. Synth manufacturers have responded to the
dance/house/trance/techo/rap crowd with instruments that serve these
needs. They won't spend hundreds of people-hours developing microtonal
support if they believe there will be no significant adder to sales for
this effort. There's more than just making the request, we have to make
it worthwhile for them to add these features.

> Well, the lowest possible impact is certainly no tuning
> support...

Exactly, and by making high impact requests of hardware manufacturers
that is exactly what we will get.

John Loffink
jloffink@...

Re: [MMM] ultimate instrument

🔗Rick McGowan <rick@...>

🔗John Loffink <jloffink@...>

🔗John Loffink <jloffink@...>

🔗paulerlich <paul@...>