13
0
Commit Graph

4 Commits

Author SHA1 Message Date
cd53301d06
Significantly speed up loading SMF tempo-maps
Files that have many tracks, each with tempo information
were near impossible to load (30+ mins on modern 4.2Ghz CPU!),
because tempo is parsed incrementally:

```
For each new track:
  for each new tempo-event:
    rewind()
    for each loaded track so far:
      for each event on this track so far
```

This reduces the complexity from O(tracks^2 * tempos^2)
to O(tracks * tempos).

"Come Thou Fount Tempo Map.mid" has 238 Tracks and 56168 total
Tempo Changes (236 per track). This now requires only 56168 iterations
in smf_create_tempo_map_and_compute_seconds, rather than 1.64e+9
iterations
2022-02-05 17:33:21 +01:00
c6b87972b1
Remove unused libsmf seconds/time API
This significantly speeds up parsing MIDI files with complex
tempo-maps. e.g. "Black MIDI Trilogy_2.mid" has 24134 Tempo
changes. Prior to this commit parsing that file took over 5 minutes.
now it loads in under one seconds (libsmf only; libardour still
add overhead, and now needs about 30-40 seconds, previously
it took about 10 mins).

The problem was that every call to `smf_track_add_event_pulses()`
calls `seconds_from_pulses()` which calls `smf_get_tempo_by_seconds()`
which iterates over the tempo-map:

  for every midi-event { for ever tempo until that midi-event {..} }

This does not scale to 3.5M events and 24k tempo-changes.
2020-07-16 18:38:03 +02:00
23e6dd5f6b
NO-OP: backport some libsmf doc and warnings 2020-07-16 17:58:04 +02:00
eaae38ba84 move evoral/src/* to evoral/ 2019-11-02 16:32:18 -06:00