back to list

Re: JM

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

5/8/2001 6:10:41 AM

Sorry about the duplicated digest at the end of the last post!

Robert

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

5/8/2001 5:23:18 AM

Hi Monz,

Nice ideas, but I think it is best to start simple with something thta
works.

Once it is up and going, and if it is a good program, others will want
to link in with it and use its capabilities.

How about just finishing it as it is, and letting others use it,
and then continue based on feedback from them.

I'm happy to try it out and make suggestions and so forth, as I have
done already.

However, you've also asked me to take on the responsibility for getting
the project finished, in one form or another (no idea what words you
used), and I'm not interested in doing that. I do appreciate being
asked.

To date I haven't been involved in the coding for it at all. If there
is something that you would like the code for, say, conversion of
cents to ratios or whatever, then I am happy to share some of the
c-code from FTS (indeed, you could use the source code from my
javascript pages for that particular one).

But, not at all interested in debugging someone elses code, at least, not for
a large complex application, which is what would inevitably be involved if
I were to take on the completion of the project from the present source code. I'm
happy to help beginner programmers find bugs in their programs, but that
is quite another matter. Just from trying out the program, I see it is
well designed, by expert programmers who know what they are about, and they should
be able to fix their own bugs!

For many projects, debugging is about half of the work; maybe less if one
uses really good programming practices (I'd say less than half would be
rather rare), maybe much more, especially if it isn't so well written,
or the bugs are particularly elusive.

It is hard enough to find bugs in ones own program
that one practically knows some of the sections by heart line by line from debugging it.

This program isn't even in the language I normally use as it is in C++ rather
than C.

I expect you aren't that aware of those points as you are not so involved
in programming large programs.

See if you can get the original programmers enthusiastic about it again.
It is a nice program with a lot of potential, so I think there is a
lot to be enthusiastic about in it, if you don't try to do too much
at once.

Also, releasing the program and getting nice feedback from users is a way
to encourage the programmers to continue. But, you do have to fix bugs
first. Better to have a simple program that works than one with lots of
great features that doesn't.

Especially, it _must_ work for any input for the basic task the program
is designed to do - if a user happens to open a scale that doesn't show
up a lattice at all first time they use the program, unless very determined,
they will just give up at that point.

I wish I could debug all the buggy nice programs in the world. But, not
practical,...

I believe it is fairly common for a program to get very close to completion
and never be completed because of bugs that are never fixed.

I make a policy of fixing all the bugs I find. However, if that isn't
practical, one can prioritise them.

For example, a bug that means a user can't open a scale and show a lattice
is top priority as the program can't be used at all until it is fixed.

An example of a low priority bug might be - you write a word processing
program, and very occasionally the printer will print out an extra blank
page at the end of a document. Okay, should be fixed, but it isn't that
much trouble for the user to put the blank page back into the feeder
tray, so it is a low priority bug (I got this example from a book on
coding practice and debugging, but I think it is a good one).

I don't think it would take that long for the original programmers to
fix the top priority bugs. Also it is perfectly normal for a program
to have such things at the beta stage, and doesn't reflect badly on
the programmers at all. What does reflect badly is if it is released
when it is still at that early beta stage, so they do have to be fixed!

I'd say go for an early release, let some of the others on the
TL use it, and see what they say, and go from there.

But that is only a suggestion, I hasten to add!

Robert

----- Original Message -----
From: <tuning@yahoogroups.com>
To: <tuning@yahoogroups.com>
Sent: Monday, May 07, 2001 10:03 AM
Subject: [tuning] Digest Number 1289

