jimm / midilib Goto Github PK

Hey Jimm!

Is there a straight forward way to force a file/sequence into Format Type 0 using midilib? See attached an example binary structure of a Type 1 file with multiple tracks. Is there a way to force this into Type 0 with only 1 track without losing data? Sorry can't really find this in the docs.

Love from Germany
Mohan

Is this possible? How would I best go about implementing functionality like this and contribute?

I wouldn't mind trying to fix this and sending you a pull request. Before I spend time on it, I was wondering if there was a reason you ignore the sequence.format in SeqWriter#write_header:
https://github.com/jimm/midilib/blob/master/lib/midilib/io/seqwriter.rb#L32
?

I am not that much into the whole midi spec sorry about that, but maybe you can help me on this one maybe this is a problem in the midi file and not a problem with midilib:
When I just run the attached original midi file (I don't know how this was exported) through midilib via
seq.each { | track | track.each { | event | ... } }
without even manipulating it at all I get the result shown in the attached screenshot. It works until the marked point, then notes seem to get shifted "forward in time".

Maybe this has something to do with midi export resolution, delta times, I would be happy if anyone could help me understand this.

Thank you so much already!

event.time_from_start = new_start_time

does not work. I assume its got something to do with delta time?

Do you have any plan to release midilib 3.x to rubygems?

Midilib in rubygems is stopped at 2.0.5, which turned out to not compatible to ruby 3. I believed that is the latest development for a long time.
However today I checked out the latest source and the test successfully ran in ruby 3.1.2.
I expect the valuable library to be updated and live with ruby 3 in rubygems. Is there any issue which prevents the release, or any breaking changes?

It seems that the pitch bend messages are having their bytes read in the wrong order in the MIDI::PitchBend class.

This particulary affects some files like this one, created with tuxguitar: http://dl.dropbox.com/u/2701879/music/racemeeee.mid

Just opening and saving the same file (works with some of the code in the examples directory) will yield strange results.

I don't know if that's the right solution, but I'm using a monkey patched Midi::PitchBend in a project of mine that processes midi files and it seems to work the expected way:

class MIDI::PitchBend
    def data_as_bytes
        data = []
        data << (@status + @channel)
        # the values where switched
        data << ((@value >> 7) & 0x7f) # msb
        data << (@value & 0x7f) # lsb
    end
end 

Thank you

The length_to_delta method on sequence currently strips any decimal place to return only the integer part. When dealing with data that has been input from live playing (not quantized) this could be problematic.

eg:

seq.ppqn = 96
seq.length_to_data(0.237) #22.752 is interpreted as 22.

instead of to_i, would it not perhaps be better to use .round?

Hi,

Could a simple example be added to the intro-documentation so that newcomers like me can figure out how to play midi files from within ruby?

Whether it is possible to do so without having to rely on external players, or whether it is only possible with i.e. mplayer.

Whatever the solution, I think a short section to tell people how to play those created midi files would be AWESOME!

It looks like the CC codes in consts.rb are off:

  CC_HOLD_2 = 69
  CC_GEN_PURPOSE_5 = 50
  CC_GEN_PURPOSE_6 = 51
  CC_GEN_PURPOSE_7 = 52
  CC_GEN_PURPOSE_8 = 53
  CC_TREMELO_DEPTH = 92

The general purpose CCs 5 through 10 should start at 70, not 50.

A description of the MIDI file format can be found in a few places such as www.borg.com/~jglatt/tech/midifile.htm.

www.borg.com/~jglatt/tech/midifile.htm is giving a 404

I'm getting this (test_tottoro.bat, test_tottoro.sh, ruby 2.7, both linux and windows):

chan_settings: ["d", "me", "p", "m", "m", "m", "me", "p", "mew"]
track , num_tracks 7, index 0
track #<MIDI::Track:0x000000000682f978>, num_tracks 7, index 1
...
mixing lchan:8 into 2
--- render into text ---
Traceback (most recent call last):                                                 
        7: from autosiril.rb:905:in `<main>'                                       
        6: from autosiril.rb:905:in `times'                                        
        5: from autosiril.rb:913:in `block in <main>'                              
        4: from autosiril.rb:913:in `map'                                          
        3: from autosiril.rb:914:in `block (2 levels) in <main>'                   
        2: from autosiril.rb:914:in `!='                                           
        1: from autosiril.rb:914:in `=='                                           
autosiril.rb:416:in `<=>': undefined method `note' for nil:NilClass (NoMethodError)

How to fix?

I just ran a short MIDI file through examples/reader2text.rb, and the @curr_ticks output appeared erratic. (See the whole output on this pastie.) The only two values that showed up for @curr_ticks were 0 and 240, but in fact the MIDI file has 14 moments of attack for a total of 17 "note on" events.

I'm hoping to make use of a tool which will reliably indicate the order and simultaneity (where extant) of MIDI events. Can you shed some light on this for me?

Hi there! I use midilib in a couple of my own projects, so thanks for writing it!

One of my projects is a toy FM synthesizer that can play a MIDI file. To detect the end of a song, I use the latest of the final note-off event, the final event in any track, or the final oscillator envelope decay. It'd be nice to be able to use the delta time of the FF 2F 00 track end meta-event to determine track length instead, at least for looping.

If this sounds interesting, I'd be happy to open a merge request that adds a track_length or duration attribute to MIDIFile, and modify SeqReader#eot to save track length (but while still not adding the META_TRACK_END event to the event list, in keeping with documented behavior).

MIDIs (even in format 1) can have multiple tempos.

method beats_per_minute in sequence.rb assumes that there is one single tempo on the first track for the entire song. Tempo events can occur on any track, but more importantly, multiple tempo events often occur throughout a song to account for accelerandos, etc.

# Returns the song tempo in beats per minute.
def beats_per_minute
  return DEFAULT_TEMPO if @tracks.nil? || @tracks.empty?
  event = @tracks.first.events.detect { |e| e.kind_of?(MIDI::Tempo) }
  return event ? (Tempo.mpq_to_bpm(event.tempo)) : DEFAULT_TEMPO
end

As a consequence, pulses per second is also incorrect. You can't make the assumption that there is a single, static tempo. A correct implementation of this requires summation across multiple tempos.

def pulses_to_seconds(pulses)
  (pulses.to_f / @ppqn.to_f / beats_per_minute()) * 60.0
end

The core Array class is being monkey patched in lib/midilib/track.rb. Its definition of Array#split clashes with the implementation found in ActiveSupport which makes using midilib with Rails applications difficult.

I've created a patch at 326391d that avoids monkey patching by creating the MIDI::Array class that extends the core Array class.