As discussed for #102, and directly with Alex here:

To make music-maker / bot interaction easier, it would be desirable to create a new class. The underlying reason is that a bot is conversational, i.e. it asks and answers questions in no definite order, while the music-maker script is a linear “old-fashioned” program with prompts (input() & print().

The code is being pushed in the dev branch.

TODOs:

• [x] finish QueryOpen
• [x] Think about how the asking locutor will “know” that it has been talked back
• [x] change the list of valid locutors from test strings to something else (objects? Class names?)
• [x] implement my secret hash-like feature and the corresponding functions in QueryMemory
• [x] try using the objects inside Communicator and bot to see how it works
• [x] add support for the Information class in def store() method of QueryMemory
• [x] add sorting by time stamp in QueryMemory
• [x] IMPORTANT: finish implementing the prerequisites property. In particular, for each Query check that the dependencies have been answered to. Currently the prerequisites is only used to make a topological sort.
• [x] let Tracey digest the code, test it with test_comm.py, give directions, make corrections, beautify it
• [x] enable the use of UIDs to define prerequisites (dependencies)? Problem: the UID is only created once the Query has been sent (or manually).

I have some suggestions regarding the new music feature in the bot.

1. Link the sky-music.github.io website once an user finished with the composition of the song, saying something like "for more music sheets visit the website ---", it's a library of songs in the end, always good to publicize it.

2. Black mode in the sheets? Not really that important but it could be a nice touch.

3. Give option to also export the song in the sky music app/sky studio format based on the bpm of the song, if not given, use 220

The format is this one:

[{
name:" ",
bpm:" ",
isComposed: true,
bitsPerPage: 16,
pitchLevel: 0,
songNotes[
      {
             key:"Key0", //Key goes from top left to bottom right 
             time:1000 //Timestamp since the beginning of the song
      }
}]

It's an array because it supports multiple song import/export, each note time is calculated with the bpm , each "cell" increases the timestamp by 60000/bpm, empty cells just increase the timestamp and don't add any other notes. Notes pressed together have the same timestamp.

This is a JSON but can be given both .JSON or .txt file extension.

Any attribute can be added to the format like the author name and other information, but the name of the song must be the first attribute. Jmmelko and Tracey already are familiar to this format, I made a script to convert the html songs to this format on the sky-music.github.io website.

• [x] address TODOs listed in #104

• [x] rewrite the methods from responder.py into communicator.py

• [x] rewrite the instructions. Maybe this should be done by parser??

• [x] write the music sheet maker's questions as queries, in the create_queries() method of communicator.py

• [x] make sure Parser works with queries

• [x] determine if the use of asyncio is mandatory for the command line version to work

• [x] In music sheet maker, decide how to return the results of queries from one method to the overlapping one (the one which called this method), by returning Reply objects or directly doing Query.reply_to

• [x] check if the query_stock structure is adequate

• [x] address TODOs left in the code as comments

about the name 'Responder' or 'Communicator', any is fine. The problem is that Responder is not centred on communicating through Query messages.

The communicator/responder is what's between Parser and the outside. Right now, I feel that the current Responder class is still way too structured for only the command line — all of the Responder.ask_to_select_mode() ask_song_key def ask_song_headers etc. methods need to be written as each queries now

For most people, absolute octave numbers mean nothing. If the song is within a single octave, they simply give note names (eg C, B, G) and that's fine because our code assumes the octave is 4.

But if the songs spans several octaves, some people will input the song starting from octave 1. This gives errors because we assume that Sky's piano starts at C4.

We have three options from here, I will list them by order of my preference:

1. Change 'note_shift' back to 'octave_shift', use 'octave_shift' before parsing the song to interpret user input
2. use note_shift before parsing the song. Then we do octave_shift = int(note_shift/n), and note_shift = note_shift - octave_shift*n, where n = 12 or 7, depending on which point of view we choose (real-world's chromatic or Sky's heptatonic system)
3. Try to parse the song with different octave_shift and chooses the one which gives less errors

My preferences goes to solution no1 because now that we handle all the musical keys available in Sky, we don't need to transpose songs within Sky's system (the initial use of note_shift was to transpose songs to work with C), while transposition within the general chromatic scale will be handled elsewhere (#32)

What do you think Tracey?

It was so fun and easy to add midi output!

At the present time it does not support other keys than C, but I am confident that after we validate the western branch we can do it.

Please fell free to test it.

I think it is safe to merge it in the beta and/or the master branch, because in case of a bug we can still disable the midi output, or write a caution "this is a beta feature" message. But only after we decide what to do with the western_branch

• [x] test it (-> Tracey)
• [x] decide if the “broken chord” note is alright (I have chosen a short high pitched note) (-> Tracey)
• [x] add support for other keys than C (-> mimizan)
• [x] add support for non-English keys
• [x] see how to change tempo, do we add a constant in main?
• [x] decide if we stick to piano or let the user choose its instrument among a list
• [x] in the documentation, tell that midi rendering is only intended for testing the melody, not for simulating the musical rendering in Sky, especially because pauses are always of the same duration so that the rhythm is not always right (->Tracey) https://sky.bloomexperiment.com/t/summary-of-output-modes/450?u=cactusflower

As suggested by Strawb:

The code in parsers.py is very long.

The reason for that is that it handles many different input formats (aka song notations), and uses long hard coded variables, such as dictionaries, regular expressions, etc.

I think we could easily split the NoteParsers into different files:

• SkyKeyboardNoteParser
• SkyNoteParser
• EnglishNoteParser
• EnglishChordsNoteParser
• DoremiNoteParser
• JianpuNoteParser

I suppose we would also have to put the generic NoteParser in a separate file.

I can do it but I need confirmation from our Code Mistress.

This is our 100th issue!

Happy birthday everyone 🥳🎂

How to write to a file without needing to write it to disk

buffer = StringIO()
# use it as any other file here to write to it
buffer.seek(0) # reset the reader to the beginning
await channel.send(file=discord.File(buffer, "filename"))

Current work: https://github.com/e-a-h/That-Sky-Bot/blob/dev-music/cogs/Music.py

My earlier test (copied code from the old main.py): https://github.com/t1-tracey/That-Sky-Bot/blob/dev-music/cogs/Music.py

Bugs channel example: https://github.com/e-a-h/That-Sky-Bot/blob/dev-music/cogs/Bugs.py

I don't know how to implement asking the questions. Alex recommended to make each question a model, (which is in line with what Strawb suggested about making Parser, Song and Renderer separate). that will mean more reorganising.

I keep feeling too overwhelmed and incompetent on my own, about what to prioritise next, I need help

note_parser = EnglishNoteParser()
print(note_parser.calculate_coordinate_for_note('G', 'Ab', note_shift=0))

I was doing some testing with Let it go and this case fails, I will look into it

Besides the obvious, I have introduced a few enhancements into the master and beta branches, that are in NOT the western branch. Pushing them from the master to the western_scale branch would be dangereous, I think, since western is ahead master on several other aspects. Even though GitHub is smart, I fear that these improvements may get lost after we merge western_scale into the master. So I will list them below so we can check that they are still in the master after the merging:

• [x] in main.css: font-size: 1.0em
• [x] new file: css/warning.txt
• [x] new file: elements/readme_elements.txt
• [x] in instruments.py: optional PIL import with definition of no_PIL_module variable
• [x] in main.py : compact writing of for ask_for_mode()
• [x] in main.py: new version of load_file(), including a use of re and only one return parameter
• [x] in main.py: compact value assignement of the ENABLED_MODES constant
• [x] in main.py: compact writing of allowed song notations (for mode in InputModes...)
• [x] in main.py: use of the new method read_lines()
• [x] in notes.py: optional PIL import
• [x] in songs.py: optional PIL import and "if no_PIL_module == False:" statement in init() and "if no_PIL_module == True" statement in write_png function
• [x] new file python/tools/readme_tools.txt

• [x] Test the WesternNoteParser — address any errors, make sure it works with some test songs, make sure the other notations (Jianpu, Sky etc.) are still working

• [x] Create test songs for all input modes

• [x] Test ascii output (and sky-western conversion)

• [x] Replace find_key with the new find_western_key.

• [x] In main.py, for finding keys, maybe could we implement allowing the user to choose from the top 3 possible keys if there is no perfect match? (Like with the modes)

• [x] Test what happens when several modes are detected

• [x] Remove (or comment) Jianpu2Western functions

• [x] Avoid using the old position_maps

• [x] rewrite detect_input_type

• [x] cleanup is welcome if you find anything

• [x] check that the coordinate of the western note is in the range of the Sky piano (0,0) to (2,4) before returning it, otherwise raise an error, so that a broken harp will be produced

• [x] Specifically test input_mode and music recognition

• [x] specifically test with dirty input (typos, missing octaves)

As for Jianpu and do re mi, I wasn't sure if they needed this NoteParser. But I just realised that maybe it could help to generate the coordinates rather than the long dictionaries currently used. I haven’t thought through this yet though.

• [x] finish implementation of Jianpu parsing

• [x] specifically test Jianpu and doremi parsing

• [x] check if the old trick to set pauses (breaks) to the (-1,-1) position is still used and/or that pauses are parsed correctly, including in find_keys and detect_input_type methods

• [x] before merging the western branch into the beta branch, archive the master in the stable

Any of these tasks are ok hehe

When a music score is split into two layers, one for each hand :

• merge the notes of both layers into a unique layer
• Use a different color for each hand

To do that: Use highlighted frame =0 for the first layer, and highlighted frame =-1 for the second one. Because using highlighted frame >0 would confuse the notes with quavers

Then assign the color of frame = max to -1, so that the colors for frame 0 and -1 are very different.

I think it is possible to make the song_creation method a pure list of calls to self.methods, using only the recipient as the input parameter. To do, this 2 steps:

• [ ] Create a retrieve_song_notes methods, which searches for the latest query about notes and get the notes out of it. Tricky part: handle files.
• [ ] Make create_song a loop iterating over a dictionary of self.methods, calling them one by one, with recipient as the only parameter
• [ ] Add an n integer or 'string' input parameter in create_song so we can skip to the call of method of the nth method or referenced by 'string'

Then, the code in the cog would become:

for i in range(len(maker.continue_song)):
    q = maker.continue_song(recipient=player, method=i)
    execute(q)

We will list here ideas of new features. Relative priorities will be decided according to player’s demands, if the code makes its way to Discord...

• under-the-hood changes:
  • [x] a new class for handling bot/code interaction (#104). I am not talking about player/bot interaction, which is something else. [suggested by @e-a-h & @t1-tracey ]
  • [x] make chord_sky_grid a separate class (#75) [suggested by @t1-tracey]
  • [x] (maybe) putting the Renderer outside Song (#99)
  • [ ] wrap the time-consuming functions in a function and offload it to another thread using asyncio, to avoid clogging the bot [suggested by @AEnterprise].

.

• Front end features:
  • [x] dark mode (thank you Specy)
  • [x] link to generate a song on Sky-music.github.io (just have to test it and pull it to the Music Cog of thatSkyBot)
  • [ ] add measure dividers (parse |, add vertical line drawing)
  • [x] database storage of songs, with the ability to search [suggested by @e-a-h] => this is implemented in the website at [email protected]
  • [x] two-hands, or two-instruments [suggested by @IchigoDaifuku aka Strawb]
  • [ ] better handling of lyrics (how?)
  • [ ] better tempo handling
  • [ ] key transposition (aka transposition in the chromatic scale) [suggested by @jmmelko and @e-a-h]