Octet perc fix

Gene/Manuel,

I think I have fixed Gene's retuning of the Octet. It was simple, once I took a look at it. I recommend the tools mf2t.exe and t2mf.exe that come from the MIDIOX site (MidiFile2Text and Text2MidiFile).

I translated octf.mid to text, using the -t and -n switches:

-n : write notes in symbolic rather than numeric form. A-G optionally followed by # (sharp) followed by octave number.
-t : event times are written as bar:beat:click rather than a click number

(Note: I did not try the -t and -a combination...)

...as in:

c:\mf2t -tn octf.mid octf.txt

Upon getting a text file, I simply opened up with a decent text editor and started looking. Unlike in a sequencer, it didn't list the items simply in time-order, but in time order *by track*. I saw this way that Scala tunes each track, using multiple midi channels as necessary to avoid 'bending' pitches on the same channel. This got me thinking...

I then did a text search for "ch=10", which is what I knew was causing the problem. Sure enough, all these events occurred in only one track. Now to see how far things went...

I then search for "ch=11" and upwards numerically, finally realizing that in retuning this piece that contains 8 tracks of musical data, Scala used midi channels 1-13; I found no events on channels 14-16. It seemed safe, then, that I could reassign all the events from 10 to 14 (or higher). This was accomplished with an easy search/replace.

I then saved the file (octfx.txt) and retranslated:

c:\t2mf octfx.txt octfx.mid

I loaded the new midi file into Sonar and it seems like it does what Gene intended.

Sooooooo....

Manuel, I'm not sure what to say. Maybe you should use the original file, before Gene tuned it, and see if you can duplicate the addition of channel 10 events even if they are supposed to be included (of course, we expect that Gene will have double-checked his results as well...). I see the logic in your rechannel method, but maybe something slipped through the cracks.

And Gene, just note that the midi file you used isn't flawless: if you bring the sucker up in a notation window, you'll see that it is off by one beat throughout the entire piece, and all the downbeats actually fall on beat 3. For a drummer like me, that is a piece that is 33.33% out of tune! We can also see there is a limit to the complexity of a piece before you run out of channels.

For large scores, one could end up with multiple files, and each 16 channel allotment file could go to a different midi port, utilizing multiport midi devices to use 64 or more midi channels for a whole lot of retuned polyphony.

I've uploaded the new midi file to Gene's folder in the files area; there should be an announcement on the list...

Good night,
Jon

`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`
Real Life: Orchestral Percussionist
Web Life: "Corporeal Meadows" - about Harry Partch
http://www.corporeal.com/
NOTE:
If your reply bounces, try --> jonszanto@...

--- In MakeMicroMusic@yahoogroups.com, "Jonathan M. Szanto"
<JSZANTO@A...> wrote:
> Gene/Manuel,
>
> I think I have fixed Gene's retuning of the Octet.

Thanks, Jon. This doesn't look too hard, and again thanks for taking a
look at it.

> And Gene, just note that the midi file you used isn't flawless: if you
> bring the sucker up in a notation window, you'll see that it is off
by one
> beat throughout the entire piece, and all the downbeats actually
fall on
> beat 3. For a drummer like me, that is a piece that is 33.33% out of
tune!
> We can also see there is a limit to the complexity of a piece before
you
> run out of channels.

That's the way the fella sequenced it.

> For large scores, one could end up with multiple files, and each 16
channel
> allotment file could go to a different midi port, utilizing
multiport midi
> devices to use 64 or more midi channels for a whole lot of retuned
polyphony.

Are you suggesting splitting the midi into separate instrument tracks,
feeding the results into Scala, and then trying to put the whole think
back together again? Or was this for Manuel's benefit?

Gene,

{you wrote...}
>Are you suggesting splitting the midi into separate instrument tracks, >feeding the results into Scala, and then trying to put the whole think >back together again? Or was this for Manuel's benefit?

I'm suggesting that there is an upper limit on the polyphony/complexity of a score that will cause Scala's channel allocation retuning scheme to fail. Once one begins to run out of channels (there are only 16 per midi port) to swap around as it inserts pitch bends, the only option is to sequence a score as two pieces, and then copy/paste one of them into the other, after reassigning the midi output to a 2nd port, thereby giving a new set of 16 midi channels.

And I don't think this could necessarily be included as a Scala feature, because Scala would have no knowledge of how to assign midi ports - I think.

Cheers,
Jon