search

openjournals / joss-reviews

Reviews for the Journal of Open Source Software
Creative Commons Zero v1.0 Universal
720 stars 38 forks source link

[REVIEW]: soni-py: A Pitch-Based Sonification Package #2446

Closed whedon closed 2 years ago

whedon commented 4 years ago

Submitting author: !--author-handle-->@lockepatton<!--end-author-handle-- (Locke Patton) Repository: https://github.com/lockepatton/sonipy Branch with paper.md (empty if default branch): Version: v1.0 Editor: !--editor-->@arfon<!--end-editor-- Reviewers: @faroit, @benjaminrose Archive: Pending

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

Status

status

Status badge code:

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

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) by leaving comments 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

@faroit & @benjaminrose, 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.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @harpolea know.

✨ Please try and complete your review in the next six weeks ✨

Review checklist for @faroit

Conflict of interest

Code of Conduct

General checks

Functionality

Documentation

Software paper

Review checklist for @benjaminrose

Conflict of interest

Code of Conduct

General checks

Functionality

Documentation

Software paper

whedon commented 4 years ago

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @faroit, @benjaminrose it looks like you're currently assigned to review this paper :tada:.

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

: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

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@whedon generate pdf
whedon commented 4 years ago 
Reference check summary:

OK DOIs

- 10.1007/978-3-540-49127-9_4 is OK

MISSING DOIs

- None

INVALID DOIs

- None
whedon commented 4 years ago

:point_right: Check article proof :page_facing_up: :point_left:

faroit commented 4 years ago

@harpolea @lockepatton I checked weather this software meets the JOSS criteria with respect to other related packages. In this context, I found two other packages:

Both of them can be used for auditory display/sonification, which also is the purpose of this software. One of them, sonipy, even carries the same name as this submission. Before continuing with here, I guess that it would be recommended to rename this software. Furthermore, it is suggested to includes a detailed comparison to related packages in the paper.

david-worrall commented 4 years ago

Hi, I am the author of the sonipy mentioned. I am not averse to, would even encourage, an amalgamation of related projects if that is appropriate, as your "A Perceptually Uniform Sonification Package" subtitle suggests it might. My website mentioned, above, is in need of an update as a result of the publication of my recent Sonification Design book (Springer). I'd be interested in hearing from you, with an outline of your project: dworrall@colum.edu. Thanks. David

benjaminrose commented 4 years ago

I like how simple this package makes it to generate an audio equivalent to a scatter plot. However, it seems to need a few things before it can be accepted in JOSS. In addition, I would agree with @faroit that the authors need to determine where this package fits in the broader landscape of sonification software.

harpolea commented 4 years ago

Thank you @faroit and @benjaminrose for your feedback! As it seems like there may be some substantial changes required before this review can proceed, I am going to pause this review and label it as pending-major-enhancements for now whilst they are being dealt with.

@lockepatton, please take your time to address the concerns raised above, and let me know when you are ready for me to un-pause the review.

arfon commented 3 years ago

:wave: @lockepatton - can I check what your plans are here? As this issue hasn't seen any updates for a good number of months now I'm wondering whether it might be best to close this review and re-invite a submission in the future if you manage to address the feedback here?

lockepatton commented 3 years ago

Hi everyone,

Apologies for being slow in addressing these changes, and thanks for the reminder @arfon. I've made a commit on the last remaining issue. If the changes I've committed there are sufficient, we can unpause the review.

I'm going to make this a priority this week and the next so we can finish this submission. Thanks.

arfon commented 3 years ago

Thanks @lockepatton - for clarity could you link to the "commit on the last remaining issue" here so we can direct the reviewers back to this?

Also, both reviewers asked for clarification on the relationship with other related community efforts. A writeup of any outcomes/updates here from your perspective would be important before we un-pause this submission.

lockepatton commented 3 years ago

Hi @arfon! Here is the outstanding issue I was referencing.

Re the clarification on the relationship with other community efforts:

This sonipy code is specifically designed to create an open-access scientifically useful method to listen to data, with accuracy and use on par with reading plots visually. While many sonification tools exist, this was specifically designed in collaboration with the University of Washington Hearing and Speech Sciences to guarantee that a linear increase in y value will correspond to a perceptually uniform increase in perceived “pitch”. This means that while frequency varies non linearly, the user is listening to data in a perceptually uniform space - a linear plot sounds like a linear sweep in pitch. This technique allows us to probe smaller difference in y values than we can discern visually. We’ve also found we can hear periodic details in data that are not easily visually discerned.