> You do not need web access to participate. You may subscribe through
> email. Send an empty email to one of these addresses:
> tuning-subscribe@yahoogroups.com - join the tuning group.
> tuning-unsubscribe@yahoogroups.com - unsubscribe from the tuning group.
> tuning-nomail@yahoogroups.com - put your email message delivery on hold for the tuning group.
> tuning-digest@yahoogroups.com - change your subscription to daily digest mode.
> tuning-normal@yahoogroups.com - change your subscription to individual emails.
> tuning-help@yahoogroups.com - receive general help information.
>
> ------------------------------------------------------------------------
>
> There are 24 messages in this issue.
>
> Topics in this digest:
>
> 1. Re: Re: adaptive tuning
> From: JoJoBuBu@aol.com
> 2. Re: adaptive tuning
> From: "monz" <joemonz@yahoo.com>
> 3. Re: What is a monzisma?
> From: paul@stretch-music.com
> 4. Re: Pythagorean 3-speed bikes: for Joseph Pehrson
> From: jpehrson@rcn.com
> 5. Re: Prent's new tune
> From: prentrodgers@home.com
> 6. Re: Reply to Kyle Gann on Margo Schulter; iii chord.
> From: "David J. Finnamore" <daeron@bellsouth.net>
> 7. Re: Erlich paper very readable
> From: jpehrson@rcn.com
> 8. Re: Prent's new tune
> From: prentrodgers@home.com
> 9. Re: Erlich paper very readable
> From: paul@stretch-music.com
> 10. JustMusic and latticing software (was: Re: Erlich paper very readable)
> From: "monz" <joemonz@yahoo.com>
> 11. (unknown)
> From: "monz" <joemonz@yahoo.com>
> 12. Australian Microtonal Music Forum
> From: "Justin White" <justin.white@davidjones.com.au>
> 13. nothing at the center
> From: "monz" <joemonz@yahoo.com>
> 14. Re: nothing at the center
> From: "monz" <joemonz@yahoo.com>
> 15. Re: Prent's new tune
> From: JSZANTO@ADNC.COM
> 16. Re: Prent's new tune
> From: JSZANTO@ADNC.COM
> 17. Re: New Microtonal Piece at mp3.com
> From: "monz" <joemonz@yahoo.com>
> 18. Re: Re: Prent's new tune
> From: JoJoBuBu@aol.com
> 19. Re: Pythagorean 3-speed bikes -- Monz's welcome emendation
> From: mschulter <MSCHULTER@VALUE.NET>
> 20. Re: Ben Johnston notation - a centered universe
> From: mschulter <MSCHULTER@VALUE.NET>
> 21. Re: buckets...
> From: Robert C Valentine <BVAL@IIL.INTEL.COM>
> 22. Re: Pythagorean 3-speed bikes -- Monz's welcome emendation
> From: "monz" <joemonz@yahoo.com>
> 23. Re: Pythagorean 3-speed bikes -- Monz's welcome emendation
> From: "monz" <joemonz@yahoo.com>
> 24. German version of my "lattices" webpage
> From: "monz" <joemonz@yahoo.com>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 1
> Date: Sun, 6 May 2001 22:49:32 EDT
> From: JoJoBuBu@aol.com
> Subject: Re: Re: adaptive tuning
>
> In a message dated 5/6/2001 10:26:56 PM Eastern Daylight Time,
> joemonz@yahoo.com writes:
>
>
> > And Andy, since you're new to the list, you should definitely
> > give a listen to John deLaubenfels's incredible adaptive-tuning
> >
>
> Thanks for the suggestion. Where is it available? I pulled up his name on
> google.com but didn't see it.
>
> Andy
>
>
> [This message contained attachments]
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 2
> Date: Mon, 07 May 2001 02:56:43 -0000
> From: "monz" <joemonz@yahoo.com>
> Subject: Re: adaptive tuning
>
>
> --- In tuning@y..., JoJoBuBu@a... wrote:
>
> /tuning/topicId_17672.html#22218
>
> > In a message dated 5/6/2001 10:26:56 PM Eastern Daylight Time,
> > joemonz@y... writes:
> >
> >
> > > And Andy, since you're new to the list, you should definitely
> > > give a listen to John deLaubenfels's incredible adaptive-tuning
> > >
> >
> > Thanks for the suggestion. Where is it available? I pulled up
> > his name on google.com but didn't see it.
>
>
> Go to
> www.adaptune.com
> and click on "Studio J".
>
>
> BTW, Andy's post here came up with my full email address
> on it. What gives? I've always seen the domain names
> x'd out.
>
>
>
> -monz
> http://www.monz.org
> "All roads lead to n^0"
>
>
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 3
> Date: Mon, 07 May 2001 03:21:54 -0000
> From: paul@stretch-music.com
> Subject: Re: What is a monzisma?
>
> > > I wonder if this might be the smallest interval that's ever
> > > actually been given a name?
>
> Probably the smallest superparticular ratio that's been given a name is Erv Wilson's 7-limit
> "ragisma", which is 4375:4374. In Xenharmonikon 17, John Chalmers published a list of all
> superparticular ratios for each prime limit through (I think) 23, using a maximum of something
like
> 10 digit numbers. If I recall correctly, the smallest 5-limit one is 81:80, and the smallest
7-limit one
> is the ragisma.
>
> In my investigations of 7-limit periodicity blocks, I've used unison vectors much smaller than the
> "monzisma", such as the 250000:250047, involved in some of the 171-tone periodicity blocks I
> found.
>
> On Kees van Prooijen's page _Searching Small Intervals_, one finds even smaller 7-limit
> intervals, such as 2251783932057135:2251799813685248. This would be involved in
> constructing a 3125-tone periodicity block.
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 4
> Date: Mon, 07 May 2001 03:21:59 -0000
> From: jpehrson@rcn.com
> Subject: Re: Pythagorean 3-speed bikes: for Joseph Pehrson
>
> --- In tuning@y..., mschulter <MSCHULTER@V...> wrote:
>
> /tuning/topicId_22164.html#22164
>
> >
> > Hello, there, Joseph Pehrson, and thank you for some very helpful
> > comments and questions.
> >
> > Within the very modest limits of written prose and ASCII keyboard
> > diagrams, maybe one way that I can share some "Pythagorean biking"
> > ideas with you is by a "test drive" in which we try to design the
> > perfect "3-speed" model in 24 notes.
> >
> > I write this in the hope that you and other readers can reasonably
> > soon make the "test drive" metaphor more concrete by actually trying
> > out some of these tunings on a synthesizer, or at least hearing them
> > on a tape which I may soon by preparing.
> >
>
> Thank you very much, Margo, for this fascinating post concerning
> possible alternate tunings for Gothic music... Surely I hope to try
> out some of these tunings and, of course, your cents indications
> always make this quite an easy matter...
>
> Your discussion of 36-tET with the 1/6 tone alterations was,
> naturally, particularly apropos... after our recent discussions of
> its relative 72-tET.
>
> It was also particularly interesting to see the results you found
> when you varied the distances BETWEEN the two keyboards from the
> "usual" Pythagorean comma difference that you use.
>
> Surely, the "tricomma" is a mighty ratio, as is the tuning work of
> Mightymonz!
>
> Thanks so much again!
>
> ________ _____ ______
> Joseph Pehrson
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 5
> Date: Mon, 07 May 2001 03:51:56 -0000
> From: prentrodgers@home.com
> Subject: Re: Prent's new tune
>
> This song took me six months. Lots of time on coding the pre-
> preprocessor program in Pascal, called "samples", to accept different
> timing options (which randomize the start time of notes to imitate
> the out of phase playing of high school drum and bugle corps). I also
> spent some time implementing the upsampling and downsampling options.
> These allow me to make miniature pianos and giant piccolos. I hand
> coded all the glissando's: 65 different slides, up and down by
> different amounts to allow the move from 4:5:6 to 7:9:11 in all
> inversions and combinations. The program picks which one to use
> randomly. Each time through is different.
>
> This is not the fastest way to make music. But I can't figure out a
> faster alternative. How else do you get to hear these chord changes,
> in perfect intonation, perfect rhythms, and never hear anyone
> complain about one more time through?
>
> I think I may be able to move a little faster when soccer season
> ends.
>
> Prent Rodgers
>
>
>
> --- In tuning@y..., John Starrett <jstarret@c...> wrote:
> > Another fine piece of microtonal music Prent. Reminds me of Miles
> Davis'
> > post Bitches Brew. Could you estimate the amount of time it took
> you to
> > complete this? I am interested in how long it takes an experienced
> > Csound programmer to assemble a piece.
> >
> > --
> > John Starrett
> > "We have nothing to fear but the scary stuff."
> > http://www-math.cudenver.edu/~jstarret/microtone.html
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 6
> Date: Sun, 06 May 2001 22:53:15 -0500
> From: "David J. Finnamore" <daeron@bellsouth.net>
> Subject: Re: Reply to Kyle Gann on Margo Schulter; iii chord.
>
> Kyle Gann wrote:
>
> > I still don't know Margo as more than a name.
>
> Now, that's a cryin' shame. Search the Tuning List archives for "neo-Gothic." You'll end up with
what is the equivalent of 333 single-space typed pages (I've copied it into a single Word document)
of
> masterful, engaging, and thoroughly scholarly work. Also, search for the names of medieval and
Renaissance theorists such as Zarlino, Vicentino, Marchettus, etc. for loads more. She has also
published some
> web pages about early music theory.
>
> I think she also may be up for the "Nicest Person In The World" award.
>
> --
> David J. Finnamore
> Nashville, TN, USA
> http://personal.bna.bellsouth.net/bna/d/f/dfin/index.html
> --
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 7
> Date: Mon, 07 May 2001 03:57:32 -0000
> From: jpehrson@rcn.com
> Subject: Re: Erlich paper very readable
>
> --- In tuning@y..., "monz" <joemonz@y...> wrote:
>
> /tuning/topicId_22105.html#22193
> >
> >
> > I'm still working on it, Joe... the tool you're describing
> > is the JustMusic software. At this point it looks like
> > Robert Walker is going to be the one to make the final push
> > and get it released. (hopefully)
> >
>
> Wow... this I didn't know, but I had heard that you were organizing a
> "developers' group." Congrats... and this sounds exciting! Might
> save people like Paul some time, too!
>
> ________ ______ ____ _____
> Joseph Pehrson
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 8
> Date: Mon, 07 May 2001 04:08:38 -0000
> From: prentrodgers@home.com
> Subject: Re: Prent's new tune
>
> Andy,
>
> Csound does use lots of lists of notes. The way I use it, I tell
> Csound the following information for every note:
>
> - Start time (nice to make it just a tad early or late to simulate
> drummers getting in and out of the "groove"
> - Duration (short, long, independent of the start time of the next
> note)
> - Velocity (how loud each note is, very important for phrasing)
> - Note (I use Partch's 43 tone scale)
> - Octave
> - Voice (which instrument the sample based synthesizer is using)
> - Stereo (location in the stereo field)
> - Envelope (I use 18 different envelopes, with various attack,
> sustain, and decay characteristics)
> - Glissando (I use either a non-glissando, or any one of 64 different
> glissandi on each note, up or down, how long at each step, how many
> steps and slides for each note)
> - Up-sample how many samples (creates deliberate munchinization)
>
> With all these different variables for each of the 60,000 notes in
> the piece, I needed a separate program to control the information. I
> use one I wrote in Pascal over the years. It's full of bugs and
> idiosyncrasies and no one else has ever tried to use it. It requires
> Borland's Turbo Pascal compiler, which has long gone un-supported.
> But it does allow me to spend time on the parts of the music I care
> most about in an organized manner.
>
> Supercollider is Mac only. I only use windows and OS/390 computers at
> the moment.
>
> --- In tuning@y..., JoJoBuBu@a... wrote:
> > Anyone who works in Csound I would suggest taking a look at
> > some of the newer sound synth languages like Supercollider (what I
> use) or
> > Max. They work for live performances and if I remember correctly,
> its been a
> > while, Csound does not work in real time (although direct Csound
> might I dont
> > remember). As for your question it can take a good chunk of time to
> program
> > that stuff depending on how complicated you make it and what
> program you are
>
> Prent Rodgers
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 9
> Date: Mon, 07 May 2001 04:09:02 -0000
> From: paul@stretch-music.com
> Subject: Re: Erlich paper very readable
>
> --- In tuning@y..., jpehrson@r... wrote:
> > --- In tuning@y..., "monz" <joemonz@y...> wrote:
> >
> > /tuning/topicId_22105.html#22193
> > >
> > >
> > > I'm still working on it, Joe... the tool you're describing
> > > is the JustMusic software. At this point it looks like
> > > Robert Walker is going to be the one to make the final push
> > > and get it released. (hopefully)
> > >
> >
> > Wow... this I didn't know, but I had heard that you were organizing a
> > "developers' group." Congrats... and this sounds exciting! Might
> > save people like Paul some time, too!
>
> The ability to make higher-dimensional
> lattices, and to project these in various ways
> onto the 2-dimensional plane of the computer
> screen or page, would be a must for me. But
> some of my lattices, such as the helical
> meantone lattice, for example, would
> probably not be supported by the JustMusic
> software . . . would it?
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 10
> Date: Mon, 07 May 2001 04:40:05 -0000
> From: "monz" <joemonz@yahoo.com>
> Subject: JustMusic and latticing software (was: Re: Erlich paper very readable)
>
>
> --- In tuning@y..., jpehrson@r... wrote:
>
> /tuning/topicId_22105.html#22224
>
> > --- In tuning@y..., "monz" <joemonz@y...> wrote:
> >
> > /tuning/topicId_22105.html#22193
> > >
> > >
> > > I'm still working on it, Joe... the tool you're describing
> > > is the JustMusic software. At this point it looks like
> > > Robert Walker is going to be the one to make the final push
> > > and get it released. (hopefully)
> > >
> >
> > Wow... this I didn't know, but I had heard that you were
> > organizing a "developers' group." Congrats... and this
> > sounds exciting! Might save people like Paul some time, too!
>
>
> Yes, it would save Paul time, because even tho the version
> that currently works only uses the Monzo lattice formula,
> eventually the plan is to have the user specify any lattice
> formula he wishes, including all of Erv Wilson's lattice
> and Bosanquet-derived keyboard designs. So Paul could
> simply pop in the numbers, or better yet, formulae, and
> JustMusic does all the latticing.
>
> And of course, the ultimate goal of JustMusic is to produce
> audible music. The version I have that will actually create
> music for me does it with MIDI, but we've put that on the
> back burner and have decided to create CSound output.
>
> But anyway, the project has been stalled for a while as
> I haven't had time to devote to its leadership. Hopefully
> we can stir some interest now.
>
>
> If you're a programmer or mathematician who would like to
> contribute to getting this sofware developed and released,
> please consider joining the Yahoo JustMusic group. It's
> a private list, and I just ask that you email me with details
> about your interests and abilities as they relate to what
> I have on the homepage:
>
> /justmusic
>
>
>
> -monz
> http://www.monz.org
> "All roads lead to n^0"
>
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 11
> Date: Mon, 07 May 2001 04:58:11 -0000
> From: "monz" <joemonz@yahoo.com>
> Subject: (unknown)
>
>
> I was contemplating the line "All roads lead to n^0"
> that I coined for my signature, and my thoughts turned
> mystical...
>
> I've been so interested in the millenia-old connections
> posited between musical harmonic lattice diagrams and
> cosmic geometry, that it suddenly struck me as highly
> interesting that this phrase points to the nothingness
> that lies at the center of so many cosmologies and religions.
>
> Get it?... "lies at the center"?...
>
> Hmmm...
>
>
> ----
>
> PS - Just something to make y'all jealous...
>
> I'm down at Starr Labs every day now,
> working on MicroZones...
>
>
>
>
> -monz
> http://www.monz.org
> "All roads lead to n^0"
>
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 12
> Date: Mon, 7 May 2001 15:05:30 +1000
> From: "Justin White" <justin.white@davidjones.com.au>
> Subject: Australian Microtonal Music Forum
>
>
>
>
>
> Announcing the first Australian
>
> Microtonal Music Forum
>
>
> covering modern approachs to Just Intonation and all tuning systems other than
> 12 tone equal temperament
>
>
>
> Date: May 15th.
>
> Starting time: 5.45pm
>
> Place: Room 3.11, Level 3,
> Select House
> 109 Pitt Street
> (next to the eastern entrance to the Hunter Arcade)
> Sydney NSW 2000
> AUSTRALIA
>
> Note:The sliding doors close at 6.00pm.
>
> By phoning 9230 3740, late comers MAY be able to call someone down to ground
> level to open the door. But please try to be on time.
>
>
> Light refrehments will served.
>
>
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 13
> Date: Mon, 07 May 2001 05:06:32 -0000
> From: "monz" <joemonz@yahoo.com>
> Subject: nothing at the center
>
> --- In tuning@y..., "monz" <joemonz@y...> wrote:
> >
> > I was contemplating the line "All roads lead to n^0"
> > that I coined for my signature, and my thoughts turned
> > mystical...
> >
> > I've been so interested in the millenia-old connections
> > posited between musical harmonic lattice diagrams and
> > cosmic geometry, that it suddenly struck me as highly
> > interesting that this phrase points to the nothingness
> > that lies at the center of so many cosmologies and religions.
>
>
> It might be a good idea to elaborate for those who aren't
> familiar with my theories that the actual literal meaning
> of the nothingness at the center of my phrase "All roads
> lead to n^0" is the *absence of prime-factors*.
>
> n^0 means that all of the prime-factors have an exponent
> of zero, which produces the product of 1, which by definition
> is *not* a prime number.
>
> So all the rest of the lattice, in every dimension, is
> populated with prime-factors raised to their various exponents,
> but the very center only contains 1, the only non-prime
> on the lattice.
>
>
> This structure is amazingly similar to the latest models of
> galaxies, which posit a black hole at the center with the
> enormous mass needed to hold the galaxy together.
>
> I've brought this up before, but it's stunning to me how
> these musical lattice diagrams *do* reflect our beliefs
> about the structure of the universe. And if Siemen Terpsra
> and I are correct about the Sumerians knowing all this stuff,
> it's one of the oldest ideas around.
>
>
>
> -monz
> http://www.monz.org
> "All roads lead to n^0"
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 14
> Date: Mon, 07 May 2001 05:11:23 -0000
> From: "monz" <joemonz@yahoo.com>
> Subject: Re: nothing at the center
>
>
> --- In tuning@y..., "monz" <joemonz@y...> wrote:
>
> /tuning/topicId_22228.html#22230
>
> > I've brought this up before, but it's stunning to me how
> > these musical lattice diagrams *do* reflect our beliefs
> > about the structure of the universe. And if Siemen Terpsra
> > and I are correct about the Sumerians knowing all this stuff,
> > it's one of the oldest ideas around.
>
>
> Sorry, a typo... that's Siemen Terpstra.
>
>
>
> -monz
> http://www.monz.org
> "All roads lead to n^0"
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 15
> Date: Mon, 07 May 2001 05:16:30 -0000
> From: JSZANTO@ADNC.COM
> Subject: Re: Prent's new tune
>
> Yo Prent!
>
> --- In tuning@y..., prentrodgers@h... wrote:
> > This song took me six months.
>
> What could only be termed "a dogged pursuit of the truth"!!
>
> > Lots of time on coding the pre-preprocessor program in Pascal,
> > called "samples"...
>
> I remember the last time I talked to you about your custom 'tools'
> you were one of the few people that was still playing with Pascal (a
> language I still have a fondness for).
>
> As to all the things you did to make the music, it really came out
> great. You are one of the few that I'll use my 56k modem to download
> the whole enchilada.
>
> > This is not the fastest way to make music. But I can't figure out a
> > faster alternative.
>
> That's a shame, because I wouldn't be surprised if your
> more 'spontaneous' (like, in hours or days) would be just as fun and
> fascinating.
>
> > I think I may be able to move a little faster when soccer season
> > ends.
>
> Slacker. You're just waiting for a sun break...
>
> Cheers,
> Jon
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 16
> Date: Mon, 07 May 2001 05:24:23 -0000
> From: JSZANTO@ADNC.COM
> Subject: Re: Prent's new tune
>
> Prent,
>
> I want to take advantage of one of the few times you're posting to
> the list...
>
> --- In tuning@y..., prentrodgers@h... wrote:
> > Csound does use lots of lists of notes. The way I use it, I tell
> > Csound the following information for every note:
> >
> > - Start time (nice to make it just a tad early or late to simulate
> > drummers getting in and out of the "groove"
> > - Duration (short, long, independent of the start time of the next
> > note)
>
> ...and etc. Just a question: have you ever tried, investigated,
> and/or used any of the MIDI-to-.sco programs a couple of people have
> cobbled together? I wonder if you couldn't do at least some of this
> in mockup form in MIDI, and then continue to tweak with either
> another program or by hand on the .sco files? At the very least, it
> might make generation of the drum parts faster (and not having to
> worry about the intonations).
>
> Then again, the more random sections you have, the more you will have
> to stay with 'hand' composing the piece. Which seems to have it's own
> rewards...
>
> Again, appreciatively,
> Jon
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 17
> Date: Mon, 07 May 2001 05:39:19 -0000
> From: "monz" <joemonz@yahoo.com>
> Subject: Re: New Microtonal Piece at mp3.com
>
>
> --- In tuning@y..., prentrodgers@h... wrote:
>
> /tuning/topicId_22140.html#22140
>
> > Dear Tuners,
> >
> > I recently uploaded a new song to my MP3.com web site called "La
> > Cuenta". It can be found at http://www.mp3.com/PrentRodgers .
> >
> > <etc.>
>
>
> Hey Prent, this is a great piece! Reminds me a little bit
> of Wendy Carlos's 19-limit harmonic scale piece on _Beauty
> In The Beast_... "Just In Time", or something like that...
>
> I love those pungent 7:9:11 triads!
>
>
> -monz
> http://www.monz.org
> "All roads lead to n^0"
>
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 18
> Date: Mon, 7 May 2001 01:49:18 EDT
> From: JoJoBuBu@aol.com
> Subject: Re: Re: Prent's new tune
>
> In a message dated 5/7/2001 12:10:17 AM Eastern Daylight Time,
> prentrodgers@home.com writes:
>
>
> > Andy,
> >
> > Csound does use lots of lists of notes. The way I use it, I tell
> > Csound the following information for every note:
> >
> > - Start time (nice to make it just a tad early or late to simulate
> > drummers getting in and out of the "groove"
> > - Duration (short, long, independent of the start time of the next
> > note)
> > - Velocity (how loud each note is, very important for phrasing)
> > - Note (I use Partch's 43 tone scale)
> > - Octave
> > - Voice (which instrument the sample based synthesizer is using)
> > - Stereo (location in the stereo field)
> > - Envelope (I use 18 different envelopes, with various attack,
> > sustain, and decay characteristics)
> > - Glissando (I use either a non-glissando, or any one of 64 different
> > glissandi on each note, up or down, how long at each step, how many
> > steps and slides for each note)
> > - Up-sample how many samples (creates deliberate munchinization)
> >
> > With all these different variables for each of the 60,000 notes in
> > the piece, I needed a separate program to control the information. I
> > use one I wrote in Pascal over the years. It's full of bugs and
> > idiosyncrasies and no one else has ever tried to use it. It requires
> > Borland's Turbo Pascal compiler, which has long gone un-supported.
> > But it does allow me to spend time on the parts of the music I care
> > most about in an organized manner.
> >
> > Supercollider is Mac only. I only use windows and OS/390 computers at
> >
>
> Thats quite incredible. I didn't realize the immense amount of coding thats
> required for CSound(let alone using turbo pascal along with it), I've only
> used it very briefly. With SC programmings quite different. Its easy to
> create a little function that puts whatever ratios, or temperaments desired
> into patterns. you could for example set a ton of material into a variable
> and then later manipulate that pattern, meaning pattern of ratios to a
> fundamental or frequencies in general, and modulate it or whatever you want
> by whatever ratio or number you want with very little code. Of course this
> all depends on how specific you want to be with everything
>
> Or you can work in scale degrees or other ways I havent messed with much. It
> does have a feature that can do lists of notes which I've used briefly but I
> always tend to make a mistake here or there (wrong duration for a note or
> what not which screws everything up). Everything you specify, unless you are
> specifically using lists of notes, can of course be specified of course but
> you definately dont have to specify it for every note.
>
> I wish it was supported on PC. I am more of a PC guy myself.
>
> Thanks for the info on how you work with the microtones, interesting.
>
> Andy
>
>
> [This message contained attachments]
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 19
> Date: Sun, 6 May 2001 22:56:33 -0700 (PDT)
> From: mschulter <MSCHULTER@VALUE.NET>
> Subject: Re: Pythagorean 3-speed bikes -- Monz's welcome emendation
>
> Hello, there, Monz, and thank you very much both for a most due
> Aristoxenian "friendly amendment" to my post on 3-speed Pythagorean
> bikes, and a fascinating discussion on "least intervals."
>
> First, I would very much like to emphasize the importance of your
> point about choosing an interval varying somewhat from 7:6 _by ear_
> for your composition _3+4_, and then, having settled on something
> around 279 cents, selecting 75:64 as a convenient ratio.
>
> Unfortunately, although I had read your account, my language neglects
> this very characteristic Aristoxenian touch -- finding what sounds
> right, and then integrating it into the intonational structure. My
> emphasis was on "How neat that this fits a 5-limit RI model!" as if
> the model were the basis for the choice, rather than the ratio a
> convenient realization of an _aural_ judgment.
>
> In contrast, my tricomma tuning was a theoretical construct designed
> to solve a musical problem on a mathematical basis: "Come up with a
> 24-note Pythagorean tuning with both a 7-flavor and a 17-flavor."
>
> Your experimental, directly interactive, "intracompositional" process
> of trying 7:6, adjusting by ear to 279 cents, and then fine-tuning to
> a 75:64 as a ratio at once satisfying to the ear and conceptually
> elegant, is something left out of my narrative -- which could easily
> be read to suggest that you set out in advance to emulate a 7-based
> ratio with a complex 5-limit approximation.
>
> In any future reference to the 75:64 saga, I'll be careful to tell the
> full story, with much emphasis on the very audible process of
> "fine-tuning" in the best Aristoxenian manner.
>
> As for small intervals, or more specifically those with not-so-small
> integer ratios, the monzisma at ~0.29 cents is larger than the kalisma,
> the difference between 32:25 and the 12544:9801 interval equal to a
> Pythagorean major third at 81:64 plus two 896:891 commas (the
> difference between this third and 14:11). The kalisma has a ratio of
> 9801:9800, or ~0.1766 cents.
>
> By the way, I wonder what might have happened had you chosen a
> different rational expression for your "right-sounding" 279 cents, for
> example 27:23 (~277.59 cents)? That ratio occurred to me by a certain
> free association as the fifth complement of the 23:18 which I enjoy
> quoting as an RI approximation for the regular major third of 17-tET
> -- that is, the size that the minor third _would_ have in 17-tET if
> the fifths were a pure 3:2.
>
> The jots are interesting -- according to Scala, a kalisma at 9801:9800
> is about 4.431350 jots; although the monzisma apparently involves a
> rational ratio too large for my version of Scala for MS-DOS to report
> in integer form, it returns a size of about 7.334990 jots.
>
> Most appreciatively,
>
> Margo Schulter
> mschulter@value.net
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 20
> Date: Sun, 6 May 2001 22:59:14 -0700 (PDT)
> From: mschulter <MSCHULTER@VALUE.NET>
> Subject: Re: Ben Johnston notation - a centered universe
>
> ------------------------------------------------
> Ben Johnston notation and historical context:
> A response to the Paul Erlich-Kyle Gann dialogue
> ------------------------------------------------
>
> Hello, there, and having become something of a topic as well as a not
> disinterested reader of the fascinating dialogue regarding matters of
> broad music history and notational utility involving Paul Erlich and
> Kyle Gann, I would like to respond especially on two questions of
> historical style and intonation.
>
> Please let me begin by thanking Paul Erlich warmly for quoting my
> views pertinently and accurately, and also Kyle Gann for raising some
> very reasonable questions and differences of view with a widespread
> currency among musicologists and others.
>
>
> -----------------------------------------------------------------
> 1. General concerns: 5-limit notations and historical transitions
> -----------------------------------------------------------------
>
> Before getting into the deeper historical intricacies of 14th-century
> style and Pythagorean intonation (e.g. Machaut), or the fluid and
> often ambiguous modality of the late 16th and early 17th centuries
> based in my view mainly on a meantone model, I'd like briefly to
> address the primary matter at issue in this dialogue, and also to echo
> your caution, Kyle Gann, about taking _any_ convenient date as a
> precise and absolute line or demarcation between two eras or
> approaches such as modality and major/minor tonality.
>
>
> -------------------------------------------------
> 1.1. Notational projects and historical precedent
> -------------------------------------------------
>
> First, regarding notations for a system such as 5-limit just
> intonation (JI) where any solution will involve some compromises and
> arguable "anomalies," I would say pragmatically that whatever people
> find most comfortable and convenient is best.
>
> Since different people evidently find different notations most
> "natural," some diversity may be the most reasonable or, I might say,
> "ecologically" appropriate solution.
>
> If we are to take 16th-century musical notation as a precedent or
> model, however, then we encounter a complication: this notation, as
> used by composers and theorists including Zarlino (champion of the
> syntonic diatonic as a model of _vocal_ intonation), does not attempt
> explicitly to show syntonic comma adjustments or to distinguish 9:8
> and 10:9 whole-tones. Rather such adjustments -- however negotiated --
> are left implicitly to the performers.
>
> Playing a 16th-century piece on a keyboard with a 15-note octave
> modelled after Zarlino's scheme, I must realize the notation by
> playing the right notes to make either G-D or D-A a pure fifth rather
> than one a syntonic comma narrow. Here there is _not_ a one-to-one
> correspondence between notation or spelling and the tuning system
> itself. Karol Berger's dissertation on chromatic and enharmonic
> theories in late 16th-century Italy nicely addresses this point.
>
> Thus the project of developing a 5-limit notation which _expressly_
> indicates syntonic comma distinctions is something outside of usual
> 16th-century practice, which seems to me most closely to reflect
> either meantone or some "unwritten" form of adaptive tuning
> adjustments for purer consonances. On this point, Paul, we seem much
> in agreement.
>
> As to what system is best for such a project, I may not be the best or
> most informed judge, since I'm accustomed mostly to what I term
> "equitonal" systems such as Pythagorean intonation, meantone, and
> neo-Gothic temperaments where all regular major seconds have the same
> size and a major third is equal to four fifths up.
>
> If one is seeking a literal notation for classic 5-limit JI which
> keeps count of all the syntonic commas, then I might personally go
> with the Helmholz-Ellis-Wolf-Monzo system (HEWM), also used by Easley
> Blackwood (albeit as a critic rather than an exponent of this form of
> intonation).
>
> However, if the Ben Johnston notation is comfortable for performers
> and helps them find the right notes, then that's fine, also.
>
> Here I would emphasize that neither Johnston nor HEWM notation needs
> the ratification of any historical precedent: if the notational shoe
> fits the musical foot, then why not wear it?
>
>
> ---------------------------------------
> 1.2. Transitions and conventional dates
> ---------------------------------------
>
> In response to Paul's accurate quote of my view that the transition
> from modality to major/minor tonality had become an established
> feature of "modern" practice by around 1680 (the era of Corelli and
> Werckmeister), Kyle questions the validity of giving _any_ precise
> date for such a transition, as well as proposing the late 16th-century
> era of Palestrina, say a century earlier, as a better estimate.
>
> While saving the issue of modality in the late 16th and early 17th
> centuries for discussion below (Section 3), I would like very much to
> agree that any date such as 1680 is merely an arbitrary reference
> point for a process of transition.
>
> What we have during the Manneristic era of around 1540-1640 or
> Rore-Monteverdi, in my viewpoint, is a fluid and very creative
> practice based on a 12-mode system both enriched and sometimes blurred
> by liberties including direct chromaticism and sometimes also
> diesisism (Vicentino). An important point is that the new inflections
> often fit _neither_ the "classical" Renaissance practice of a composer
> such as Josquin, nor the constraints of major/minor tonality.
>
> By the third quarter of the 17th century, composers such as Stradella
> are moving in a tonal direction, so that one might place the
> transition somewhere around 1660-1680, with Corelli's music taken as a
> confirmation and consolidation of this trend.
>
> One advantage of the approximate date 1680 is that it closely
> coincides with Werckmeister's publication of his well-temperaments
> (1681 and later), as well his views that only two basic modes (major
> and minor) were needed to describe modern practice. At the same time,
> this date also agrees with one 20th-century view of the major/minor
> period as ranging roughly from 1680 to 1900 (say Corelli-Puccini).
>
> In my opinion, a balanced view of the problem should recognize not
> only that some elements introduced in the late modal practice of
> around 1600-1640 become usual elements of major/minor tonality, but
> also that some modal concepts remain important in the theory of around
> 1700, when we would agree that tonality has clearly become the norm.
>
> Similarly, to propose (as Mark Lindley does, very reasonably in my
> view) that the transition from Pythagorean to meantone on keyboards
> may have occurred sometime around 1450 is not to say that it happened
> suddenly in that precise year or even decade, but that clues such as
> the style of a keyboard composer such as Conrad Paumann suggest this
> epoch as a likely one.
>
> Traditional "great dates" of historiography may be placed in fuller
> perspective without losing their significance. The year 1600 (or its
> surrounding decade or so), for example, continues to symbolize the
> import of such events as the new dissonance treatment of Monteverdi
> and his colleagues, or the advent of continuo-based forms, even if we
> choose to describe this transition as "Early/Late Manneristic" rather
> than "Renaissance/Baroque."
>
> To sum up, Kyle, I'm much in agreement with you that any quoted date
> for a transition between two musical eras, styles, or tuning systems
> is at best a convention and convenience -- although a galvanizing
> composition or treatise may often provide a ready date _symbolizing_
> such a transition and making its flavor more tangible.
>
>
> ----------------------------------------------
> 2. Pythagorean intonation and the 14th century
> ----------------------------------------------
>
> In this dialogue, Machaut's prominent use of major thirds was briefly
> mentioned, and I'd like to comment in my view that this practice is
> quite consistent with the Pythagorean intonation described by
> musicians of the Ars Nova era such as his contemporary Johannes Boen
> (1357).
>
> As long as thirds and sixths are treated as decidedly _unstable_
> intervals, often inviting standard cadential resolutions although
> often also used in a freer or more "coloristic" fashion, Pythagorean
> tuning fits such a role of "imperfect concord" or _relative_ blend.
>
> An interesting passage in Boen explains the role of parallel thirds
> and sixths in approaching a cadence: these intervals serve as
> "forerunners and handmaidens" of the stable or "perfect" concords of
> the fifth and octave. Thus I find that a late Gothic idiom of this
> kind can be very pleasing in Pythagorean tuning, with C4 here showing
> middle C in a "MIDI-like" fashion:
>
> A4 G4 F4 E4 F4
> E4 D4 C4 B3 C4
> C4 Bb3 A3 G3 F3
>
> As Mark Lindley writes, the complex thirds and sixths give this kind
> of texture a "sinuous" quality.
>
> In fact, I often enjoy passages of this kind in 29-tone equal
> temperament (29-tET) with major thirds and sixths somewhat wider than
> Pythagorean. Going much beyond this, however, some Setharean timbre
> adjustments may be in order to keep these unstable intervals
> _relatively_ blending; with such adjustments, 17-tET can also be
> delightful.
>
> As Carl Dahlhaus has written, there is a neat correspondence between
> the "acoustical surface" of Pythagorean tuning and the musical
> style of the 13th and 14th centuries, with octaves, fifths, and
> fourths serving as the primary concords but various unstable intervals
> also playing a very prominent role.
>
> By the later 15th century, however, there is a gap between Pythagorean
> theory and current practice -- although some students of this era have
> recently suggested that singers may have often leaned toward
> Pythagorean intonation in performances of composers such as Ockeghem,
> even as meantone keyboards were becoming the norm.
>
> Notationally speaking, musicians finessed the transition by sticking
> with what one might call an intonationally generic and "equitonal"
> notation corresponding closely to either the old Pythagorean or the
> new meantone system, but not explicitly recognizing the complication
> of the syntonic comma for flexible-pitch performers negotiating the
> tertian styles now in vogue with thirds at or close to 5:4 or 6:5.
>
>
> ----------------------------------------------------------
> 3. Modality, centers, and intonation: Vicentino-Monteverdi
> ----------------------------------------------------------
>
> During the era of 1540-1640, music is based on a very flexible system
> of 12 modes, sometimes freely ornamented and mixed together in manners
> advocated in the earlier part of this period by the composer and
> theorist Nicola Vicentino (1555), and in the latter part by such
> musicians as Claudio Monteverdi and his brother Giulio Cesare
> Monteverdi (1607).
>
> Here I would like to focus on the general question of accidentalism,
> the matter of Zarlino's experimental JI keyboard, and my views of the
> modes in practice around 1600.
>
>
> ------------------------------------------------------
> 3.1. Accidentalism in Manneristic modality (1540-1640)
> ------------------------------------------------------
>
> In viewing the accidentalism of the 16th and early 17th centuries,
> including the direct chromaticism of a Vicentino or Gesualdo as well
> as the routine inflections taken for granted by Zarlino, it is very
> important to place this question in the perspective of earlier Gothic
> practice and theory.
>
> While the accidentals Eb, F#, and C# -- in addition to the fluid step
> B/Bb (German H/B) of the regular gamut -- are in use by the era of
> Perotin around 1200, these inflections plus G# become a routine
> feature of the early Ars Nova in the era around 1300.
>
> Such accidentals are frequently mandated by the pattern of "closest
> approach" -- the norm that unstable intervals should resolve to "the
> nearest consonance." Thus a third expanding to a fifth or sixth
> expanding to an octave by contrary motion should be major, while a
> third contracting to a unison should be minor.
>
> This convention calls for a regular use of _musica ficta_, "invented
> notes" outside the regular gamut of diatonic notes plus Bb.
>
> In 16th-century modality, such inflections are one side of a modal
> system also routinely using accidentals by the 1520's to obtain major
> thirds above the lowest voice in closing sonorities -- the use of
> thirds in such sonorities becoming increasingly the norm.
>
> From my perspective, at least, a balanced view of our Manneristic
> period from Rore and Vicentino to Monteverdi and Frescobaldi should
> take account of at least three factors:
>
> (1) The modal system, including its creative ambiguities and
> affinities between related modes with similar species of fifths and
> fourths (or pentachords and tetrachords);
>
> (2) The element of vertical sonority, now clearly shifted in practice
> and theory from the Gothic trine (2:3:4) to the _harmonia perfetta_ of
> Zarlino's "third plus fifth or sixth" (e.g. 4:5:6); and
>
> (3) The often guiding role of "closest approach" and related
> progressions, some borrowed from the Gothic era, in directing the flow
> of saturated tertian sonorities.
>
> Obviously a 16th-century system of meantone, or of adaptive JI with
> minute adjustments to finesse the syntonic comma while maintaining
> pure vertical concords, neatly fits item (2). However, musicians such
> as Netherlands just intonation advocate Peter van Marissing have
> suggested a more subtle connection between intonation and vertical
> organization.
>
> In meantone, major and minor thirds are pure or nearly pure, and the
> late modal style of organization often features relationships between
> sonorities with lowest notes a third apart. Such relations are common
> in medieval chant and polyphony, but take on new aspects in a tertian
> environment, some of them involving striking forms of accidentalism
> including direct chromaticism.
>
> At the same time, the late Gothic principle of "closest approach" also
> takes on new forms, as such a scholar as Carl Dahlhaus has found in
> his study of compositions around 1600.
>
> Consider a progression in a setting in E Phrygian like this:
>
> E4 F#4 G4
> B3 D4 E4
> G#3 A3 C4
> E3 D3 C3
>
> 8 - 10 - 12
>
> Here there is no direct chromaticism -- the use of chromatic semitone
> steps -- but a use of accidentals producing three consecutive
> sonorities with what Zarlino terms harmonic divisions of the fifth
> (fifth plus major third above the bass).
>
> From one viewpoint, we might focus on the stepwise contrary motion of
> the outer parts from octave to major tenth to twelfh. The smoothly
> conjunct motion prevailing has a "late tertian/modal flavor" of its
> own.
>
> Taking the perspective of closest approach, we note that the first
> sonority is connected to the second by a major third expanding to a
> fifth between the lower pair of voices (E3-G#3 to D3-A3), and the
> second sonority to the third by a similar expansion of major tenth to
> twelfth between the outer voices (D3-F#3 to C3-G3).
>
> Thus does a familiar 14th-century cadential progression take on new
> sonorous shape, Pythagorean intonation compellingly reflecting the
> original context, and meantone or adaptive just intonation the
> 16th-century adaptation.
>
> While the beauty of this progression speaks for itself, we might add
> from a free modal perspective that the motion of the bass E3-D3-C3
> connects the Phyrgian final E, the note of repose, with the common
> confinal or "co-final" C, often favored for intermediate cadences.
> This "third-related" connection is a delightful aspect of Manneristic
> practice sometimes inspiring boldly direct chromaticism.
>
> For example, consider a progression like this:
>
> A4 A4
> F4 E4
> C4 C#4
> F3 A3
>
> Such idioms have a logic of their own, constrained neither by the
> earlier modal practice of a composer such as Josquin, nor by the
> major/minor key system established in the later 17th century.
>
> In his analysis of Monteverdi, Carl Dahlhaus concludes that many of
> his progressions fit the "closest approach" paradigm mentioned as a
> basic element of counterpoint by such an early 17th-century "modern"
> as Agazzari in his presentation on continuo (1607), but not the
> expectations of key tonality, citing especially examples like the
> following:
>
> E4 F#3 G4 A4
> B3 D4 D4 F4
> G#3 A3 B3 C4
> E3 D3 or G3 F3
>
> These progressions again involve the common expansion of major third
> to fifth in contexts where Dahlhaus remarks that major/minor tonality
> would suggest a different treatment. He comments that while
> conventional histories often look for instances where inflections
> seem to fit a "major/minor" pattern, they may disregard choices which
> seem to have the opposite effect, but fit the concept of "closest
> approach" as applied in a tertian setting.
>
> At the same time, Dahlhaus emphasizes that such compositions do not
> conveniently fit either classic 16th-century modal theory or
> 18th-century tonal theory. In their manifesto of 1607, the Monteverdi
> brothers themselves declare that this music belongs to a tradition of
> freely mixing modes in order to express the words and affections
> (i.e. emotions) of a text, an ethos for which we have an eloquent
> statement in Vicentino.
>
> A "polymodal" approach to composers such as Monteverdi and Gesualdo,
> like any theoretical approach, must fall short of a full appreciation
> of the music, but seems to me both enticing and evocative, with
> "closest approach" as discussed by Dahlhaus providing one historical
> foundation for what in the 21st century remains justly famed as a
> radically innovative style.
>
>
> -----------------------------------------------
> 3.2. Zarlino's JI keyboard and the modal system
> -----------------------------------------------
>
> As Paul Erlich has remarked, Zarlino's JI keyboard with its 16 notes
> per octave (including two versions of D, Bb, F#, and Eb) is presented
> by Zarlino himself as an experimental instrument, difficult to play
> and much less practical than a temperament such as his own 2/7-comma
> meantone.
>
> The main conclusion I draw from playing a 15-note variation on
> Zarlino's instrument mapped to two keyboard manuals is that managing
> any piece in any mode that frequently calls for fifths at both D-A and
> G-D is likely indeed to be "difficult," just as Zarlino observes.
> These fifths are likely to occur in any of the modes, not only in the
> obvious D Dorian or G Mixolydian.
>
> For a few pieces calling for only one of these fifths (interestingly
> including a favorite D Dorian piece where G-D happens not to occur),
> or where in my two-manual arrangement the fifths or fourths in
> question happen fortuitously to call for the right hand at the most
> convenient time, this kind of JI can be as easy as meantone.
>
> Otherwise, as Zarlino says, temperament is more practical; and he also
> observes that singers, unlike such special keyboards in the syntonic
> diatonic, can strive for pure consonances without the complication of
> "small intervals" such as the syntonic comma. Could this be a hint
> that adaptive JI was at least sometimes practiced?
>
> Like his predecessor Glareanus, Zarlino favors a system of 12 modes,
> with an authentic and plagal form for each of six basic octave-species
> (D, E, F, G, A, and C).
>
> From the perspective of either middle to late 16th-century practice,
> or of later developments, we may duly note that while in 1558 he
> follows the traditional numbering of the modes starting with authentic
> and plagal Dorian (Modes I and II), by the early 1570's he proposes
> giving the Ionian or C modes pride of place. This renumbering would
> follow the order of the natural hexachord C-A (C ut, D re, E mi, F fa,
> G sol, A la).
>
> However, Zarlino is _not_ proposing a reduction of the 12 modes to
> two, or the abolition of the Dorian mode because the fifth D-A
> presents complications in a realization of his syntonic diatonic model
> on a fixed-pitch instrument.
>
> Similarly, Zarlino groups the modes (1558) into two families based on
> the natural vertical division of the fifth above the final: in Dorian,
> Aeolian, and Phrygian (D-D, A-A, E-E), the arithmetic division
> prevails with minor third below and major third above (string ratio
> 6:5:4); while in Lydian, Ionian, and Mixolydian (F-F, C-C, G-G) the
> harmonic division obtains with major third below and minor third above
> (string ratio 15:12:10).
>
> He describes the harmonic division with the major third above the
> final as more "natural" or "joyful," and the arithmetic division with
> the minor third as more "sad" or "gentle."
>
> This harmonic/arithmetic distinction is also expressed in the later
> contrast between major and minor keys, but under different musical
> conditions and with often different organizational structures and
> patterns.
>
> While Zarlino proposes a renumbering of the 12 modes, incidentally,
> musicians of this and the immediately succeeding generation prefer to
> retain the customary numbering as expounded and expanded by
> Glareanus (1547).
>
> The question, "What is the center of the system?" may be based on the
> premise that there is necessarily a specific "center." One might
> argue that there are multiple centers, depending on how one chooses to
> view the system at a given moment.
>
> For example, the Dorian and Mixolydian modes might represent one kind
> of center, located midway between Lydian and Phyrgian in the set of
> modes (a distinct Lydian being least common in the 16th century):
>
> F C G D A E
> Lydian Ionian Mixolydian | Dorian Aeolian Phyrgian
> ------------------------ ------------------------
> harmonic division arithmetic division
>
> If we take account of Zarlino's harmonic/arithmetic groupings, then
> Mixolydian and Dorian are the adjacent members of the two groupings,
> sharing the affinity of an upper tetrachord T-S-T (T for whole-tone, S
> for semitone), D-E-F-G or A-B-C-D.
>
> Of course, Zarlino's theoretical model of the syntonic diatonic and
> his renumbering of the modes suggest C as a center of interest, while
> going back to earlier medieval practice, one could argue on the
> concrete evidence of usual musical clefs that F and C, the diatonic
> notes located immediately above mi-fa semitones (C-fa or F-fa), are
> both salient points of orientation.
>
> Applying solmization in a different way, we could point to the
> symmetry of Dorian as a special attraction, with two T-S-T tetrachords
> (re-mi-fa-sol):
>
> D E F G A B C D
> re mi fa sol re mi fa sol
> T S T T T S T
>
> The attraction of multiple centers both in theory and in practice
> lends much charm to the music of this era, along with the element of
> fluid degree inflection inspired by both melodic and vertical
> considerations often differing from those of later tonal styles.
>
> The typical 12-note meantone compass Eb-G# nicely accommodates the
> usual accidental inflections of the 12 modes, with modal variety
> providing a rich system within a relatively modest range of
> transpositions.
>
> It is in the late 17th century, when major/minor tonality becomes the
> established paradigm, that Werckmeister's well-temperaments serve to
> accommodate the greater range of routine transpositions compensating
> for the "bipolar" rather than "multipolar" world of the new system.
>
>
> -------------------------------------------
> 3.3. Fluid modality in practice around 1600
> -------------------------------------------
>
> As a very perceptive historian, Julius Lester if I recall correctly,
> has observed, debates about the "modal" or "tonal" nature of early
> 17th-century music are inevitably colored by the viewpoints of the
> participants.
>
> I have experienced this at first hand, when playing a piece from a
> German keyboard manuscript of this era identified as in the "First
> Tone" (Mode I, D Dorian) for a friend more accustomed to later Baroque
> music, and a far more skilled keyboardist by the way.
>
> What I experienced as routine cadences or momentary focuses on various
> degrees of the mode, she noted as "modulations." In other music from
> this period, she expressed surprise at events which for me seemed less
> remarkable.
>
> Reading efforts of 20th-century theorists to "explain" progressions
> which seem to me a part of the usual late modal vocabulary also
> suggests that one's musical background and preferences may shape much
> of the analysis.
>
> Recognizing these inevitable and stimulating differences, I would myself
> join with such authors as Arthur Merritt (_Sixteenth Century Polyphony: A
> Basis for the Study of Counterpoint_) and Knud Jeppesen (often cited by
> Joseph Pehrson in counterpoint-related threads) in viewing the music of
> Palestrina, Lasso, and Victoria as indeed modal, with an interplay of
> multiple centers which Merritt considers a special attraction of this
> period.
>
> In composers of the early 17th-century era such as Giovanni Gabrieli
> and Frescobaldi, I can recognize, for example, "Dorian" idioms; while
> the Phrygian mode has its charms not only in vocal liturgical settings
> such as those of Victoria, but in keyboard music with a distinctly
> "modern" flavor.
>
> Also, a radical musician such as Fabio Colonna (1618) demonstrates the
> transpositions of various modes, including Dorian with its symmetrical
> solmization, on his 31-note _Sambuca Lincea_ or harpsichord dividing
> each tone into five equal parts (a model suggesting a circulating
> 1/4-comma temperament or the later 31-tET).
>
> In proposing an often free intermixture of the 12 modes, or
> "polymodality," as one standpoint from which to approach this era --
> and in 1655, Christoph Bernhard presents a 12-mode system while
> discussing many of the new idioms of Monteverdi and his age -- I would
> not wish to suggest that "modality" is the only or most important
> factor in this music.
>
> Vertical euphony, closest approach, chromatic idioms, and sheer
> inspiration all play a role in giving this music its character. As one
> historian wrote of a different question, the "medieval/Renaissance"
> distinction, there is enough material here for advocates or "modal"
> and "tonal" analyses alike to keep busy for some time, and possibly to
> find inspiration for the creation of much new music.
>
> Most respectfully,
>
> Margo Schulter
> mschulter@value.net
>
>
>
>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 21
> Date: Mon, 7 May 2001 10:07:28 +0300 (IDT)
> From: Robert C Valentine <BVAL@IIL.INTEL.COM>
> Subject: Re: buckets...
>
> > From: paul@stretch-music.com
> > Subject: Re: mistuning of octave considered good
> >
> < summarizing the differences between Pauls Harmonic Entropy
> and my 'hacked psuedo harmonic entropy calculation' >
>
> HE HPHEC
> 2/1 1200+-42 1200+-30
> 3/2 702+-35 702+-18
>
> > > Basically, I gave my tool sharper ears than 'typical resolution'.
> >
> > Not necessarily! The range I gave doesn't correspond to the "width
> > of the bucket" -- would that be the distance between the two
> > nearest local maxima?
>
> Yes, I am referring to the width of the bucket up to the local
> maxima. Somewhere around 1230 the walls of the bucket rising up
> from 33/16 are lower than those from the 2/1, hence it stops
> being a bruised octave and starts being some distinct identity.
>
> An interesting observation in this thread i
(Message over 64 KB, truncated)

🔗Jay Williams <jaywill@tscnet.com>

5/8/2001 6:25:22 AM

Jay here,
Sorry if repetition abounds, but I didn't see my two previous posts appear so:
Sure enough, assigning note-off commands to specific program numbers didn't
solve the problem of having two separate voices on one channel, one pitch,
but different lengths from operating independently. What I'm wondering is
what might be done with what Roland calls "parts." I was going to try that
but I don't have the manyual at hand and don't remember how to turn on
sysex on an external SC55. I'd appreciate that bit of info, I don't recall
that it can be done from the pc keyboard. Anyway, voices such as #86, the
one that runs in parallel 4ths, might be a good one to experiment on as it
is a ready-made example.
And thanks, Robert, for your discussion of this phenomenonomaly.
At 02:10 PM 5/8/01 +0100, you wrote:
>Sorry about the duplicated digest at the end of the last post!
>
>Robert
>
>
>You do not need web access to participate. You may subscribe through
>email. Send an empty email to one of these addresses:
> tuning-subscribe@yahoogroups.com - join the tuning group.
> tuning-unsubscribe@yahoogroups.com - unsubscribe from the tuning group.
> tuning-nomail@yahoogroups.com - put your email message delivery on hold
for the tuning group.
> tuning-digest@yahoogroups.com - change your subscription to daily digest
mode.
> tuning-normal@yahoogroups.com - change your subscription to individual
emails.
> tuning-help@yahoogroups.com - receive general help information.
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>

🔗John A. deLaubenfels <jdl@adaptune.com>

5/10/2001 6:16:36 AM

[Robert Walker wrote:]
>For many projects, debugging is about half of the work; maybe less if
>one uses really good programming practices (I'd say less than half
>would be rather rare), maybe much more, especially if it isn't so well
>written, or the bugs are particularly elusive.

>It is hard enough to find bugs in ones own program that one practically
>knows some of the sections by heart line by line from debugging it.

>This program isn't even in the language I normally use as it is in C++
>rather than C.

I may be a bit OT here, but...

Tracking and fixing bugs, without introducing new ones (!) is indeed a
difficult art. It is probably the most exasperating, and possibly the
most satisfying, aspect of programming. Satisfaction, of course, comes
at the moment of victory, after a long slog through digital mud.

It is best to fix one's own bugs, absolutely. It's bad karma to leave
a mess for someone else to clean up.

I do highly recommend C++ over C. I resisted making the transition for
years, but now would never want to go back. It is _much_ easier to
write robust code quickly in C++ than in C. I would guess (knock on
wood!!) that I spend considerably less than 50% of my programming time
debugging now, I think because of using C++ most of the time. Java is
said to be even more robust; I've been meaning to learn it, but...

JdL

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

5/10/2001 10:00:33 PM

Hi John,

I remember I had a lot of resistance to first using a debugger to step through
my code, preferring to do ti the old way by adding lots of instructions
to the debug code to print out the values of any relevant variables
as it goes through a loop etc.

In fact, still do that sometimes, sometimes it is an excellent approach,
but wouldn't go back to doing without a step through debugger with breakpoints now.

I also had a lot of resistance to using a wizard to edit my resource scripts,
preferring to write them all by hand. Used to find all the coordinates
for the buttons and other controls by hand and type them in myself.
But, wouldn't even think of doing that now, though it is useful to
be able to do it sometimes if you get a resource script error,
as _can_ happen with the wizards occasionally.

I don't know if this is the same kind of thing. Perhaps.

But. if C++ code is so easy to debug that you can get rid of
_all_ the bugs in the same length of time that it takes to
write the code, or less, why are any C++ programs ever released
with bugs in them? Does it means the programmers aren't prepared
to spend even as much as half of their programming time
debugging?

I can't believe that, given the difference it makes
to the reception of a program if it is really completely
bug free, or nearly so.

I can believe that the wizard generated code itself is bug free, if one
fits in with the C++ architecture when using it, but imagine it
might perhaps not work so well if one were to try to change the architecture
in some fundamental way, as I might desire to do, after so much
time using a C level of coding.

I even do some wizard generating code in a way - well, writing
a program to scan a file and make externs out of all the
function headers in it for instance, things like that.

I can also believe that the object orientated approach
can remove certain types of bugs completely.

So, I can believe is that writing in C++ removes some of the
bugs that are most trickly to fix in C.

But, does it introduce new bugs? The tricky ones in C are all
very low level in a way, and I'm used to dealing with those.

Does C++ introduce a new high level of bug. I'm used to that
happening in ones own code, but then one wrote it oneself, and
knows the architecture intimately.

But, how does one set about finding a high level bug when using
wizard generated code and libraries of classes that one needs
to know the documentation of.

Would have to learn new techniques surely, and I'd need to
change my style a lot as I make extensive use of global
variables.

If all C++ programs released were bug free, that would
be a strong incentive to change. But, as yet, they aren't.

Nor are programs in any of the popular languages, to my knowledge.

Suggests that at least some bugs just get more elusive,
whatever language one uses...

I know that there are guaranteed bug free programming methods,
used for really critical programs, in fact there is a group
in Oxford (no particular connections with the logic group that I studied
with) that is working on exactly that, provably correct programming.

But, to date, programs in that approach are _very_ slow to write,
I believe, and it hasn't caught on in popular languages.

Nasa still has software glitches in its pioneering spacecraft,
and I'm sure there would be a strong incentive to use provably
correct programs for that if it was at all easy to do.

The methods are used for some safety critical programs, I believe.

Maybe in the future it will catch on, as techniques improve.

However, will have to have limits even then. There's a famous theorem that
if your programming language is sufficiently powerful to
let you write an interpreter of the language in itself Interpr (say),
(which is quite a complex type of program, but not _that_ complex
- the core of c can be interpreted in a dozen or so pages of c-code)
then there is no way to write a program T (say) that can check
whether any program in the language will go into an endless loop or not

- any such program checking program, if sufficiently powerful to check all
programs, is guaranteed to either give the wrong answer for at least
one input, or to have at least one input that will send it into
an endless loop.

An endless loop that can't be avoided would always
be counted as a bug I think = the "This program has stopped
responding to the system" type of bug.

So one is saying that any program that can check for all possible
bugs in all possible programs in a sufficiently versatile
computing language is guaranteed to have a bug in itself.

Why? write a program P that reads the testing program T as data,
runs T as interpreted code, with P as the data for T, and then,
by design, goes into an endless loop if T terminates normally
with the answer that P never goes into an endless loop.

Such a program will just consist of the interpreter Interpr, plus
P and T as data, plus a few extra lines of code to set T
as the program for the interpreter to run, and P itself as the
data for T, plus an extra couple of lines to go into an endless loop
depending on the output from T when run in the interpreter.

One could write this a little more formally as something like:

Define A(x) = return value for A with x as data

Suppose we have a program T that satisfies
T (x) = TRUE if x terminates normally.
T (x) = FALSE if x goes into an endless loop.

and an intepreter
Interpr(x,y) = interpreter with x as program, y as data
and output of x(y) as return value

I.e. Interpr is a program that can be given any other
program x as one input file, and the data y for x as a second
input file, and will then interpret x, and return with
the return value for x(y)

Now make
P(x,y) =
"
if(Interpr(x,y)== TRUE)
go into endless loop
else
exit
"

Then run P(T,P)

Now the question is, does T (when interpreted in this way)
say that P goes into an endless loop?

If T answers Yes, then P by design doesn't go into one. If
T answers No, then P by design does.

Either way, T gives the wrong answer.

If T goes into an endless loop itself, which is a third way out,
then it has a bug in it too, as we agree (I hope) that an unintended
endless loop is a bug.

There is a way out of all that, but not a very desirable one.

Idea is, T is okay (doesn't have a bug in it) but P now has a bug,
and since P is a pretty simple program apart from the interpreter,
then the most likely conclusion is that Interpr has one now, and
doesn't do what it is designed to do; doesn't run T correctly.

But the argument will work if there is any bug free interpreter
that can be written in the language. So this way out isn't
that desirable either - means it is completely impossible to
write any bug free interpreter of the language in itself,
though perhaps plenty of buggy ones. I think one would be a bit
wary of using such a language!

So looks as though a provably correct programming language has
to step very warily when it gets to the stage where one
is making a program as complex as an interpreter, and
must somehow prevent you from writing a complete interpreter
of itself in itself (Interpr). I.e lets you write T perhaps,
but not Interpr, and so not P.

Or alternatively, it lets you write Interpr, but
not T.

I.e. alternatively, you can't write the program that can be used to prove
correctness of other programs in the language.

Perhaps this seems a more promising approach to
use. But then this means that the program for proving
correctness can't itself be proved to be correct using
its own methods.

I suppose that isn't so bad - T would be quite a complex program,
but you only have one program to write, and you do it very
carefully, then after that, all the other ones will be
provably correct - always assuming you never introduced any
bugs in T. But you will never know for sure that T has no
bugs in, or at least, even if completely convinced,
won't be able to use T to check itself.

Your programs will also be limited to some extent in what
they can do, but if T is well designed, mightn't be much
of a drawback at all, might only apply to _really_ esoteric
mathematical things that no-one is likely to ever want to be
able to do, not even mathematicians (hopefully! There's always
a possibility, maybe a strong one, that when excluding these
really esoteric things, one might also exclude some as yet
unforseen mainstream things as well).

I'm not sure what the theorists do at this point. I expect
they then resort to a powerful but reasonably straightforward
mathematical theory that is believed to be correct, though
it can't be proved to be so, such as the axiomatisation of
arithmetic + universal and existential quantification.
But that is a pretty simple theory, so they will have
to make severe restrictions on the programming language
to make it impossible to code a theorem tester for the
meta theory (once you've got one of those, you've almost
got the program T).

Have to say here, I've no idea how they actually design
these provably correct programming languages, just know
about them in theory. Might be interesting to learn more.

In practice, T would be more complex than just saying whether
P goes into an endless loop or not. But one of the bugs
it would be expected to detect would certainly be the endless loops,
and if ti can catch those at all, then that is enough for
the conclusions to hold.

Anyway, the conclusion is clear, making provably correct
code is possible, but must be at least slightly limited in scope.

Maybe someone will design a reasonably versatile language in which
only provably correct programs can be written, and which
is reasonably easy to use. That would be a great boon.
It mightn't completely eliminate bugs as there are two things,
whether the program does what it is supposed to do, and
whether what it was supposed to do was a sensible thing
to do in the first place.

It can't eliminate the bugs that are there because the program
is designed to do something that isn't particularly sensible.
But would eliminate a great many.

However, looks as though we will still be chasing bugs for some time
to come. Also, looks as if any programs that really push the boundaries
of complexity for a program in innovative ways will - not necessarily
always have bugs in them, but never be conclusively proved by anyone to
be totally bug free.

N.B. Godel's incompleteness theorem that Jacky quoted uses
essentially the same type of idea, but in the context
of any provable correct formal system instead of any
provably correct programming language.

Changing from programming language to formal system
changes the way that one has to set about proving it,
and the proof gets a fair bit longer. Both results, by
Turing, and Godel (plus a third theorem of similar
nature by Tarski) were published in the same year
I believe, some time around 1939.

Proving Godel's theorem is the kind of thing that requires
quite a lot of lines. But proving Turings theorem is easy
especially if one can assume knowledge of the basic ideas
of a computing language, which of course wasn't the case
in 1939 - basically I've done it here (using some ideas
from my phd supervisor's way of presenting it).

The results can also be interpreted positively, as saying
that there is no limit that can be set to innovation
in programming, or in mathematics.

There is no way to churn out a list of all possible
good programs, no matter how long you have for the task,
or how versatile your language, as any such enumeration
will be guaranteed to have gaps in it.

Similarly, no way to enumerate all possible true theorems
of mathematics, no matter how rich your mathematical methods.

Just to make this on topic (slightly):

There's no way to enumerate all possible tunings and their properties,
no matter how versatile your methods.

Always, there will be new scales, and new properties of scales,
to surprise us, into the endless future.

This isn't usually added, but I think perhaps it also means that
there will also always be some potential for mistakes when doing really
innovative mathematics, thinking one has proved something, then on reflection
and finding out more in the field, finding that one hasn't after all.

I suppose this is rather OT, but does relate to a few recent things posted
to TL, and it is easy to press the delete key.

Robert

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

5/10/2001 10:19:50 PM

Should be:

Suppose we have a program T with two input files as data that satisfies
T (x,y) = TRUE if x terminates normally with y as data.
T (x,y) = FALSE if x goes into an endless loop with y as data.

Define
T'(x) = T(x,x)

and an intepreter
Interpr(x,y) = interpreter with x as program, y as data
and output of x(y) as return value

I.e. Interpr is a program that can be given any other
program x as one input file, and the data y for x as a second
input file, and will then interpret x, and return with
the return value for x(y)

Now make
P(x,y) =
"
if(Interpr(x,y)== TRUE)
go into endless loop
else
exit
"

Then run P(T',P)

Forgot about the business of defining T' first.

Robert

🔗John A. deLaubenfels <jdl@adaptune.com>

5/11/2001 5:12:42 AM

Robert,

Very sorry if my post left the impression I was claiming that use of
C++ eliminates bugs! Far from it!! It does cut down on them by
allowing useful encapsulation of data and the functions that operate on
it.

My retuning program is a console app, which I can't run under the
debugger, so I track down bugs the "old" way, with debug writes. I do
enjoy the added power of the debugger in applications which can make use
of it.

The process of freeing a program from bugs is never-ending: any given
set of bugs tends to be revealed in a kind of exponential decay fashion.
Some only happen with an extremely unlikely combination of inputs, and
may in practice never reveal themselves.

We should probably take this off-list... thanks for your input.

JdL

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

5/11/2001 8:01:51 PM

Correction again, realised, P' needs to have a single
data file as argument, to fit with T'.

So last bit should be

Define A(_x,y) = A(x,y) with x inlined as data
i.e. a new program A(_x,y) for each choice of x.

Define P'(x) = P(_T',x)

Then run P'(P')

(P' needs to have a single data file to be tested by T')

If P' halts with P' as input, T' says that it doesn't

If P' goes into an endless loop, T' says it halts,
or goes into an endless loop itself.

Either way, the bug finding program T' itself has a bug in it.

So you can never write a perfect debugger that will work for
all possible programs in a normal unrestricted type of
programming language and always detect the "this program has stopped
responding to the system" type bugs, because for at least
one input, the debugger itself will either give the wrong
answer, or it will stop responding to the system.

Robert

🔗Robert Walker <robert_walker@rcwalker.freeserve.co.uk>

5/11/2001 8:25:34 PM

Correction again, realised, P' needs to have a single
data file as argument, to fit with T'.

So last bit should be

Define A(_x,y) = A(x,y) with x inlined as data
i.e. a new program A(_x,y) for each choice of x.

Define P'(x) = P(_T',x)

Then run P'(P')

(P' needs to have a single data file to be tested by T')

If P' halts with P' as input, T' says that it doesn't

If P' goes into an endless loop, T' says it halts,
or goes into an endless loop itself.

Either way, the bug finding program T' itself has a bug in it.

So you can never write a perfect debugger that will work for
all possible programs in a normal unrestricted type of
programming language and always detect the "this program has stopped
responding to the system" type bugs, because for at least
one input, the debugger itself will either give the wrong
answer, or it will stop responding to the system.

Robert