[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Midi entry
From: |
Richard Shann |
Subject: |
Re: Midi entry |
Date: |
Tue, 26 Jul 2016 16:01:02 +0100 |
On Tue, 2016-07-26 at 15:45 +0200, Mojca Miklavec wrote:
> Hello,
>
> Just before I give up about midi2ly:
>
> On 22 July 2016 at 17:50, David Kastrup wrote:
> > Mojca Miklavec writes:
> >
> >> That said, I wouldn't mind suggestions for some good OpenSource (GUI)
> >> MIDI editors. I have a bunch of weird MIDI files that I would like to
> >> turn into scores. They sound OK, but I'm not exactly sure if they were
> >> just obfuscated on purpose or if they are recordings of "human
> >> players" and thus the timings are some horrible (i)rational numbers.
> >
> > midi2ly is unsuitable for quantizing human play. It's really just a
> > software-produced Midi reimporter.
> >
> >> I did try to play with different settings of midi2ly, but didn't yet
> >> find the magic recipe for fixing the timing of those (obfuscated?)
> >> MIDIs.
> >
> > No, it's just that midi2ly's quantizer is just not for human play.
>
> The problem is that this is what I'm getting in the *.ly file:
>
> trackAchannelA = {
> \key f \major
> \time 3/4
> \key f \major
> \tempo 4 = 170
> \tempo 4 = 170
> \tempo 4 = 170
> \skip 4.
> \tempo 4 = 170
> \skip 16
> \tempo 4 = 169
> \skip 16
> \tempo 4 = 168
> \skip 16
> \tempo 4 = 167
> \skip 16
> \tempo 4 = 166
> \skip 16
> \tempo 4 = 165
> \skip 8
> \tempo 4 = 170
> \skip 16*17
> \tempo 4 = 170
> \skip 16
> ...
>
> I would suspect that this looks like obfuscation of the midi file
> rather than side-effect of human play, but I could be wrong.
I think the first track is just being used to vary the tempo. Whether
that is because it originated in a human performance (it would be a
sophisticated program that generated this in that case) or some sort of
human-modified MIDI performance (you could easily "conduct" a MIDI
performance causing the tempo to vary throughout and record the modified
MIDI by adding a track with the tempo changes that you conducted).
>
> In any case, I got reasonable output for at least some midi files with
>
> midi2ly -a --duration-quant=16 --key=-1 --start-quant=16 file.midi
Interestingly, Denemo creates reasonable output straight out of the box
- in many ways a measure of its crudity - it ignores all those tempo
changes and so you get one empty staff and then the four parts. If that
was a hard as it got, you could write a script to output the parts into
your own templates quite easily. For real human-generated MIDI where
each 1/4 note has a slightly varying number of ticks you would need
something that does not yet exist, but (as I mentioned in an earlier
email) I'm working on it :)
Richard