Thanks to the nature of human hearing, we can audibly discern subsequent pitch differences of 10 cents (a logarithmic measure of pitch interval). On a y scale ranging from 0 to 10, that corresponds to hearing variations as small as dy~0.03 - a number which rivals our visual perceptions of scatter plot detail. This simultaneous depth and range makes pitch-varied audio an incredibly powerful and accessible tool for understanding nuances in data. This approach also opens up science and citizen science to participants who are visually impaired, and empowers blind and visually impaired (BVI) individuals to explore their own data.

In fact, this code was specifically designed for this use case. Already it’s been used by students at Perkin’s School for the Blind, a semester Ohio State Astronomy Program for BVI high school students, and is the foundation for an NSF-funded TransientZoo project, a citizen science program that will allow participants, including BVI individuals, to classify astronomical supernova lightcurves using sound. For more details, here is a link to my paper where I go into the TransientZoo case study.

re: the state of sonification tools

The two codes that you linked above - @faroit - are both very interesting but distinct sonification cases. In emailing with @david-worrall, the author of the other code “sonipy”, it’s clear that their code is more an awesome cumulation of interface codes. While a potentially cool idea in the future to connect this sonipy with their infrastructure to connect more with the field of sonification, this code is most useful and accessible to BVI students as already designed and implemented. It’s a tool designed to be plugged into various science disciplines (in fields otherwise unfamiliar with sonification) and thus fits well without a complete sonification library.

The second code interactive-sonification is awesome and designed for interactive audio processing. Our code is specifically designed non-interactively; while it uses audio processing, it uses thinkDSP as the audio processing tool. Our code does the work of designing a perceptually uniform sonification for accurate use in listening to science plots. We specially built this tool as there was no other sonification that filled this use.

Since I last updated everyone, I've closed the last issue, so if everyone agrees (especially @faroit as we were resolving the last issue here, I believe we can unpause this review. Let me know if you need anything else from me in the meantime.

arfon commented 3 years ago

Got it, thanks for the detailed response @lockepatton.

@faroit, @benjaminrose - I realize it's been quite some time since you both agreed to this review but, provided you find @lockepatton's responses above satisfactory, would you both be willing to pick up yours reviews sometime soonish?

Many thanks!

faroit commented 3 years ago

@arfon sure. I will look into this today

benjaminrose commented 3 years ago

I've got some time this week and next to try and finish this review.

benjaminrose commented 3 years ago

@whedon generate pdf

whedon commented 3 years ago

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

benjaminrose commented 3 years ago

The following is a much better statement of need and summary of the field than what is in the paper (and I assume the documentation). These ideas need to be added to the paper and also ensure they are in the documentation.

In addition, the content currently in the paper is about twice as long as required and should be tightened up. For example, "The Code" section is not required for the paper since it is acting like documentation.

Re the clarification on the relationship with other community efforts:

This sonipy code is specifically designed to create an open-access scientifically useful method to listen to data, with accuracy and use on par with reading plots visually. While many sonification tools exist, this was specifically designed in collaboration with the University of Washington Hearing and Speech Sciences to guarantee that a linear increase in y value will correspond to a perceptually uniform increase in perceived “pitch”. This means that while frequency varies non linearly, the user is listening to data in a perceptually uniform space - a linear plot sounds like a linear sweep in pitch. This technique allows us to probe smaller difference in y values than we can discern visually. We’ve also found we can hear periodic details in data that are not easily visually discerned.

Thanks to the nature of human hearing, we can audibly discern subsequent pitch differences of 10 cents (a logarithmic measure of pitch interval). On a y scale ranging from 0 to 10, that corresponds to hearing variations as small as dy~0.03 - a number which rivals our visual perceptions of scatter plot detail. This simultaneous depth and range makes pitch-varied audio an incredibly powerful and accessible tool for understanding nuances in data. This approach also opens up science and citizen science to participants who are visually impaired, and empowers blind and visually impaired (BVI) individuals to explore their own data.

In fact, this code was specifically designed for this use case. Already it’s been used by students at Perkin’s School for the Blind, a semester Ohio State Astronomy Program for BVI high school students, and is the foundation for an NSF-funded TransientZoo project, a citizen science program that will allow participants, including BVI individuals, to classify astronomical supernova lightcurves using sound. For more details, here is a link to my paper where I go into the TransientZoo case study.

re: the state of sonification tools

The two codes that you linked above - @faroit - are both very interesting but distinct sonification cases. In emailing with @david-worrall, the author of the other code “sonipy”, it’s clear that their code is more an awesome cumulation of interface codes. While a potentially cool idea in the future to connect this sonipy with their infrastructure to connect more with the field of sonification, this code is most useful and accessible to BVI students as already designed and implemented. It’s a tool designed to be plugged into various science disciplines (in fields otherwise unfamiliar with sonification) and thus fits well without a complete sonification library.

The second code interactive-sonification is awesome and designed for interactive audio processing. Our code is specifically designed non-interactively; while it uses audio processing, it uses thinkDSP as the audio processing tool. Our code does the work of designing a perceptually uniform sonification for accurate use in listening to science plots. We specially built this tool as there was no other sonification that filled this use.

Since I last updated everyone, I've closed the last issue, so if everyone agrees (especially @faroit as we were resolving the last issue here, I believe we can unpause this review. Let me know if you need anything else from me in the meantime.

benjaminrose commented 3 years ago

I do not think this is project is currently at an acceptable state for JOSS, however, it is close. The main concern is over the substantialness of the scholarly effort. @lockepatton, a strong statement of need will alleviate this concern. Looking at the JOSS guidelines, I think this project "is likely to be cited by your peer group" if the need for this specific project is well addressed.

Before accepting, I see the following required changes.

arfon commented 3 years ago

Thanks for your update @benjaminrose. These sound like good recommendations for @lockepatton to address.

Ensure that @faroit is also satisfied with the state of the project.

@faroit - how are you getting along here? I see there are still a number of unchecked items in your review checklist.

david-worrall commented 3 years ago

Hello all,

Perceptual uniformity is a complex interdisciplinary research field. It is a big claim in of this project, not yet substantiated. It would bode well for the credibility of the project itself to temper that claim, as there is more work to do towards perceptual uniformity that is beyond the use of (some) psychophysical mapping parameters. For example, see the work of  Roddy et al. on cognitive metaphors, and Friberg et al. (with /Director Musices/ for example) - as overviewed in Ch 4 of my book.mThis is where the perceptual research is largely developing in the field, including in my own /Sonipy /software framework.

=== On the use of the name /Sonipy ===/ My extensive and still active project of that name has been evolving for more than 10 years. It does not make sense to confuse the research/development/user space with a new project of the same name. The 'noise' so generated is at best inconvenient, especially as there are other viable alternatives; /Pysonic /for example seems available.

I wish the project well and, as I indicated in correspondence, am not averse to a friendly merger, once this project is past the beta stage.

Dr David Worrall Professor, Audio Arts and Acoustics Columbia College Chicago 33 E. Ida B. Wells Drive Room 601A Chicago, ILLINOIS, USA 60605

https://en.wikipedia.org/wiki/David_Worrall_(composer)Wikipediahttps://en.wikipedia.org/wiki/David_Worrall_(composer)Instagramhttps://www.instagram.com/david.r.worrall/Facebookhttps://www.facebook.com/david.worrall.5872/Soundcloudhttps://soundcloud.com/david-worrall-8849455Youtubehttps://www.youtube.com/playlist?list=PL9vjIQ8ca6oOnhOs1fMq1DqhoaxXV-9i0 Personal research/creative practice website: avatar.com.auhttp://avatar.com.au/ New Organised Sound issue (25/1): Computation in the Sonic Artshttps://www.cambridge.org/core/journals/organised-sound/volume/C868728E57C2FEF58217164D7F862577 New Book: Sonification Design: From data to intelligible soundfieldshttps://www.springer.com/gp/book/9783030014964(Springer) (also available through Amazonhttps://www.amazon.com/Sonification-Design-intelligible-soundfields-Human-Computer/dp/3030014967/ref=sr_1_fkmrnull_1?keywords=worrall+sonification&qid=1553803176&s=gateway&sr=8-1-fkmrnull)

On 2020 12 03 08:54, Benjamin Rose wrote:

I do not think this is project is currently at an acceptable state for JOSS, however, it is close. The main concern is over the substantialness of the scholarly effort. @lockepatton https://github.com/lockepatton, a strong statement of need will alleviate this concern. Looking at the JOSS guidelines, I think this project "is likely to be cited by your peer group" if the need for this specific project is well addressed.

Before accepting, I see the following required changes.

  • Update the documentation and paper to more clearly address why this project is needed over other projects already available.
  • The above should also simultaneously address the other aspects missing from the paper (i.e. state of the field).
  • Update the documentation to clearly (likely with links) address how all three third parties participants can interact with the project: 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support. Currently, all three of these are covered by the generic "Have an issue with your operating system? Let us know by opening an issue!"
  • Ensure that @faroit https://github.com/faroit is also satisfied with the state of the project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/2446#issuecomment-738045536, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRJDMWPDLJ6LHCORPMKSS3SS6RBTANCNFSM4OTDCXPQ.

faroit commented 3 years ago

  1. I fully support the comments and suggestions made by @benjaminrose especially that the statements with respect to state-of-the-art should be added to the paper.

  2. I support the view of @david-worrall that the same name for a similar project is confusing (even though david's package is neither on github nor on pypi). Given that merging the projects will probably not happen anytime soon, it looks like to be the best option right now that this submission is going to be renamed.

  3. I still struggle with checking Substantial scholarly effort. The reason is that the submission has barely more than 300LOC when ignoring the copied thinkdsp.py module as mentioned in https://github.com/lockepatton/sonipy/issues/3. I am okay with a very lightweight package being accepted but I would suggest to at least revisit this issue, refactor the code and preferably include librosa as a dependency.

arfon commented 3 years ago

I still struggle with checking Substantial scholarly effort. The reason is that the submission has barely more than 300LOC when ignoring the copied thinkdsp.py module as mentioned in lockepatton/sonipy#3. I am okay with a very lightweight package being accepted but I would suggest to at least revisit this issue, refactor the code and preferably include librosa as a dependency.

Thanks for flagging this @faroit. I had not realized that thinkdsp.py was essentially a dependency here, and not functionality implemented by the author.

@benjaminrose - I notice that you also are yet to check this box off. I'd appreciate your thoughts on this point too (our submission guidelines are here: https://joss.readthedocs.io/en/latest/submitting.html#substantial-scholarly-effort)

benjaminrose commented 3 years ago

@arfon, this is a small project and the scholarly effort is near JOSS’s minimum requirement. In general, I think that science benefits from allowing more works to be published rather than fewer.

This specific case misses most of the examples in the JOSS documentation. However, I feel like this project could have a major impact on the field. In the study of odd astrophysical transients, a field that will see exponential growth in the next decade, light curve comparisons are the main scientific figure. This project has the potential to add audio “light curves” with fewer lines of code than you typically use to reformat a default matplotlib figure. The addition of audio light curves might allow for more inclusive science, viral public outreach, as well as a better scientific understanding of the minor differences in objects.

However, my expectations are not given, and another project may already do this sufficiently well. So a strong statement of need, description of the state-of-the-art, and explanation of how this project is unique is vital to show that though small, it has the potential impact sufficient enough to claim substantial scholarly effort.

benjaminrose commented 3 years ago

I regret to inform @lockepatton and others that it appears Space Telescope Science Institute has also created a sonification package, Astronify. This makes the need for sonipy even more difficult to explain.

lockepatton commented 3 years ago

Thanks for bringing up astronify: this STScI code is, in fact, actually based on our package. We’ve been in touch with the creators (Clara and Scott) over email and video since March of 2020 (when they reached out to us following our presentation of this work at last year’s American Astronomical Society meeting) and have been advising them on the basics of sonification and audio perception since they first began their project (though email, video chat, and regular meetings of the World Sonification Chats). Indeed, we’re mainly just disappointed that they’ve now released and begun promoting their code publicly without consulting or citing us in any way, particularly as their code is directly derived from our work and they were aware that we were in the process of publishing our code as peer-reviewed work in JOSS.

We’d be happy to add a mention of astronify to our paper as yet another example of the impact our code is having on the field of data sonification in astronomy. We’ll also be reminding the astronify creators that they should properly acknowledge our contribution via a JOSS citation.

Apart from adding this mention of astronify, we are almost done incorporating our state-of-the-field summary, making the other minor changes you suggested to the paper, and adding the requested additional documentation; we anticipate that this will be finished by Friday at the latest. Once these changes are made we hope that our package will be considered ready for publication. Please let us know if you need any additional changes to the paper, or if you’d like further clarification on where astronify fits in the sonification landscape as a project derived from our code.

lockepatton commented 3 years ago

Our edits to the paper itself are now complete! The requested changes to the code documentation will also be finished shortly, and we expect to submit those by Monday.

lockepatton commented 3 years ago

@whedon generate pdf

whedon commented 3 years ago

:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:

arfon commented 3 years ago

:wave: @lockepatton - how are you getting on with your changes?

arfon commented 3 years ago

👋 @lockepatton - how are you getting on with your changes?

lockepatton commented 3 years ago

Hi @afron,

Apologies for the delay - things are going well. I believe I've completed most of the requests you asked for listed above. Two are outstanding:

I'm happy to talk in real time if that would be helpful.

Thanks for your suggestions and patience. Pandemic year is not the best year to publish papers apparently.

lockepatton commented 3 years ago

Hi @arfon - following up on this request again. The two questions outstanding are on the use of sonipy and the use of thinkdsp.py. Let me know if there are other open tasks, but for now I'm awaiting your reply on the best way to move forward.

arfon commented 3 years ago

Hi @arfon - following up on this request again. The two questions outstanding are on the use of sonipy and the use of thinkdsp.py. Let me know if there are other open tasks, but for now I'm awaiting your reply on the best way to move forward.

Sorry for the delay @lockepatton.

Given that sonipy already exists, I think it would be appropriate to find a different name. Could something like sonicpy, py-sonic, or python-sonic work?

To your third point, in using librosa as a library - including librosa would be a large coding project, as a lot of the fundamental design of my objects is based on thinkdsp.py. My original choice of audio tool was based upon testing the sonification tools available to me when the code was under development. This was the final best choice at the time. We tested upwards of three different sonification codes and found this to produce the best sound. As changing to librosa would not fundamentally change any aspect of the code for the user, I'm hesitant to make such a change and nervous the sound quality might differ.

While I think @faroit's recommendation is a good one, at this point, I think it's OK to move forward with using thinkdsp.py as the dependency here rather than ask @lockepatton to embark on a significant refactor.

faroit commented 3 years ago

While I think @faroit's recommendation is a good one, at this point, I think it's OK to move forward with using thinkdsp.py as the dependency here rather than ask @lockepatton to embark on a significant refactor.

I agree. Also at a later stage features could be submitted via PR to librosa.

lockepatton commented 3 years ago

Hi @arfon and @faroit!

Perfect. I really agree that librosa could be an awesome eventual upgrade - just not at this moment before publication.

As for the name! sonicpy is not successfully google-able due to the sonic franchise and already has software with that name. pysonic similarly already has a collection of different softwares with that name. May I suggest soni-py? That way the publications we already have with sonipy in the title do not become null and void, but the name is slightly different to avoid confusion with the other soniny. If this sounds good to you, let us know and we'll update all documentation accordingly, as well as update pypl where it is already published under sonipy.

faroit commented 3 years ago

May I suggest soni-py? That way the publications we already have with sonipy in the title do not become null and void, but the name is slightly different to avoid confusion with the other soniny.

sounds good to me. Just be aware of the python limitations for hyphens vs. underscores. pypi supports both, I think...

arfon commented 3 years ago

If this sounds good to you, let us know and we'll update all documentation accordingly, as well as update pypl where it is already published under sonipy.

Also sounds good to me 👍

lockepatton commented 3 years ago

Alight - so I started working on the name change and ran into a hiccup. This stack overflow describes this very well. Basiclaly, I can superficially change the name to soni-py in documentation, but need to leave the python interactable places as sonipy -- these include pypi and the home name of my directory so that the following import does not result in a syntax error: from sonipy.sonify import SonifyTool . Does this seem like an acceptable way to go forward?

lockepatton commented 3 years ago

Those changes are made so if the above is a good solution, I've now complete the changes you asked for. Let me know if there's anything else you see but I believe we can unpause the review!

faroit commented 3 years ago

Alight - so I started working on the name change and ran into a hiccup. This stack overflow describes this very well. Basiclaly, I can superficially change the name to soni-py in documentation, but need to leave the python interactable places as sonipy -- these include pypi and the home name of my directory so that the following import does not result in a syntax error: from sonipy.sonify import SonifyTool . Does this seem like an acceptable way to go forward?

I think it would be better to go with underscores, also otherwise this would not reflect a true renaming. See https://github.com/asteroid-team/asteroid-filterbanks as a good example of dash-hyphen in use at github/packaging/pypi

david-worrall commented 3 years ago

There are (still) two elephants in this room.

1. The package claim: "A Perceptually Uniform Sonification Package" Unless a /huge/ amount of work has gone on in the interim between now and when I last looked, "A Perceptually Uniform Sonification Package" oversells the generality of it:

- The "perceptions" are restricted to that of frequency as pitch is
not a revelation. Over the history of the field, the number of
sonifications that don't treat frequency like that could be counted
on the fingers of one hand. Even then, it only applies the (linear,
log) mapping in its simplest form, without taking into account
Fletcher-Munson and related psychophysical mappings and other
cross-modal sensory affects.  See
https://en.wikipedia.org/wiki/Equal-loudness_contour.
- There there seems no model of a perceptually uniform timbre space,
on which there is a considerable literature.
-There there seems no model of a perceptually uniform temporal
space, let alone models of pulse, meter, etc

2. The package name: sonipy

Surely, given the more than a decade of use of this name for another purpose (see, for example, overviews in Chapters 5 and 6 of Sonification Design: From data to intelligible soundfields https://www.springer.com/gp/book/9783030014964(Springer) it would be better, and more intellectually honest, to not muddy those waters and just choose another name. If for no other reason, the confusion generated by not doing so is likely to negatively impact on the reception of Package #2446 and the perception of the value of that project as a whole.

On 2021 05 18 03:09, Fabian-Robert Stöter wrote:

Alight - so I started working on the name change and ran into a
hiccup. This
<https://stackoverflow.com/questions/54597212/using-hyphen-dash-in-python-repository-name-and-package-name>
stack overflow describes this very well.
Basiclaly, I can superficially change the name to soni-py in
documentation, but need to leave the python interactable places as
sonipy -- these include pypi and the home name of my directory so
that the following import does not result in a syntax error: |from
sonipy.sonify import SonifyTool| . Does this seem like an
acceptable way to go forward?

I think it would be better to go with underscores, also otherwise this would reflect a true renaming. See https://github.com/asteroid-team/asteroid-filterbanks https://github.com/asteroid-team/asteroid-filterbanks as a good example of dash-hyphen in use at github/packaging/pypi

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openjournals/joss-reviews/issues/2446#issuecomment-842955277, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRJDMVJ4H7XWO2CRUPPMT3TOIOEZANCNFSM4OTDCXPQ.

faroit commented 3 years ago

@arfon @david-worrall thanks for your clarifications – especially to 1. However, the paper subtitle has already been changed to Pysonic: A Pitch-Based Sonification Package, so I assume this is a more suitable subtitle. @lockepatton please change it also in the issue title etc.

Regarding the naming issue, as I pointed out earlier, we should encourage authors to respect existing software projects, including its name. @lockepatton to speed up the reviewing process I suggest to find a new name which is less close to the existing package by David Worral.

arfon commented 3 years ago

@arfon @david-worrall thanks for your clarifications – especially to 1. However, the paper subtitle has already been changed to Pysonic: A Pitch-Based Sonification Package, so I assume this is a more suitable subtitle. @lockepatton please change it also in the issue title etc.

Right, thanks for pointing this out @faroit. I've updated the review thread to match the paper title.

On the naming issue: This is a challenging situation especially given that it sounds like there are already papers published that link to this tool under the name sonipy. Ultimately I don't think JOSS can (or should) rule on package naming but I would like to consult with the broader JOSS editorial team on this point

faroit commented 3 years ago

On the naming issue: This is a challenging situation especially given that it sounds like there are already papers published that link to this tool under the name sonipy. Ultimately I don't think JOSS can (or should) rule on package naming but I would like to consult with the broader JOSS editorial team on this point

@arfon sure, that sounds reasonable. Another thing to consider would be a clear statement in the readme of the project and the paper title that references the software created by @david-worrall – assuming he would be satisfied with such a disclaimer?

lockepatton commented 3 years ago

We are happy to add a statement at the top of our README disambiguating SoniPy and soni-py and point people to David Worrall's work, and have done so!

From what I'm gathering from @faroit and @afron, it sounds like sticking with soni-py, with a disambiguation in the README sounds like a good place to settle. Am I missing anything else? If not, shall we unpause? Thanks!

arfon commented 3 years ago

Am I missing anything else? If not, shall we unpause? Thanks!

@lockepatton – are you planning on addressing this feedback from @faroit too? 👇

I think it would be better to go with underscores, also otherwise this would not reflect a true renaming. See https://github.com/asteroid-team/asteroid-filterbanks as a good example of dash-hyphen in use at github/packaging/pypi

lockepatton commented 3 years ago

Oh thanks for the reminder - I was scrolling through convinced I'd mentioned this before but it must have slipped my mind.

I'm very hesitant to republish anything on pypl simply because pypl doesn't remove old publications so the old sonipy will still exist. By renaming it, we'd be clogging up the sonipy namespace even more and risking people run pip install sonipy instead of pip install soni_py, thus installing the older version of two versions of the software or worse installing both. Since SoniPy and soni-py are distinct (both in dashes and capitalization), I'd like to leave it as is with pip install sonipy as our install command and titles including soni-py. Does this seem reasonable to you all?

faroit commented 3 years ago

by renaming it, we'd be clogging up the sonipy namespace even more and risking people run pip install sonipy instead of pip install soni_py, thus installing the older version of two versions of the software or worse installing both.

there are good practices for these issues: See here for pypi. Also, this seems to make things a bit easier: https://github.com/simonw/pypi-rename

I'd like to leave it as is with pip install sonipy as our install command and titles including soni-py. Does this seem reasonable to you all?

I would encourage you to try at least all possible ways to make the hyphenized name as effective as possible – given that these names are still quite close to the project of @david-worrall. Therefore, I would prefer the use of soni_py and soni-pi for the repo name, pypi package and the root src folder of the repo.

@lockepatton as @arfon was pointing out, we can't decide if renaming should take place and we will have to wait for other editors to jump in, so maybe just hold on and wait for more opinions on this matter?

arfon commented 3 years ago

I would encourage you to try at least all possible ways to make the hyphenized name as effective as possible – given that these names are still quite close to the project of @david-worrall. Therefore, I would prefer the use of soni_py and soni-pi for the repo name, pypi package and the root src folder of the repo.

I would also like to see this if possible. I went browsing the source code for your repository @lockepatton and as far as I could tell, it looked like the README had been modified but not a whole bunch more (caveat, I don't know very much about Python packaging).

@lockepatton as @arfon was pointing out, we can't decide if renaming should take place and we will have to wait for other editors to jump in, so maybe just hold on and wait for more opinions on this matter?

Thanks for the suggestion @faroit but I don't think we should wait further. I've consulted with the broader JOSS editorial team and they agree that we ultimately can't mandate name changes by authors. That said, in the spirit of reducing user confusion as much as possible here, I would strongly encourage you @lockepatton to be as comprehensive as possible with this renaming i.e., following some of these suggestions 👇

there are good practices for these issues: See here for pypi. Also, this seems to make things a bit easier: https://github.com/simonw/pypi-rename

lockepatton commented 3 years ago

Hi @arfon and @faroit - it seems like the only remaining issue is resolving and making the name changes where needed. To recap, I've changed the name to soni-py in the following places:

I haven't changed the name in the GitHub repo to lockepatton/soni-py because I believe this'll hurt the efficacy of the code - those who have downloaded this code already will be met with a repository not found error upon attempts to connect with GitHub (updating the code for instance) - something I'd rather not cause unnecessarily to the entire user base. Even before publication, 16 people have already starred the code before publication - and I've advertised this and taught it in groups where this is their first interactions with GitHub and would like to minimize the difficulty of interacting with the code as much as possible.

I also haven't changed it on pip, as mentioned above, because the original "pip install sonipy" will not be removed. Two separate namespaces cause all sorts of issues including duplicate installations on the same machine, installing old versions unnecessarily and a rather clogged namespace on pip. This also asks all of our current users to uninstall sonipy and re-install soni-py unnecessarily.

In short, I'm happy to make any changes that are necessary to resolve the name issue but not want to do at the expense of the usability of the code.

With this in mind, are the current changes satisfactory? Do we need anything else before moving forward with the code?

(@arfon The most update version of the code has major changes ending around 2 months ago, and minor changes up to today.)