On Wed, 5 Sep 2001, Glenn Saunders wrote:
> So a program has to be pretty smart in taking all the _intervals_ between
> the notes and trying to find somewhere, like fitting a jigsaw puzzle, to
> home it on the 2600's scale, then report back the results. Most likely
> even a best-fit is going to result in unhittable notes that will require
> rescoring, like hitting the note an octave above or below the desired note,
> etc...
>
Right, I understand relative pitch. If the entire band is tuned a quarter
step flat (-50 cents?), the music would still sound fine to anybody but a
music expert with perfect pitch.
(But I can't remember: are there 100 cents between half-steps (C and C#), or
full steps (C and D))?
> The quick page I can create will only be able to show you filtered views
> which you can then experiment with.
>
> You'd have to break your song down and isolate the range of notes it needs
> to generate, and compare that against these views. If it doesn't fit,
> you'd have to manually modulate the notes up and down until you find a best
> fit.
>
Even if you're having the user manually modulate up & down, your web page could
display notes that are (say) >10 cents out of tune in either direction in red.
That alone would make life easier...
> But even then it's tricky because, let's say you wanted a filtered view
> where the target cent value was +50. That is right in the middle a quarter
> tone between two notes. So you can't go just by note values anymore
> because it's on the fence between two different notes. It gets really
> confusing trying to compare a MIDI score to that because then a C in your
> score could match a C# -49 or a B+49.
>
Well I wasn't planning on using the note value at all... convert the notes
(from MIDI files, or text files of note names, or whatever) into their value
in cents. The lowest C would be 0, C# would be 100 (? or is it 50?), etc.
Now a CS major could write a more clever algorithm that could do this better,
or anyway faster, but you *could* just brute-force it, keeping track of the
mean/mode/std. deviation/whatever for each possible offset from 0 to X cents,
X being how far the user's willing to transpose up. The program wouldn't be
all that fast, but you wouldn't be running it *that* often, either... and if
Perl turns out to be too slow, well, this is all math, and it could be re-coded
in C pretty easily (I wouldn't be using any of the perl shortcuts like
regular expressions, except maybe in the parser).
If anybody reading this finds themselves mumbling about vector arithmetic or
O log N execution times, they're free to laugh at me, or write a better
algorithm, or both. I never got far with higher math, so I tend to take the
simplest solution that will work, with problems like these.
There's one more aspect... this program will be able to make educated guesses
only. It can give you a sequence of TIA sound values that are statistically
likely to sound kind of like what you want, but only the human ear can be the
real judge of what sounds good and what sounds like crap (and humans never seem
to agree on this kind of thing, but that's another topic entirely...)
Brian
---
If a trainstation is the place where trains stop, what is a workstation?
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
