Yahoo Tuning Groups Ultimate Backup makemicromusic [MMM] VSTi's and microtonality?

Timo Toivonen asked:

> Does anyone know of a software (preferrably a VST-plugin/synth)
> where one could map the midi keys with one's own arbitrary
> frequencies (or supply the synth with a tuning file).

Yes. If you want an all-in-one solution for tuning & testing, try the
Midicode synthesizer, which is also very inexpensive (not VST, but
completely standalone): http://www.midicode.com
Midicode has a great tuning interface and tools, and tutorial, etc.

Yes, for VST: Rhino, Angelina, and Rainbow from Big Tick Audio. Also the
Anamark synth. Also VAZ Modular from Software-Technology.com. They *all*
support identical ".tun" files which can be generated with Scala, and used
with all the synths.

http://bigtick.pastnotecut.org/index.php
http://www.software-technology.com/
http://www.anamark.de/about_e.htm

Then, get Scala to make tuning files for those synths.
http://www.xs4all.nl/~huygensf/scala/

For spectrum/frequency analysis, there are several VST modules available.
Try this one: http://ourworld.compuserve.com/homepages/NickWhitehurst/
I like it pretty well. Also for oscilloscope, try sMexoscope from
smartelectronix.com.

Try looking at KVR-VST.com if you want to search for VST plugin tools.

Also see the ZR-3, an open-source VST soft synth (organ emulator):

http://zr-3.sourceforge.net/

If you are a prgorammer,it might be easy enough for someone to drop in the
Anamark tuning source, which is available here:

http://www.anamark.de/files/tuning.zip

Cheers,

Rick

🔗Kalle Aho <kalleaho@...>

🔗paolovalladolid <phv40@...>

🔗Alison Monteith <alison.monteith3@...>

🔗Kalle Aho <kalleaho@...>

🔗paolovalladolid <phv40@...>

--- In MakeMicroMusic@yahoogroups.com, "Kalle Aho" <kalleaho@m...>
wrote:
> --- In MakeMicroMusic@yahoogroups.com, "paolovalladolid"
<phv40@h...>
> wrote:
> > However, FM7 cannot read Scala tuning files directly. It
> reads .syx
> > (MIDI System Exclusive) files and can receive MTS messages. You
> must
> > use a utility such as Max Magic Microtuner or Lil' Miss Scale
Oven
> to
> > convert Scala files to MTS or .syx.
> >
> > That said, FM7 is a fine synth and I think most folks can live
with
> > the little extra step in loading microtunings into FM7.
> >
> > Paolo
>
> Huh? My copy of FM7 reads Scala tunings as midi files. I just save
> them as .mid-files and then load them in as SysEx. It really
actually
> works! You know, this is really weird. Do you use Mac or PC? I use
> PC.
>
> Kalle

I use Mac OS X. There's no GUI version of Scala for Mac OS X -
command line only. With the free Max Magic Microtuner available (and
with a GUI too), I have no need to use the Scala application itself,
just the files.

Paolo

🔗pasport197 <pasport197@...>

🔗Rick McGowan <rick@...>

"pasport197" wrote:

> Similar thing happened with z3ta+ there was a long disscussion about
> it on KVR forums which came down to: "Scala format is much better so
> there's no need for .tun support".

Ridiculous. I don't see this point at all. Scala is generalized for
producing scales, while .tun format is a specific list of frequencies tied
to specific MIDI notes. I don't see how Scala's input format can
effectively be used as a tuning file.

Let's say I have generated a set of 128 random frequencies. I want to
assign those frequencies onto the 128 MIDI notes. In .tun format, I just
assign them one per note. How can you do that in Scala's input format?

Tunings which are completely irregular, such as some gamalan tunings that
I've used, don't seem to be constructable in Scala. Or maybe I just don't
know enough about Scala input files...

Furthermore, there are bound to be bugs and inconsistencies in any synth's
implementation of Scala input format that cause it to have different
results from Scala itself.

Rick

🔗pasport197 <pasport197@...>

