-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add load and save for midi files #140
Conversation
I'm not sure if it was a good idea to have removed readMIDIFile and writeMIDIFile completely.. I just realized that after pushing.. could you please share your thoughts on this? @Datseris Should those functions stay along with load/save? |
Hi, my understanding is that you have to first do a PR at FileIO, and once a version with your changes is tagged at file IO then we can merge this PR here...? Not sure which one has to be done first. Can you open a PR at FileIO as well, so that the devs there can guide us? The functions |
Okay, I will add the functions back and deprecate them. I've opened a PR at FileIO.jl. JuliaIO/FileIO.jl/pull/323 |
JuliaIO/FileIO.jl#323 looks good to me. You can commit a Manifest.toml with that FileIO branch so that the CI here passes, and then make a new MIDI release, update JuliaIO/FileIO.jl#323 with tests, and then we'll merge it and tag a new FileIO release. I don't know much of the MIDI internal here so it would be great to at least see a green check in CI (by committing a Manifes.toml). After the approval of this PR, you can then remove the Mainfest.toml. |
Codecov Report
@@ Coverage Diff @@
## master #140 +/- ##
==========================================
- Coverage 60.28% 57.65% -2.64%
==========================================
Files 8 8
Lines 564 588 +24
==========================================
- Hits 340 339 -1
- Misses 224 249 +25
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's posted via my phone so sorry for not able to format the codes in the comments.
Except two minor comments, other changes are good to me.
@@ -1,5 +1,6 @@ | |||
using MIDI | |||
using Test | |||
using FileIO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depredations should be explicitly tested as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done (in another PR).
src/midifile.jl
Outdated
@@ -111,6 +168,9 @@ function writeMIDIFile(filename::AbstractString, notes::Notes) | |||
return midi | |||
end | |||
|
|||
@deprecate writeMIDIFile(filename::AbstractString, data::MIDIFile) FileIO.save(filename, data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's more controllable to pass the depredation to 'MIDI.save' instead of 'FileIO.save'. same to 'load'.
(It's FileIO that depends on this package and not this package depends on FileIO.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the inacuraccy:
@deprecate writeMIDIFile(filename::AbstractString, data::MIDIFile) FileIO.save(filename, data) | |
@deprecate writeMIDIFile(filename::AbstractString, data::MIDIFile) save(filename, data) |
and similar to load
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(It's FileIO that depends on this package and not this package depends on FileIO.)
This is so confusing. How does FileIO depend on MIDI? Doesn't MIDI.jl just extend the FileIO.save
method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MIDI creates a new function save
/load
, which is not FileIO.save
/FileIO.load
. MIDI only tags the MIDI.load
/MIDI.save
function with FileIO.File
type, so that FileIO.load
/FileIO.save
calls the MIDI.load
/MIDI.save
via invokelatest
. That's why I said "FileIO depends on MIDI".
To be clear, MIDI.load
and FileIO.load
are two functions; they're not specifications of the same function FileIO.load
.
Ref: https://juliaio.github.io/FileIO.jl/stable/implementing/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@johnnychen94 MIDI.load and MIDI.save functions takeFile{format"MIDI"}
type in its argument and passing a filename string to them gives a method error. FileIO.load and FileIO.save take a regular string as input and it works fine with them. Would it be fine to use FileIO.load or FileIO.save itself in this case instead of the MIDI functions?
@deprecate writeMIDIFile(filename::AbstractString, data::MIDIFile) FileIO.save(filename, data)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can instead use:
@deprecate writeMIDIFile(filename::AbstractString, data::MIDIFile) save(File{format"MIDI"}(filename), data)
The problem with calling FileIO.save
is that FileIO.save
has a try-and-call mechanism to loop the backends, currently, there might only be MIDI
that supports this file format, but what if there's another package, say MIDI2
, which happens to have higher priority than MIDI
in FileIO
? The answer is, when the user calls MIDI.writeMIDIFile
, he is eventually calling MIDI2.save
, which is definitely not what we want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Done (in another PR).
@johnnychen94 your suggestion is a bit weird. You want us to release a version of MIDI that explicitly includes some FileIO branch? And then when installed by users their FileIO installation will also become some branch? Why? Tests passed perfectly before, can't we just tag a normal FileIO release that includes these magic numbers and midi extension? And you said MIDI should be tested at FileIO? I checked at FileIO's test folder, and the 100s of packages that extend it are not tested there. So where would MIDI be tested? |
After you approve this PR, the temporary
Yes, there're hundreds of file formats not properly tested inside FileIO. But if you want to make sure FileIO's development doesn't break MIDI's load/save, it's suggested to do so. See JuliaIO/FileIO.jl#319 for an example. |
Okay, I understand, so you don't need us to tag a release with this Manifest.toml. Just to merge this PR? |
Yes, merge this PR when |
@VasanthManiVasi this code: mthd = join(map(Char, read!(f, Array{UInt8}(undef, 4))))
if mthd != MTHD
error("Not a valid MIDI file. Expected first 4 bytes to spell 'MThd', got $(mthd)")
end does not exist in the new @johnnychen94 can you check one more time the file I've deleted the Manifest.toml file (of course now tests are failing). |
@Datseris I've listed open(f) do s
skipmagic(s) # utility function for skipping magic numbers
midifile = load(s)
end |
This is expected, Reference: https://juliaio.github.io/FileIO.jl/stable/implementing/ |
Hi, I've added the load and save functions to use with FileIO.jl.
Until a PR to FileIO.jl, the following should be added to FileIO/src/registry.jl or can be executed in the REPL for the load/save on midi to work
add_format(format"MIDI", UInt8[0x4d, 0x54, 0x68, 0x64], [".mid", ".midi", ".MID"], [:MIDI => UUID("f57c4921-e30c-5f49-b073-3f2f2ada663e")])
I've tested them and the test sets have passed along with some other tests on midi files locally.