Standardize tune description format

[fulldecent]

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 (\n, but \r\n should not cause an error when reading file)
4. File extension is .tune
5. 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:

• [x] 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
  • [x] Using _mm_stream_si128
  • [ ] Using counter and threads
  • [x] In Javascript
• [x] Update run instructions so users know to supply the song file

Related: #1

[rocketinventor]

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

[fulldecent]

@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]

@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]

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

[rocketinventor]

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

[rocketinventor]

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

[fulldecent]

@rocketinventor Thank you, one check for the good guys

[fulldecent]

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

87dbedb9bf0f4c79389300d6a664c7e94d50b30e 797e8ec77397d52b261d205755da6e3f8ca40b65

[fulldecent]

Tune format now working for c implementation with 0090934aa5c36717b4f5b08d1f2e6e03af4b88ec

[thegoldenprawn]

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

[fulldecent]

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/

[YoshiRulz]

It should be noted that this format is distinct from GRUB_INIT_TUNE.

edit: Adding to the below comment: pitch and duration are in the reverse order as well.

[fulldecent]

This is equivalent to the GRUB_INIT_TUNE when using a TEMPO of 60,000 (bpm)