Right on! I'm in a similar situation.
Here's the actual topic:
http://www.kvr-vst.com/forum/viewtopic.php?t=20048
But honestly, now that Cube and Tera is out, I don't care about z3ta
that much even though I paid for it(anyone wanna buy it from me?).
Absynth with .tun support would really make my day though, that's for
sure :)

--- In MakeMicroMusic@yahoogroups.com, Rick McGowan <rick@u...> wrote:
> Ridiculous. I don't see this point at all. Scala is generalized
for
> producing scales, while .tun format is a specific list of
frequencies tied
> to specific MIDI notes. I don't see how Scala's input format can
> effectively be used as a tuning file.
>
> Let's say I have generated a set of 128 random frequencies. I want
to
> assign those frequencies onto the 128 MIDI notes. In .tun format, I
just
> assign them one per note. How can you do that in Scala's input
format?
>
> Tunings which are completely irregular, such as some gamalan
tunings that
> I've used, don't seem to be constructable in Scala. Or maybe I just
don't
> know enough about Scala input files...
>
> Furthermore, there are bound to be bugs and inconsistencies in any
synth's
> implementation of Scala input format that cause it to have
different
> results from Scala itself.
>
> Rick

🔗Carl Lumma <ekin@...>

>> Let's say I have generated a set of 128 random frequencies. I want
>> to assign those frequencies onto the 128 MIDI notes. In .tun format,
>> I just assign them one per note. How can you do that in Scala's
>> input format?

Hi Rick,

There's no need to say "input", it's just "Scala format" or "scl
file". A scl file plus a keyboard map gives you everything you
need to generate a tun file, which should be obvious since Scala
can do this.

>> Tunings which are completely irregular, such as some gamalan
>> tunings that I've used, don't seem to be constructable in Scala.

Pretty-much anything is constructible in Scala, if by no other
means than entering the intervals!

>> Furthermore, there are bound to be bugs and inconsistencies in
>> any synth's implementation of Scala input format that cause it
>> to have different results from Scala itself.

Why? It's an utterly trivial conversion.

[pasport197 writes...]
>Right on! I'm in a similar situation.
>Here's the actual topic:
>http://www.kvr-vst.com/forum/viewtopic.php?t=20048
>But honestly, now that Cube and Tera is out, I don't care about z3ta
>that much even though I paid for it (anyone wanna buy it from me?).
>Absynth with .tun support would really make my day though, that's for
>sure :)

In that thread Rene writes, "The native scale format is much more
complete and powerful, and as you already know z3ta+ supports it
directly. Perhaps you could convince the vendors of your other
instruments to go this way instead."

There are many, many reasons why Rene is absolutely correct.

"Scala does something extremely interesting from my point of
view: it completely insulates the concepts of 'tuning system' and
'keyboard layout', turning them in two cohesive but non-intersectant
objects."

That's one reason.

"A text editor will do Scala files as well."

And here's another. Scala files make an excellent human-readable
and human-writable standard for scale description and archival.

Anamark writes, "As soon as you start applying this ratio to
frequencies, it also will have an error."

Yet another reason to protect the scale, a theoretical concept,
from the resolution errors of various instruments, which vary.

Another way to say it is that a scl file is a list of intervals,
which which a keyboard mapping can produce a list of pitches.

-Carl

🔗Rick McGowan <rick@...>

Hi Carl --

> There's no need to say "input", it's just "Scala format" or "scl
> file".

Fine. "scl" file.

> A scl file plus a keyboard map gives you everything you
> need to generate a tun file, which should be obvious since Scala
> can do this.

But a .scl file *alone* doesn't give you a precise set of frequencies,
unless I'm missing something. These synth developers who are saying "just
drag a .scl file onto the synth and voila it works" don't seem to get it.

> Pretty-much anything is constructible in Scala, if by no other
> means than entering the intervals!

Fine, but. So can a .tun file, so it doesn't matter. Both formats are
human readable and can be edited. Anything can be made in the .tun format
also; you just have to enter the frequencies (or cents).

>> Furthermore, there are bound to be bugs and inconsistencies in
>> any synth's implementation of Scala input format
>
> Why? It's an utterly trivial conversion.

