Joss-reviews: [REVIEW]: MIDI.jl: Intuitive handling of MIDI data made for musicians

Created on 12 Jan 2019  ·  175Comments  ·  Source: openjournals/joss-reviews

Submitting author: @Datseris (George Datserus)
Repository: https://github.com/JuliaMusic/MIDI.jl
Version: v1.1.3
Editor: @Kevin-Mattheus-Moerman
Reviewer: @ssfrr, @jfsantos
Archive: 10.5281/zenodo.2591437

Status

status

Status badge code:

HTML: <a href="http://joss.theoj.org/papers/e0cfc67982f857ed96d906ff2266aa15"><img src="http://joss.theoj.org/papers/e0cfc67982f857ed96d906ff2266aa15/status.svg"></a>
Markdown: [![status](http://joss.theoj.org/papers/e0cfc67982f857ed96d906ff2266aa15/status.svg)](http://joss.theoj.org/papers/e0cfc67982f857ed96d906ff2266aa15)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@ssfrr & @jfsantos, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

  1. Make sure you're logged in to your GitHub account
  2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.theoj.org/about#reviewer_guidelines. Any questions/concerns please let @Kevin-Mattheus-Moerman know.

Please try and complete your review in the next two weeks

Review checklist for @ssfrr

Conflict of interest

Code of Conduct

General checks

  • [x] Repository: Is the source code for this software available at the repository url?
  • [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
  • [x] Version: v1.1.3
  • [x] Authorship: Has the submitting author (@Datseris) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

  • [x] Installation: Does installation proceed as outlined in the documentation?
  • [x] Functionality: Have the functional claims of the software been confirmed?
  • [x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

  • [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
  • [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
  • [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
  • [x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
  • [x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

  • [x] Authors: Does the paper.md file include a list of authors with their affiliations?
  • [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • [x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

Review checklist for @jfsantos

Conflict of interest

Code of Conduct

General checks

  • [x] Repository: Is the source code for this software available at the repository url?
  • [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
  • [x] Version: v1.1.3
  • [x] Authorship: Has the submitting author (@Datseris) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

  • [x] Installation: Does installation proceed as outlined in the documentation?
  • [x] Functionality: Have the functional claims of the software been confirmed?
  • [x] Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

  • [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
  • [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
  • [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
  • [x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
  • [x] Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

  • [x] Authors: Does the paper.md file include a list of authors with their affiliations?
  • [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
  • [x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?
accepted published recommend-accept review

Most helpful comment

I will probably get to it around the middle of next week.

--
João Felipe Santos

On Mon, 21 Jan 2019 at 03:25, Kevin Mattheus Moerman <
[email protected]> wrote:

@ssfrr https://github.com/ssfrr, @jfsantos https://github.com/jfsantos,
can you give me an indication as to when you think you'll be able to do
this review? Let me know if you have questions. Thanks!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openjournals/joss-reviews/issues/1166#issuecomment-455986097,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAWZYUEWtjo_Hq_Fa05FKDORhJeOiSOks5vFXmIgaJpZM4Z8jgp
.

All 175 comments

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @ssfrr, it looks like you're currently assigned as the reviewer for this paper :tada:.

:star: Important :star:

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

  1. Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

watching

  1. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

notifications

For a list of things I can do to help you, just type:

@whedon commands
Attempting PDF compilation. Reticulating splines etc...

@Datseris, @ssfrr, @jfsantos, this is where the review takes place. There are instructions at the top of this issue as well as a check list which will guide you through the process. If all boxes are ticked and reviewers recommend acceptance this submission will be accepted in JOSS.

You can comment on minor things here and we encourage your to use check lists (- [ ] in markdown). Larger/longer issues are better discussed in a separate issue which you can open on the submission repository and refer to here.

Thanks again for helping with the review process!!!!!

Let me know if you have any questions.

@Datseris can you work on fixing that figure in the paper? Let me know if you need help.

@Kevin-Mattheus-Moerman I do not know how to fix this figure, as I said in a previous comment in the previous issue. It is a standard .png figure that is included with the standard ![description](figure) format. The figure doesn't have overly big whitespace either.

From my perspective this is a problem of the "compilation/pdf-generation" procedure. If you know what I have to do then please let me know.

@arfon any idea what is causing the figure to be off center in this paper?

@Datseris looks a bit like it is an inline picture so I tried to add extra lines in the PR https://github.com/JuliaMusic/MIDI.jl/pull/111.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Thank you Kevin, it worked. I'll add a better caption now...

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@ssfrr, @jfsantos, can you give me an indication as to when you think you'll be able to do this review? Let me know if you have questions. Thanks!

I will probably get to it around the middle of next week.

--
João Felipe Santos

On Mon, 21 Jan 2019 at 03:25, Kevin Mattheus Moerman <
[email protected]> wrote:

@ssfrr https://github.com/ssfrr, @jfsantos https://github.com/jfsantos,
can you give me an indication as to when you think you'll be able to do
this review? Let me know if you have questions. Thanks!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openjournals/joss-reviews/issues/1166#issuecomment-455986097,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAWZYUEWtjo_Hq_Fa05FKDORhJeOiSOks5vFXmIgaJpZM4Z8jgp
.

Hello @Kevin-Mattheus-Moerman , @jfsantos , @ssfrr . While I was trying to improve MIDI.jl I realized that I had to do a breaking bugfix. If you are interested you may look at https://github.com/JuliaMusic/MIDI.jl/pull/112 but this is in no way relevant to the paper.

Although this is a breaking change it is a bugfix and thus does not require a major version increment. Regardless, I have released version 1.1 that includes a warning of this change. if possible, please associate this paper with version 1.1 and not with version 1.0. Thank you.

@ssfrr, @jfsantos can you give an update on the review process? Thanks!

Hi Kevin, sorry for the delay. I should be able to take a look at this next week

I will work on it next Monday. Sorry for the delay.

--
João Felipe Santos

On Thu, 31 Jan 2019 at 11:13, Spencer Russell notifications@github.com
wrote:

Hi Kevin, sorry for the delay. I should be able to take a look at this
next week


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openjournals/joss-reviews/issues/1166#issuecomment-459403693,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAWZaceQfYcKdikttZFGz_B6CcnG08zks5vIxYtgaJpZM4Z8jgp
.

Uhm, excuse me, but I believe I have to bump this.

@ssfrr, @jfsantos sorry to bother you again but it would be great if you could get started with this review. Thanks!

@Datseris apologies for the delay encountered so far

@Kevin-Mattheus-Moerman it's no problem, and I certainly hope I didn't come as across as impolite! It's because (I assume) we are all doing these things voluntarily as side projects that it is easy to forget things. So a reminder can be helpful in such cases.

Hello all, I just started my review. The version I get from Github is 1.1.1 but the review form says 1.0.0. The paper doesn't mention a specific version, so I guess that is a non-issue?

Minor issues:

  • [ ] The version I get from Github is 1.1.1 but the review form says 1.0.0 (the actual paper doesn't mention a specific version, so I guess this is either a non-issue or the paper should specify which version it describes)
  • [x] Most of the references are missing a DOI.
  • [x] Figure 1 is mentioned in the text as appearing right below the text, but is actually rendered on the next page. Please fix the text and point the reader to Figure 1 instead of assuming it is going to be rendered on a specific position.

Another question:

  • [x] The paper only describe examples of note events on MIDI, but the protocol/format deals with a lot more than just note events (like velocity changes, communication with multiple instruments in different channels, etc). Does the software address these other events? Is it future work or do the maintainers have no interest in supporting those?

Thank you for the review @jfsantos .

Figure 1 is mentioned in the text as appearing right below the text, but is actually rendered on the next page. Please fix the text and point the reader to Figure 1 instead of assuming it is going to be rendered on a specific position

Please read the latest version of the pdf, where this issue is fixed. whendon will compile a new one for you now. Towards my side there is only two issues: remove references with missing DOIs and answer the question:

The paper only describe examples of note events on MIDI, but the protocol/format deals with a lot more than just note events (like velocity changes, communication with multiple instruments in different channels, etc). Does the software address these other events? Is it future work or do the maintainers have no interest in supporting those?

The core MIDI protocol is already implemented in MIDI.jl. These details far exceed the scope of a publication and are not discussed in the paper (and I believe I am already at the limit of word count suggested by JOSS).

Please read the documentation for more: in short, all MIDI/META/SysEx events are possible to write and read using MIDI.jl as well as any instrument channel (which as a result covers the entire MIDI protocol).

Anything exceeding what is already implemented is not of interest for the developers of MIDI.jl.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Please read the documentation for more: in short, all MIDI/META/SysEx events are possible to write and read using MIDI.jl as well as any instrument channel (which as a result covers the entire MIDI protocol).

Maybe just mention this somewhere in the paper or documentation? I tried to find it but on a quick search did not find anything mentioning events that were not notes.

Anything exceeding what is already implemented is not of interest for the developers of MIDI.jl.

Sounds good, and I don't think this needs to be mentioned anywhere.

Maybe just mention this somewhere in the paper or documentation? I tried to find it but on a quick search did not find anything mentioning events that were not notes.

I am not sure I agree with this statement, because this is already mentioned in the documentation. Here is my justification:

Searching the documentation (using the search bar) for "META EVENT" brings me here: https://juliamusic.github.io/JuliaMusic_documentation.jl/dev/midi/io/#MIDI.TrackEvent which lists clearly (at least I believe so) the existence of and how to create or read META/MIDI/SysEx events.

If one can create any of these three track events then one can implement the entire midi protocol.


Please let me know if this is still unclear.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Alright, I have fixed the missing DOIs. Now all cited literature includes a DOI.

I updated the checkboxes for the minor issues and review accordingly. I don't know what are the specific guidelines for versioning on JOSS but the paper does not describe which version of MIDI.jl it is talking about.

Ideally I would like this paper to be associated with version 1.1.0. I have added an explicit statement about this in the manuscript now. Of course, it falls into the hands of @Kevin-Mattheus-Moerman whether this will be accepted and further more implemented, as it falls beyond my power to make such a change on whedon.

Getting rolling now, basing my review on the proof from 3 days ago

This paper also references and uses MusicManipulations.jl. Is that in-scope for the review, or are we solely considering MIDI.jl?

Review Summary:

MIDI.jl is a Julia package to enable users to read and write MIDI notes and tracks. While there is prior work in this space, it is useful to have a pure-julia implementation for working with MIDI files, as MIDI is a widely-used format for symbolic music representation. This work also includes the MusicManipulations package, which provides additional functionality for quantizing MIDI notes to a predefined grid, translating and transposing arrays of notes, filtering notes, and extracting individual properties into separate time series.

Specific Issues

  • [x] The paper makes the claim "This makes reading MIDI data easier than ever before.", which seems a little promotional and isn't substantiated.
  • [x] There are multiple references to saving the user from worrying about understanding the byte-level representation of MIDI files. I think this can be assumed of any package that parses formatted data files and can be removed.
  • [x] Most of the references are to papers on microtiming, which doesn't seem closely tied to MIDI.jl (though possibly to MusicManipulations.jl). I think these can be pared down to only what's relevant to the given example.
  • [ ] There's unreferenced prior art, e.g. mido, python-midi, pretty-midi and the accompanying paper. That paper also has some references to other packages (as of 2014). It would be useful to see some more discussion of how MIDI.jl compares in approach to these prior libraries. There's also this MATLAB implementation, but given the dependence on MATLAB and the relative complexity of calling into MATLAB relative to Python that is a less compelling comparison. The microtiming example could be slimmed down to compensate.

Thank you @ssfrrr for your review. Let me now answer one by one your specific issues:

  1. Thank you for pointing this out, I have now reworked my introduction.
  2. Please be more specific about this issue. By reading the entire paper I can only find a singular instance: the opening paragraph of the section "Intuitive and simple interface". I could not find any other instance where there are "references to saving the user from worrying about understanding the byte-level representation of MIDI files.". If you believe there are multiple instances of this event please do state them explicitly. In addition, this software (and thus the paper) does not target audio engineers but musicians and scientists. Therefore it cannot be assumed that our users will "just know that they don't have to know about low level representations". We believe this has to be explicitly stated once, and we do so in our paper, again only once.
  3. The editor of this review, @Kevin-Mattheus-Moerman asked me explicitly to include a "clear research application" in our paper, see the comment here: https://github.com/openjournals/joss-reviews/issues/1149#issuecomment-452094559 . As a scientist actively doing research in this field and actively publishing papers in this field I strongly stand that the current number of references should not be reduced further as they are all fully relevant to the example scientific application.
  4. Thank you very much for sharing these references. I have included all of them in the paper (the MATLAB implementation was disregarded) and I have also added notes that compare MIDI.jl to them, in a concluding paragraph.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

I updated the checklist of issues in my comment above.

Please cite their paper as a real reference

Thank you for adding the comparison. Can you clarify items 1 and 2 in the "notable differences" list? Specifically:

The Notes data structure and getnotes functionality that exists in MIDI.jl

Can you expand on how the data structure and note retrieval functionality are different in MIDI.jl from the other libraries? It seems that the main advantage over the other libraries is that MIDI.jl combines the note-on and note-off events into a single note object with a duration (which is definitely a useful feature of MIDI.jl), but pretty-midi seems to have a similar representation. If that's the main difference maybe clarify that here.

The extensibility of MIDI.jl into higher level applications not limited only to raw midi data (see MusicManipulations.jl).

Here again pretty-midi seems to provide some high-level functionality, for instance tempo and beat estimation and note transition matrices.

Thank you for your reply.

Please cite their paper as a real reference

Done.

Can you expand on how the data structure and note retrieval functionality are different in MIDI.jl from the other libraries?

For MIDI.jl the Note is a central structure used everywhere and expanded by other modules. It has a much more important place than just a utility structure. Many functions (as shown in our official documentation) dispatch directly on the Note structure. In addition it has the channel property which I could not find elsewhere. Other than that indeed the "pretty-midi" representation seems quite similar. The paper was updated accordingly.

Here again pretty-midi seems to provide some high-level functionality, for instance tempo and beat estimation and note transition matrices.

I have changed the sentence to:

  1. MIDI.jl is extended further into higher level applications like the ones offered by MusicManipulations.jl or the module MotifSequenceGenerator that can create specially random sequences of notes.

I believe that pretty-midi is not extended by neither MusicManipulations.jl nor MotifSequenceGenerator and thus this is a notable difference.


@Kevin-Mattheus-Moerman can you please resolve the conflict regarding the software version?

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

The reference you have in your references section is for the wrong paper. Also the link you gave is incorrect, and gives a 404. They provide the correct citation as well as a link to the paper in their README.

Please be more careful with your references. As I'm sure you're aware, properly citing prior work is one of the more important aspects of academic publishing. It shouldn't take three rounds of review to get directly-relevant prior work cited.

Please be more careful with your references. As I'm sure you're aware, properly citing prior work is one of the more important aspects of academic publishing. It shouldn't take three rounds of review to get directly-relevant prior work cited.

Wow, sorry for the mistake I did not realize this.

Unfortunately they do not provide the correct citation in their README as you claim. They provide a PDF file and a claim of publication. Of course I tried to find a DOI or an ISBN if the citation is for a book chapter. I have visited the official page for the conference the authors claim to have published in. It is here: https://dblp2.uni-trier.de/db/conf/ismir/ismir2014.html

As you will see for yourself, there is no paper titled "Intuitive Analysis, Creation and Manipulation of MIDI Data with pretty_midi" (but there is a single paper by C. Raffel which I wrongly assumed the correct one). In addition, searching the entire database for author "Colin Raffel" again does not return the claimed paper. You can see this here: https://dblp2.uni-trier.de/pers/hd/r/Raffel:Colin

If you do know where this paper is published, please be kind and share it with us here. The "text" they provide in the README is not enough of a proof to create a proper BiBTeX entry as required per the JOSS standard.

It appears that the short paper was accepted in the Late-Breaking/Demo category. The official conference website has a list of these accepted papers:

http://www.terasoft.com.tw/conf/ismir2014/AcceptedLBDPapers.html

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Thank you @ssfrr for helping me with this. I've now corrected the citation (which as a result also corrected the wrong link).

I have to note that even though I searched the website, I couldn't find an associated DOI for this paper (I don't think one exists). But I hope this is okay because there is at list a link that links to the paper.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

The title for the raffel citation isn't showing up in the references. Maybe something weird with the bibtex?

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Alright, no matter what I try the title of the paper does not appear in the compiled pdf. If anyone knows the solution please let me know as well. The Bib entry I have now (which I stripped to the bare basics) is:

@article{Raffel,
  author    = {Raffel, Colin and Ellis, Daniel P. W.},
  title     = {{Intuitive Analysis, Creation and Manipulation of MIDI Data with pretty_midi}},
  journal   = {Proceedings of the 15th International Society for Music Information
               Retrieval Conference Late Breaking and Demo Papers, {ISMIR} 2014, Taipei, Taiwan, October 27-31,
               2014},
  year      = {2014},
  url       = {http://www.terasoft.com.tw/conf/ismir2014/LBD/LBD29.pdf},
}

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Fiiiiiiiiiiiiiinaly. It is not possible to have underscore in names in latex apparently.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@ssfrr, @jfsantos thanks for your review work!! Please can you check if you can tick those final boxes?

Note that the version will be updated before acceptance so that box (which has been removed in future review issues) can safely be ticked.

@ssfrr, can you check the reference which should now be in good shape?

@whedon check references

Attempting to check references...

@Datseris Some minor editorial comments on the paper

  • [x] Can you check the sentence "A music note can be (in its most basic level) deconstructed into just four numbers: the temporal position that the note is played, the duration, the pitch and the intensity (strength with which the note is played, also called velocity)". Perhaps it should read: "A music note can be (in its most basic level) deconstructed into just four numbers: the temporal position that the note is played in, the duration, the pitch[,] and the intensity (strength with which the note is played, also called velocity)"

  • [x] "This easy to use high level interface allows MIDI.jl to be extendable. In e.g. another
    software package MusicManipulations.jl we provide general functions for manipulating
    (and further analyzing) music data.
    For example, the function quantize from the package MusicManipulations.jl allows
    the user to quantize any Notes instance to any grid." I propose to remove "this", to rephrase the part with "e.g.", and to remove the enter/paragraph break. i.e.: -> "The easy to use high level interface allows MIDI.jl to be extendable. For instance ~~ In e.g~~, in another software package MusicManipulations.jl we provide general functions for manipulating (and further analyzing) music data. For example, the function quantize from the package MusicManipulations.jl allows the user to quantize any Notes instance to any grid."

  • [x] Check the use of "high level" and "high-level" please use the hyphen consistently

  • [x] Add comma after "In addition" in "In addition[,] it has plenty more use for scientific applications."

  • [x] Please remove: ", which also has an associated publication" (i.e. the citation alone is sufficient)

  • [x] Consider rephrasing the following: "Something similar exists in pretty-midi as well but for example there is no channel property." e.g. to something like "Although the package pretty-midi contains similar functionality, it lacks the channel property."

  • [x] If DAW is an acronym can you please define it?

  • [x] Consider rephrasing "There is also no sequencer functionality in MIDI.jl, which is in example in python-midi." to something along the lines of: "Sequencer functionality, which has been implemented in for instance the python-midi package, is currently lacking in MIDI.jl"

  • [x] The following sentence sounds a bit vague, can you rephrase or perhaps expand with more examples too: "pretty-midi has some other high level functionality (like e.g. basic tempo estimation) also absent in MIDI.jl.", perhaps this improves the sentence especially if you expand it a bit: "MIDI.jl currently lacks some basic high-level functionality such as tempo estimation, which have been implemented in packages like pretty-midi."

  • [x] For the reference "Does it swing? Microtiming deviations and swing feeling in jazz", I would recommend (if possible) to upload it as a pre-print on some pre-print server (if allowed by publisher see here: http://www.sherpa.ac.uk/romeo/index.php), and to cite the DOI of the pre-print in this paper.

@Kevin-Mattheus-Moerman thank you for your reply.

I have implemented all your suggestions besides the final one. Unfortunately the research group associated with this publication has decided to _not_ publish it in a non peer-reviewed outlet (such as pre-print servers). In addition the paper is currently under review in a peer-reviewed journal, which makes me believe there is no reason to waste resources into putting it on some archive.

But there is no problem. If JOSS does not allow citing to-be-published work I can simply remove the paragraph that references this work. I believe the rest of the manuscript already makes a strong case for the scientific relevance of MIDI.jl.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@Kevin-Mattheus-Moerman thank you for your reply.

I have implemented all your suggestions besides the final one. Unfortunately the research group associated with this publication has decided to _not_ publish it in a non peer-reviewed outlet (such as pre-print servers). In addition the paper is currently under review in a peer-reviewed journal, which makes me believe there is no reason to waste resources into putting it on some archive.

But there is no problem. If JOSS does not allow citing to-be-published work I can simply remove the paragraph that references this work. I believe the rest of the manuscript already makes a strong case for the scientific relevance of MIDI.jl.

That is fine. The pre-print is only a recommendation so you can leave it as is. Thanks.

@Datseris I've gone through your revisions. There is one more point remaining:

  • [x] Please remove: ", which also has an associated publication" (i.e. the citation alone is sufficient)

That is fine. The pre-print is only a recommendation so you can leave it as is. Thanks.

Thank you very much for understanding.

Please remove: ", which also has an associated publication" (i.e. the citation alone is sufficient)

Ops, so sorry I forgot this. It is fixed now!

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

LGTM. boxes checked.

Thanks @ssfrr

@whedon check references

Attempting to check references...

```Reference check summary:

OK DOIs

MISSING DOIs

INVALID DOIs

  • None
    ```

@Kevin-Mattheus-Moerman am I supposed to do something? From the compiled pdf I can see that all articles that do have a DOI display it properly. I think whedon is pointing out references that I have in the .bib file but I don't actively use in the article.

@Datseris okay. Thanks for clarifying that. If you clean up the .bib file we can avoid this error but it sounds like your paper is in good shape.

@Datseris looks like we are nearly there. I will soon recommend that this work is accepted in JOSS. At this point, can you please:

  • [ ] Archive a copy of the reviewed software on a service like Zenodo (some follow these steps) and list the DOI of this archived version here?

  • [ ] Provide the version/release tag for the reviewed and archived version? E.g. it likely moved on from v1.0.0

Thanks

@ssfrr, @jfsantos thank you for your review work!!! :tada:

Thanks for the support @Kevin-Mattheus-Moerman , here is the DOI from ZENODO:

DOI

The version is v1.1.3

@whedon set 10.5281/zenodo.2591437 as archive

OK. 10.5281/zenodo.2591437 is the archive.

@whedon set v1.1.3 as version

OK. v1.1.3 is the version.

The DOI link produces an error but it does seem correct: https://zenodo.org/record/2591437#.XIfeO4WnxBI. Perhaps it takes a while to register properly as @Datseris has just created it.

@openjournals/joss-eics this paper is ready to be accepted

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Hi @Datseris — I'm going to ask you to edit the metadata of the Zenodo deposit (no need to get new version or new DOI) so the title and author list match the JOSS paper.

I do have some editorial suggestions on the paper:

  • Documentation: "very well documented" >> remove "very"
  • "The documentation link can be found here." >> It's awkward to have "here" as an active link in a PDF (or even a website, where it's considered bad form!). You could add the URL to the references list, instead? Or simply spell out the full URL (or create a short URL) in the body text.
  • "Because of the rich documentation, in tis paper…" >> this sentence is unnecessary, because all JOSS papers are requested _not_ to include any documentation.
  • Given the above notes, I recommend removing the heading "Documentation" and merging the sentences left to the "Introduction" section.
  • various places: high-level interface, low-level interface missing the hyphen in the compound adjective
  • various missing commas, after "In this paper," after "In addition," after "e.g.," and "In the following."
  • "the data structure we create" >> unclear: is it the data structure _you_ (the authors) created as part of your design process? (in which case it should be in past sense), or is ti the data structure that the software creates when it is being used? (in which case the subject of the sentence is not "we")
  • "The easy to use high level interface" >> missing hyphens in compound adjectives
  • Scientific Application: "see (references)">> if you are citing references as parts of a sentence, please use the Author (Year) format: For the syntax to obtain brackets in the right places, see:
    https://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.htm
  • Necessity of MIDI.jl — the fact that no other package offers the functionally does not make it necessary! I think you can remove the heading here, and move that lonely sentence into the Related Software section. (The case for need of the software was made in the previous section.)
  • Do a search for the word "very" and in each appearance ask yourself if you really need it.

Finally, you are citing _"Does it swing? Microtiming deviations and swing feeling in jazz"_, which is apparently unpublished. Is it possible to deposit the preprint somewhere? (Like OSF preprints, or similar.) Citation to a non-public artifact is discouraged.

Hi @labarba ,

In the latest master commit I implemented all your points.

Scientific Application: "see (references)">> if you are citing references as parts of a sentence, please use the Author (Year) format: For the syntax to obtain brackets in the right places, see:
https://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.htm

I don't understand where you are pointing at... In text I have:

These have been studied extensively in the literature and their importance and influence are debated strongly, see  [@Madison2011, @Butterfield2010, @Fruehauf2013, @Davies2013, @Senn2016, @Hofmann2017] and references therein.

every reference is named. In the pdf all references are expanded to the Author (Year) format.


Finally, you are citing "Does it swing? Microtiming deviations and swing feeling in jazz", which is apparently unpublished. Is it possible to deposit the preprint somewhere? (Like OSF preprints, or similar.) Citation to a non-public artifact is discouraged.

No, this is not possible, please see the discussion I had with @Kevin-Mattheus-Moerman in the comment above: https://github.com/openjournals/joss-reviews/issues/1166#issuecomment-468617973

Citation to a non-public artifact is discouraged.

That may be true, but our group discourages non peer reviewed publications. We would appreciate your respecting of our choice.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Regarding the citations, whether in-text or not, imagine if the format of the article used superscripts for citations: it would be quite weird to see a verb with a superscript but no subject, right? So, when you use the citation as part of speech in a sentence, you display it differently than if the reference is parenthetical (and could be replaced with a footnote and not look weird).

See: https://rmarkdown.rstudio.com/authoring_bibliographies_and_citations.htm#citation_syntax
... the part about in-text citations.

Regarding your decision _not_ to post a pre-print of the other manuscript, that is of course your prerogative. But in that case, please remove it from the references list. You can still mention it in the text, with something like: "we currently have a manuscript under review titled "Blah" that used this software."

I'm still a little surprised by your answer, though. Pre-prints are increasingly recognized as a valid and important tool for open science. Most journals now accept pre-printing and don't count it as prior publication. Have a look at: https://en.wikipedia.org/wiki/List_of_academic_journals_by_preprint_policy

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Hi @labarba ,

In the latest version I've tried to answer your comments again. By reading the "in-text citations" part what I've taken is that I should replace brackets with parenthesis.

Hi @Datseris — I'm going to ask you to edit the metadata of the Zenodo deposit (no need to get new version or new DOI) so the title and author list match the JOSS paper.

Looks like this is still pending?

The documentation says:

You can also write an in-text citation, as follows:

@smith04 says blah.

No brackets.

Looks like this is still pending?

Yeap, fixed now. I had to publish the changes: https://zenodo.org/record/2591437

No brackets.

I've removed all brackets from current version. Let's see:

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@whedon accept

Attempting dry run of processing paper acceptance...

Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/548

If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/548, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.
@whedon accept deposit=true

```Reference check summary:

OK DOIs

  • 10.1137/141000671 is OK
  • 10.1037/a0024323 is OK
  • 10.1525/mp.2010.27.3.157 is OK
  • 10.1177/1029864913486793 is OK
  • 10.1525/mp.2013.30.5.497 is OK
  • 10.3389/fpsyg.2016.01487 is OK
  • 10.1080/09298215.2017.1355394 is OK
  • 10.1177/0305735617697507 is OK
  • 10.1177/0305735617697507 is OK
  • 10.1371/journal.pone.0026457 is OK
  • 10.1371/journal.pone.0127902 is OK
  • 10.1371/journal.pone.0186361 is OK
  • 10.1007/978-1-4612-0919-5_38 is OK
  • 10.1371/journal.pone.0127902 is OK
  • 10.1073/pnas.1324142111 is OK

MISSING DOIs

INVALID DOIs

  • None
    ```

It looks like you have a bunch of entries in the paper.bib file that are not cited in the paper. I think you will need to clean up the .bib file, because these are listed as citations in the xml that we send to Crossref. See:
https://github.com/openjournals/joss-papers/blob/6d4ea9c3a81a9603b6532c3eb9466cc9b93f3d42/joss.01166/10.21105.joss.01166.crossref.xml

@arfon — Can you confirm that we need the paper.bib file to contain _only_ the references cited in the text? I'm not sure about this.

@arfon — Can you confirm that we need the paper.bib file to contain only the references cited in the text? I'm not sure about this.

Yes please.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@whedon check references

Attempting to check references...

```Reference check summary:

OK DOIs

  • 10.1137/141000671 is OK
  • 10.1037/a0024323 is OK
  • 10.1525/mp.2010.27.3.157 is OK
  • 10.1177/1029864913486793 is OK
  • 10.1525/mp.2013.30.5.497 is OK
  • 10.3389/fpsyg.2016.01487 is OK
  • 10.1080/09298215.2017.1355394 is OK
  • 10.1371/journal.pone.0026457 is OK
  • 10.1371/journal.pone.0127902 is OK
  • 10.1371/journal.pone.0186361 is OK
  • 10.1073/pnas.1324142111 is OK

MISSING DOIs

INVALID DOIs

  • None
    ```

Perfect, I removed all unused references! (The reference you see above without DOI does not have an associated DOI to it)

Do you want to add caps protection, {MIDI}, in the title, so it appears in upper case?

@labarba Thanks for the suggestion. I did that now in the latest commit.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

@labarba Putting {} in the title in the markdown file didn't work so I removed it. I'd prefer to continue with the publication process instead of adding caps protection.

@whedon generate pdf

Attempting PDF compilation. Reticulating splines etc...

Okay done this now @labarba .

@whedon accept

Attempting dry run of processing paper acceptance...

```Reference check summary:

OK DOIs

  • 10.1137/141000671 is OK
  • 10.1037/a0024323 is OK
  • 10.1525/mp.2010.27.3.157 is OK
  • 10.1177/1029864913486793 is OK
  • 10.1525/mp.2013.30.5.497 is OK
  • 10.3389/fpsyg.2016.01487 is OK
  • 10.1080/09298215.2017.1355394 is OK
  • 10.1371/journal.pone.0026457 is OK
  • 10.1371/journal.pone.0127902 is OK
  • 10.1371/journal.pone.0186361 is OK
  • 10.1073/pnas.1324142111 is OK

MISSING DOIs

INVALID DOIs

  • None
    ```

Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/552

If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/552, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.
@whedon accept deposit=true

@whedon accept deposit=true

Doing it live! Attempting automated processing of paper acceptance...

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

  1. Check final PDF and Crossref metadata that was deposited :point_right: https://github.com/openjournals/joss-papers/pull/553
  2. Wait a couple of minutes to verify that the paper DOI resolves https://doi.org/10.21105/joss.01166
  3. If everything looks good, then close this review issue.
  4. Party like you just published a paper! 🎉🌈🦄💃👻🤘

    Any issues? notify your editorial technical team...

Congratulations, @Datseris, your JOSS paper is now published!

Sincere thanks to the editor: @Kevin-Mattheus-Moerman, and reviewers: @ssfrr, @jfsantos 🙏

:tada::tada::tada: Congratulations on your paper acceptance! :tada::tada::tada:

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](http://joss.theoj.org/papers/10.21105/joss.01166/status.svg)](https://doi.org/10.21105/joss.01166)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.01166">
  <img src="http://joss.theoj.org/papers/10.21105/joss.01166/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: http://joss.theoj.org/papers/10.21105/joss.01166/status.svg
   :target: https://doi.org/10.21105/joss.01166

This is how it will look in your documentation:

DOI

We need your help!

Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

Thank you very much.

I just want to be on the safe side, since doi2bib.org cannot find the DOI of this publication.

Is the following BibTeX entry the correct one?

@article{Datseris2019,
  doi = {10.21105/joss.01166},
  url = {https://doi.org/10.21105/joss.01166},
  year  = {2019},
  month = {mar},
  publisher = {The Open Journal},
  volume = {4},
  number = {35},
  pages = {1166},
  author = {George Datseris and Joel Hobson},
  title = {{MIDI}.jl: Simple and intuitive handling of MIDI data.},
  journal = {The Journal of Open Source Software}
}

According to https://www.doi2bib.org/bib/10.21105%2Fjoss.01166 (this looks correct to me):

@article{Datseris2019,
  doi = {10.21105/joss.01166},
  url = {https://doi.org/10.21105/joss.01166},
  year  = {2019},
  month = {mar},
  publisher = {The Open Journal},
  volume = {4},
  number = {35},
  pages = {1166},
  author = {George Datseris and Joel Hobson},
  title = {{MIDI}.jl: Simple and intuitive handling of {MIDI} data.},
  journal = {Journal of Open Source Software}
}
Was this page helpful?
0 / 5 - 0 ratings