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

Standardize tune description format #28

Open
fulldecent opened this Issue Oct 4, 2016 · 11 comments

Comments

Projects
None yet
3 participants
@fulldecent
Owner

fulldecent commented Oct 4, 2016

We should have a common format for describing tunes (series of beeps) across the different implementations in this repository. Extensive searching was done, a simple widespread standard was not found.

Following is proposed:

  1. Simple text file
  2. Each line represents a beep or a pause
    1. Column one is a positive integer number of milliseconds
    2. Column two is a positive integer frequency in Hz, or 0 which represents silence
    3. Columns are separated by a space
  3. Line ending is unix format
  4. File extension is .tune
  5. Although not necessarily part of the tune, consider adding a silence at the end so that looped playback sounds good :-)

Example for mary_had_a_little_lamb.tune:

400 2673
400 2349
400 2093
400 2349
400 2673
400 2673
790 2673
400 2349
400 2349
790 2349
400 2673
400 3136
790 3136
400 2673
400 2349
400 2093
400 2349
400 2673
400 2673
400 2673
400 2673
400 2349
400 2349
400 2673
400 2349
790 2093
400 0    

Work plan:

  • Convert existing tunes into this format, save to tunes/ folder
  • Update each implementation to accept a .tune file on the command line / stdin or however else
    • Using _mm_stream_si128
    • Using counter and threads
    • In Javascript
  • Update run instructions so users know to supply the song file

Related: #1

@rocketinventor

This comment has been minimized.

Contributor

rocketinventor commented Oct 5, 2016

@fulldecent, what was wrong with the human-readable ".song" format described in #1 & #24?

@fulldecent

This comment has been minimized.

Owner

fulldecent commented Oct 5, 2016

@rocketinventor Nothing is wrong with those ideas. For the "standardized" format, the simplest one is preferred.

Going forward I think we will also have a few parsers to bring, say, morse code or midi into this format.

@rocketinventor

This comment has been minimized.

Contributor

rocketinventor commented Oct 7, 2016

@fulldecent It would probably be a good idea to have start, stop, and end of line symbols. While these are not 100% necessary, they would still be useful to improve the resiliency of the parser against poorly formed files, and code. In addition, start and end tokens would allow for arbitrary text to be added before, and after the actual song data.

Making 0 0 or 000 0 the official end token would be trivial to implement (in the example it is 400 0) and does not violate any of the current (proposed) specs.

@fulldecent

This comment has been minimized.

Owner

fulldecent commented Oct 7, 2016

Right now the 400 0 is just a pause so that the tune can be repeated with the correct pause between plays.

@rocketinventor

This comment has been minimized.

Contributor

rocketinventor commented Oct 7, 2016

Oh. That should probably be mentioned in the specs, then.

rocketinventor added a commit to rocketinventor/system-bus-radio that referenced this issue Oct 26, 2016

New song format
Changed over the song parser and accompanying code to be inline with the new, as suggested in issue fulldecent#28.
@rocketinventor

This comment has been minimized.

Contributor

rocketinventor commented Nov 25, 2016

@fulldecent Please update the proposal message to indicate that the JS port has been updated to use this new spec.

@fulldecent

This comment has been minimized.

Owner

fulldecent commented Nov 25, 2016

@rocketinventor Thank you, one check for the good guys

guneysus added a commit to guneysu-arsiv/system-bus-radio that referenced this issue Jun 22, 2017