I don't think it's so trivial to interpret .scl files. And any two
implementations are bound to have a different set of bugs. Also, if the
synth has to have some keyboard map and do the interpretation, that's
another place for bugs to enter. OK, maybe this is all easy enough that's
not a big issue, but, there's no guarantee, and I don't think all the
implementations are going to be bug-for-bug compatible with Scala.

Take this .scl file, direct from the distribution:

! org1373b.scl
!
English organ tuning (1373) with 18:17:16 accidental semitones (Eb-G#)
12
!
18/17
9/8
81/68
81/64
4/3
24/17
3/2
27/17
27/16
243/136
243/128
2/1

Excuse me, but what will be the frequency of MIDI note 69 if you just
drag/drop that onto one of these synths that support scl format? Who
knows!? What guarantee do you have that two synths implementing scl format
will give you the same pitches? None. The file doesn't specify any
frequencies, it specifies a *system*.

> In that thread Rene writes, "The native scale format is much more
> complete and powerful

Yeah, but... there may be N-thousand scl files out there, but none of them
specify any pitches; they specify tuning systems and they have to be tied
to set of pitches to be used. What guarantee do I have that any two synths
will give me the same set of pitches? None.

> There are many, many reasons why Rene is absolutely correct.

No, he's wrong. Yeah, scl is a powerful format, but -- every scl file
doesn't specify a set of pitches. If you drag/drop it onto a synth, what
you get is anyone's guess. It's an inappropriate format for specifying the
final, static tuning of a synthesizer. Sorry, but it doesn't work for me.

> "Scala does something extremely interesting from my point of
> view: it completely insulates the concepts of 'tuning system' and
> 'keyboard layout', turning them in two cohesive but non-intersectant
> objects."

That's precisely something I don't want in a tuning map! I want a precise
set of frequencies on particular MIDI notes. With a .tun file, at least
you're guaranteed that if you set two synths to the same tuning file you
get the same frequencies.

I really must be missing something here, and many Manuel can straighten it
out. But as far as I can tell scl format in and of itself is just
inappropriate to use as a "final format" for loading into a synth precisely
because it doesn't specify any frequencies.

> Another way to say it is that a scl file is a list of intervals,
> which which a keyboard mapping can produce a list of pitches.

Again, that doesn't seem useful to me. See above. There aren't any
frequencies of particular notes on the keyboard in a scl file. What the
synth is ultimately going to be using is a set of frequencies for sound
production. How do you get that? And how do you guarantee you'll get the
same pitches from two synths that use scl format?

Anyway, the bottom line for me is that nobody's shown me that scl format
is useful as a final format for using with different synths; or that I can
just take any scl file and get a precise set of frequencies to match some
other criterion. As such, scl format seems unsuited to be used as a
drag/drop tuning file format for synths. Am I missing some crucial point
here?

Rick

🔗Carl Lumma <ekin@...>

>> A scl file plus a keyboard map gives you everything you
>> need to generate a tun file, which should be obvious since Scala
>> can do this.
>
>But a .scl file *alone* doesn't give you a precise set of frequencies,
>unless I'm missing something. These synth developers who are saying
>"just drag a .scl file onto the synth and voila it works" don't seem
>to get it.

You have to pick a key-center somehow. Without specifying a keyboard
map, Scala assumes you want middle C.

If I want to change key centers, and my data model is

tun -> sound,

I actually have to generate a new tun file. That's why

scl -> something -> sound

is a good idea.

>> Pretty-much anything is constructible in Scala, if by no other
>> means than entering the intervals!
>
>Fine, but. So can a .tun file, so it doesn't matter. Both formats
>are human readable and can be edited. Anything can be made in the
>.tun format also; you just have to enter the frequencies (or cents).

But with a tun file, don't I have to write all 128 pitches?

Are tun files extensible beyond 128 pitches? Or tied to MIDI in
some other way?

Can I write a tun file in 30 seconds?

Can I see instantly by looking at a tun file what interval of
equivalence is being used and how many notes are in a period
of the scale?

Does the tun format support comments for each pitch entry, and
separate comments for the scale as a whole?

Can I enter pitches as ratios?

How hard is searching a library of tun files to find doubles
(such as scales that were independently discovered at different
points in history), especially if they're expressed in
different keys or with slight rounding errors?

>>> Furthermore, there are bound to be bugs and inconsistencies in
>>> any synth's implementation of Scala input format
>>
>> Why? It's an utterly trivial conversion.
>
>I don't think it's so trivial to interpret .scl files. And any two
>implementations are bound to have a different set of bugs.

http://www.xs4all.nl/~huygensf/scala/scl_format.html

Bugs a problem writing to this? I think not.

>Take this .scl file, direct from the distribution:
>
> ! org1373b.scl
> !
> English organ tuning (1373) with 18:17:16 accidental semitones
> 12
> !
> 18/17
> 9/8
> 81/68
> 81/64
> 4/3
> 24/17
> 3/2
> 27/17
> 27/16
> 243/136
> 243/128
> 2/1
>
>Excuse me, but what will be the frequency of MIDI note 69 if you just
>drag/drop that onto one of these synths that support scl format? Who
>knows!? What guarantee do you have that two synths implementing scl
>format will give you the same pitches? None. The file doesn't specify
>any frequencies, it specifies a *system*.

Exactly. It's a language for talking about musical systems.

>> In that thread Rene writes, "The native scale format is much more
>> complete and powerful
>
>Yeah, but... there may be N-thousand scl files out there, but none
>of them specify any pitches; they specify tuning systems and they
>have to be tied to set of pitches to be used. What guarantee do I
>have that any two synths will give me the same set of pitches? None.

If you want to assure that two people can get on stage and play
together, and you're too lazy to implement keyboard maps, definitely
tun files are the way to go.

>> There are many, many reasons why Rene is absolutely correct.
>
>No, he's wrong. Yeah, scl is a powerful format, but -- every scl file
>doesn't specify a set of pitches. If you drag/drop it onto a synth,
>what you get is anyone's guess.

It's no guess if you've specified a keyboard map. Otherwise
they should be mapped to middle C by default, as in Scala.

Do tun files have throwaway precision? It seems desirable to
specify the scale once at maximum precision and let each instrument
handle its frequency resolution in its own way.

>Anyway, the bottom line for me is that nobody's shown me that scl format
>is useful as a final format for using with different synths; or that I
>can just take any scl file and get a precise set of frequencies to match
>some other criterion. As such, scl format seems unsuited to be used as a
>drag/drop tuning file format for synths. Am I missing some crucial point
>here?

If synths were all I was ever going to talk to, I'd say tun format,
all the way. But I (as many others) use scl files to keep track of
tuning systems, and synth compatibility is a highly-desirable feature
for me. It isn't mutually exclusive with tun support, so why try to
discourage developers from adding it?

-Carl

🔗Rick McGowan <rick@...>

Carl wrote...

> You have to pick a key-center somehow. Without specifying a keyboard
> map, Scala assumes you want middle C.

And is that documented sufficiently that all the other synths get it
right? I hope so, because it affects interoperability. Jacky's TUN file
tutorial, which I just ran across, helps solve the problem: he tells you
how to creat scl files that specify the right pitch-center...

> But with a tun file, don't I have to write all 128 pitches?

You have Scala to generate them! ;-) No problem.

> Can I write a tun file in 30 seconds?
> ...
> Can I see instantly by looking at a tun file what interval of
> equivalence is being used and how many notes are in a period
> of the scale?
> ...
> Can I enter pitches as ratios?
>
> How hard is searching a library of tun files to find doubles

Who cares? You're missing my point. I don't care about those things. And I
have Scala do deal with that stuff anyway. What I care about is that I can
use the same source file, scl or tun, or whatever, to get all synths that
support the format to interpret it precisely the same way and get the same
frequencies (within their margins of tuning and sampling error).

(Totally aside from the main topic here, the set of N-thousand tuning
files in Scala are fairly useless to me because they aren't well enough
documented as to their provenance and properties. One line in the header is
insufficient, especially when you get into, for example "Schlesinger's
Lydian Harmonia in the first trichromatic genus". Huh? By the way, other
than scalesdir.txt, is there any accompanying doc or bibliographic info for
all the scales that come with Scala?)

Carl went on:

> http://www.xs4all.nl/~huygensf/scala/scl_format.html
> Bugs a problem writing to this? I think not.

Wow! Carl! Think again. That's the high-level view, not about the
language. You completely mistake the size of the problem here. A scl file
contains statements in the Scala LANGUAGE which Scala interprets. Make no
mistake: Scala implements a highly specialized computer language with a lot
of mathematical operators and so forth. It is *NOT* trivial to implement.
What you need to implement is indexed here:
http://www.xs4all.nl/~huygensf/scala/helpindx.html
described here:
http://www.xs4all.nl/~huygensf/scala/help.htm
and summarized here:
http://www.xs4all.nl/~huygensf/scala/commands.txt

