timing in midi & midiperl

Sean:

If I may--there are really 2 timebases in midi that need to be
considered--delta ticks, e.g., the time between events, & absolute ticks,
e.g., the time from the beginning of the sequence.  Ticks are independent of
tempo in that if you have a resolution, say, of 96 ppq, then no matter what
your tempo is, for every quarter note, 96 ticks are generated.  The quarter
notes are produced at a faster rate with faster tempos, but the ppq always
remains static.  With that in mind, time calculations should be able to be
performed using ticks.  Or do I misunderstand what you're saying?

In terms of tempo, the midi specification says the following:
a)  In a format 0 file, tempo events are scattered throughout the track;
b)  in a format 1 midi file, tempo events are contained on the first track
only (as of 1.0.4).

Have you ever by any chance seen Paul Messick's Maximum Midi Toolkit???  It
does a whole stinkin lot with windows dll's & all that crapola, which is
superfluous for my needs, but it has a good section on midi timing.  HTH.
The light shines in the darkness, and the darkness did not overcome it. John
1:5
Jackie McBride, Qchord distributor & author of qchord manual for visually
impaired
website:
www.tacticus.com/qchord
email:
[email protected]
or
[email protected]
----- Original Message -----
From: "Sean M. Burke" <[email protected]>
To: "Jackie McBride" <[email protected]>; <[email protected]>
Sent: Thursday, May 15, 2003 4:12 AM
Subject: 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/
>
>