13
0
Commit Graph

9 Commits

Author SHA1 Message Date
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
ba7db8759b
SMF: remove unused variable (from 803dab7d87) 2020-07-16 18:35:43 +02:00
803dab7d87
SMF: various backports from libsmf PR7
see also https://github.com/stump/libsmf/pull/7

* Fix validity checks of escaped data
* Handle non-EOT-terminated tracks.
* Fix buffer overflow on tempo change event
* Fix memory leaks in case loading fails
* Fix a logic errors in extract_escaped_event()
* Fix the assertion problem `is_sysex_byte(status)`
* Make libsmf more tolerant to malformed MIDI files.
  (fixes import of files generated by NoteEdit)
2020-07-16 18:00:40 +02:00
23e6dd5f6b
NO-OP: backport some libsmf doc and warnings 2020-07-16 17:58:04 +02:00
43158047ed
SMF: use glib macros for endian conversion 2020-07-16 17:57:59 +02:00
c264ab6c95
Remove debug output 2020-04-23 02:29:45 +02:00
9a93583ef7 fully initialize SMF tempo information to default (4/4, 120bpm)
Leaving CPC and 32nd-per-quarter at -1 causes arithmetic errors later if the SMF
file doesn't contain an explicit time signature meta-event
2020-04-21 21:17:14 -06:00
39bdde4250 Use labs() for long instead of abs() 2019-12-09 23:25:51 +01:00
eaae38ba84 move evoral/src/* to evoral/ 2019-11-02 16:32:18 -06:00