re: odd rhythms - how?

At 12:47 PM 2003-05-14 -0700, Jackie McBride wrote:
>However, I am finding the documentation uh, well, a bit daunting, to say 
>the very very very least. I need to be able to change the timing of events 
>in a midi file, to delete events, to filter events by type & channel, etc. 
>[...]

It's true, the documentation does no better than reflecting the fact that 
modifying existing MIDI files is a complicated task, which the Perl modules 
do only a little to simplify.  That, in turn, is because I didn't see a way 
to simplify the task much at all.

For example, suppose you turn event lists (like you get from 
$track->events_r) into a score (using MIDI::Score), so that each note 
contains a number expressing its start-time, relative to the start of the 
song.  So if you wanted a given event to be twice as long from the start of 
the piece, you can just take its start-time, and double it, right?  So if 
it's 200, ticks you change it to 400 ticks.
Well, it will usually work, but sometimes not -- if there's a set_tempo 
event that happens at 300 ticks, as far as I understand these things, it 
changes how fast the "time" from 300 ticks to 400 ticks actually takes -- 
so that 400 ticks isn't twice as far off as 200 ticks, but maybe only a bit 
farther off, or much much further off, depending on the set_tempo event's 
parameters.
And I think that that set_tempo event is free to be on a completely 
different track, while still affecting all the tracks at once!  So there 
goes any plan of processing tracks independently, which was one of the few 
bits of sanity in the system.

So the mere possibility of set_tempo events existing, adds a whole horrible 
new level of indirection into the system.  And I don't see a way to nicely 
model that.  I could maybe have something that scans for tempo-change 
events and factors them into the time offsets in score events -- but I 
think that to not distort the data too much, the units for the resulting 
time figures would have to be in milliseconds, and so when dumping the 
notes in a score, one would see quite large numbers like start-times, 
potentially with roundoff errors, 276912.333332, which make the whole 
system look somehow even messier than it is.

And that's just /one/ of the hassles in the repertory of MIDI 
events.  Consider the problem of transposition -- it's just a matter of 
taking every note-number and doing some math on it, right?  Well, first 
off, I'm not sure if or how pitch_wheel events would also have to be 
altered too; and more importantly, there's an exception: with notes on 
channel 9, the note-numbers don't represent pitches/tones, but instead 
different percussion instruments, regardless of pitch.

In short, to be able to generate a MIDI file (like with MIDI::Simple), you 
can learn a small subset of MIDI and stick with it, and  get along just 
fine.  But to be able to process existing MIDI files, you have to know the 
whole mess.  Or rather, you can learn a subset of it, and programs you 
write based of that partial knowledge will work -- except when they 
don't.  And one has no idea how often that'll be.  (Altho try it and see...)


I'm not suggesting it's impossible to make it easier to deal with MIDI 
files -- but I mean that I'm so acquinted with the current frameworks that 
I can't see how to innovate outside of them.  So others will have to be the 
ones to come up with different ways of doing/representing things, out of 
which your problems can be solved.


>Also, (& I'm sorry, Mr. Moderator, I know this might be stretching things 
>a bit), does anyone know of a good IDE for PERL that doesn't cost an arm, 
>a leg, & both eyes? I know about komodo, however, I happen to be blind, & 
>no screenreader I've seen to date can detect where the caret is, making it 
>just a *little* difficult to edit with. So, if anyone has any suggestions 
>regarding that, please feel free to contact me offlist as well.

I'd be interested to hear what people can suggest for this.  Personally I 
just use a plaintext editor (PFE under MSWin, emacs under Unix) but that's 
just by force of habit.


I'm also quite dismayed at Komodo and your screen-reader not getting along 
well.  On the one hand, I'm sometimes amazed that screen-readers can EVER 
make any sense of GUIs out there; but on the other hand, GUIs are messy to 
program, but ya know, it's not rocket science, and I think that if the GUI 
construction systems out there had started out with accessibility as a 
requirement from day 1, it would have shone a ray of clarity into the 
system that I think would have helped us all, not just blind users -- even 
down to mundane details like tabbing order and key assignments.

Akh, don't get me started!

--
Sean M. Burke    http://search.cpan.org/~sburke/