I can guarantee that any two random programmers implementing that language
and all those complex operators would end up with at least one bug that
differs from implementation to implementation. That's one problem. What
about partial implementations? If the language isn't implemented
*completely* then you'll have scl files that aren't even portable between
the implementations. That's another problem. And the fact that the files
don't expess the actual frequencies is yet another...

Rick

🔗Carl Lumma <ekin@...>

>> Can I write a tun file in 30 seconds?
>> ...
>> Can I see instantly by looking at a tun file what interval of
>> equivalence is being used and how many notes are in a period
>> of the scale?
>> ...
>> Can I enter pitches as ratios?
>>
>> How hard is searching a library of tun files to find doubles
>
>Who cares? You're missing my point. I don't care about those things.

Well I do! Can tun files do them or not?

>(Totally aside from the main topic here, the set of N-thousand tuning
>files in Scala are fairly useless to me because they aren't well enough
>documented as to their provenance and properties.

I agree totally.

>One line in the header is
>insufficient, especially when you get into, for example "Schlesinger's
>Lydian Harmonia in the first trichromatic genus". Huh?

That's why the typcial scala file from my archive is marked up with
many, many lines of text, and diagrams.

>Carl went on:
>
>> http://www.xs4all.nl/~huygensf/scala/scl_format.html
>> Bugs a problem writing to this? I think not.
>
>Wow! Carl! Think again. That's the high-level view, not about the
>language. You completely mistake the size of the problem here. A scl
>file contains statements in the Scala LANGUAGE which Scala interprets.
>Make no mistake: Scala implements a highly specialized computer
>language with a lot of mathematical operators and so forth. It is
>*NOT* trivial to implement.

Yes, it is, and I could implement it in my sleep. In fact I have
written procedures that parse scala files and do things to them.

>What you need to implement is indexed here:
> http://www.xs4all.nl/~huygensf/scala/helpindx.html
>described here:
> http://www.xs4all.nl/~huygensf/scala/help.htm
>and summarized here:
> http://www.xs4all.nl/~huygensf/scala/commands.txt

Huh?? You're misunderstanding something, or off in a frame somewhere.

-Carl

🔗Graham Breed <graham@...>

Rick McGowan wrote:

> Wow! Carl! Think again. That's the high-level view, not about the > language. You completely mistake the size of the problem here. A scl file > contains statements in the Scala LANGUAGE which Scala interprets. Make no > mistake: Scala implements a highly specialized computer language with a lot > of mathematical operators and so forth. It is *NOT* trivial to implement. Well, yes, Scala is a highly specialized language. But .scl files plainly don't contain statements in that language. They contain what the link Carl gave says they contain. It's very easy to implement. It should be fairly easy to get two synthesizers to agree on a pitch reference. You might like the example keyboard mapping:

"""
! Key-for-key mapping with Middle C on standard frequency.
! Size:
0
! First MIDI note number to retune:
0
! Last MIDI note number to retune:
127
! Middle note where scale degree 0 is mapped to:
0
! Reference note for which frequency is given:
60
! Frequency to tune the above note to (floating point e.g. 440.0):
261.6256
! Scale degree to consider as formal octave:
127
"""

which is also very simple and easy to implement. It disagrees with params.par about the pitch reference, but that would only lead to different implementations being 0.2 millicents apart.

I really fail to see the problem.

Graham