Follow (#1)
* Added my tested setup

* Fix README.md typo

* C++11 port

* Add my hardware info

I ported the code to C++11.
https://github.com/EzoeRyou/system-bus-radio/blob/master/main.cpp

Tested on my laptop running GNU/Linux.

* Update HARDWARE-INFO.md

* boost song

* cleanup

* aquire number of thread to create from hardware_concurrency()

* Update HARDWARE-INFO.md

* Update HARDWARE-INFO.md

* Update HARDWARE-INFO.md

* Add makefile

* Fix compilation on 32bit

* add make clean target

* Compiles on both linux and mach

* Fix compilation warning

* Use absolute time as per PR#3.

fulldecent#3

* add test data, thanks Jeremy Zerfas

* add test data, thanks Nipun Gunawardena

* add test data, thanks 魚田雅彦

* add test data, thanks Yuji Fujita

* add video

* add video, thanks Chris

* add video, thanks Redgar

* add video, thanks Chris

* add press coverage

* Adding MacBook Pro "Core i7" 2.4 15" Late 2011

And adding minor edits to the MD table.

* Adding Acer Aspire E1-572 info

* Update HARDWARE-INFO.md

Added test results using MacBook Pro (Retina, 15-inch, Mid 2015) and Grundig G8 Traveler II Digital.

* move test data to tsv

* vanillaJS port

* add link to USENIX paper

* move to _mm_stream_si128 folder

* remove executables

* move folder

* simplify busy work

* add project link

* Add my test and HW info

* add test data, thanks Quan

* add radio used

* add distance for Nipun

* Added smb.song

I copied the file from pull request #1.

* syntax fixes

There were a few missing semi colons and undefined vars before which are now fixed.

* Made song editable

Based on pull request #1...
The list of frequencies to be played has been moved from the JS to a textbox in the HTML.
Editing the content of the box will change what gets played.
The format also is more human human readable and consistent with the songfile from #1.
If you copy and paste the smb.song file, it should work.

* more nitpicking

Inconsistent code spacing, as well as other things that make my code linter itch have been fixed.

* add test data from Mehdi

* Clearer wording

* Add data, thank you Gabriel Tremblay

* Update test-data (fulldecent#27)

* Update TEST-DATA.tsv

Add new record

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Update README.md

* Added my own testing (fulldecent#29)

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* New song format

Changed over the song parser and accompanying code to be inline with the new, as suggested in issue fulldecent#28.

* Updated contributor information

* Improved link styling

* Improved formatting

* removed unused and unrelated  CSS classes

* removed more unused CSS

* removed red outline around text box

* improved link styling

* Added a delay function and fixed time being *1000.

There was a bug before, that caused the window to freeze up (seemingly forever). This was due to the fact that the times in milliseconds were being treated as time in seconds. This has been fixed with a *.0001 function.

Also, a block of code for the "delay" function has been added. Delays between same notes in the included demo song have also been added.

* fixed description meta

* created var for window log

* moved var definition

* Preperations for web using a worker

* Improvements to html, css, and js (fulldecent#30)

* Improved formatting

* removed unused and unrelated  CSS classes

* removed more unused CSS

* removed red outline around text box

* improved link styling

* Added a delay function and fixed time being *1000.

There was a bug before, that caused the window to freeze up (seemingly forever). This was due to the fact that the times in milliseconds were being treated as time in seconds. This has been fixed with a *.0001 function.

Also, a block of code for the "delay" function has been added. Delays between same notes in the included demo song have also been added.

* fixed description meta

* created var for window log

* Implemented Web Workers

Functionality is now taken care of by Web Workers. The advantages of this is that the page will no longer freeze/lock up when the script is working.
This also means that the page status can now update in realtime. (Before, it only updated after the script finished running.) Because it possible for buttons to be clicked during operation, it is now possible to stop script mid-execution.
Song recursion should also be possible now but, has not been implemented.

* Added comments to source code

* add local file warning

* Add data from John Sampson (fulldecent#32)

* Update TEST-DATA.tsv

* Update TEST-DATA.tsv

* Add JS instruction, fixes fulldecent#33
@fulldecent

This comment has been minimized.

Owner

fulldecent commented Nov 12, 2017

Just added this documentation to the tunes/ folder and added two sample tunes.

87dbedb
797e8ec

@fulldecent

This comment has been minimized.

Owner

fulldecent commented Nov 12, 2017

Tune format now working for c implementation with 0090934

@thegoldenprawn

This comment has been minimized.

thegoldenprawn commented Jan 17, 2018

I am new to this project and wanting to help, has any scripts been written to convert the sound to this format.

@fulldecent

This comment has been minimized.

Owner

fulldecent commented Jan 18, 2018

None yet. I have manually converted some other files into .tune format. But if you could write something took text and turned it a tune as morse code, that would be pretty cool.

If you can do it as a web page then we could host it at https://fulldecent.github.io/system-bus-radio/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment