lockepatton / sonipy Goto Github PK

I did a few tests using the interactive Jupyter notebook hosted binder by supplying different x and y values with the following default code in one of the cells:

Tone = SonifyTool(x, y)
Tone.play(autoplay=False)

The following lead to a division-by-zero bug:

x = np.array([1, 2, 3])
y = np.array([0, 0, 0])

The following lead to some bug regarding duration scale:

x = np.array([0, 0, 0])
y = np.array([1, 2, 3])

The following lead to a bug that said the waveforms cannot be added:

x = np.array([1, 2, 3, 4, 5, 6, 7, 8, 9])
y = np.array([1, 1, 1, 1, 1, 1, 1, 1, 1.1])

When saving a MultiTone this line:

creates a tones directory. Could this take the default_tones_folder variable instead so that it can be overwritten?

The package comes without automatic unit tests. Since the application is sonification, the only way to test the functionality of this package is to listen to the outputs. As this is hard to reproduce I would strongly encourage to include a few unit tests that produce tones give a short known x/y sequence.

This issue is part of a [https://github.com/openjournals/joss-reviews/issues/2446](JOSS submission review)

PyPI seems to have version 1.0 of soni-py which doesn't have the fractions/math gcd fix #7.
Is it possible to upload the 1.1 version to PyPI?

On Python 3.9 I obtain an error on "from fractions import gcd". Changing the line in thinkdsp.py to "from math import gcd" makes to package work.

the included thinkdsp.py file is only used for a single function - CosSignal. I would suggest to copy just this function (and add unit tests for this) or replace this with librosa, a very popular audio framework, that includes a tone generator as well: https://librosa.org/librosa/generated/librosa.core.tone.html

This issue is part of a JOSS submission review

The contact email address for @lockepatton on the README and other places is no longer contactable.

From the JOSS review criteria list:

Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?

the core API of this software is not documented in detail. I would suggest to build a sphinx-based (given suitable docstrings) documentation and make this available on either gh-pages or readthedocs.

This issue is part of a [https://github.com/openjournals/joss-reviews/issues/2446](JOSS submission review)

The JOSS review criteria recommends to add community guidelines: for a) Contribute to the software b) Report issues or problems with the software c) Seek support

The first point is covered in the readme but in general, a contributing.md document and issue templates would be great additions.

This issue is part of a [https://github.com/openjournals/joss-reviews/issues/2446](JOSS submission review)