sky-music / sky-python-music-sheet-maker

Make visual music sheets for thatskygame (graphical representations of the Sky keyboard)
MIT License
29 stars 10 forks source link

Stuck with implementing 'create song' for bot #102

Closed t1-tracey closed 4 years ago

t1-tracey commented 4 years ago

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

t1-tracey commented 4 years ago

I tried to separate all the print and input statements in the original main.py (currently replaced with ask and output in Responder). This is because the bot uses await commands to send and ask messages.

But I'm not sure that the way I organised Responder is working. In the current work, I don't think I can override ask and output to be used like this...

(I've asked Alex to give access to jmmelko too to That-Sky-Bot btw. Strawb, if you'd like to push to That-Sky-Bot, just let me know and I'll ask Alex too)

jmmelko commented 4 years ago

I definitely can create the Renderer again, if needed. Or Strawb can do it if he wants to.

I don’t know much about bots, but I know that they are mostly conversational bots, so an ask-wait-and-answer logic seems fine.

Alex is nice but he talks in a very abstract (conceptual) manner. So I suppose we have to take a look at that-Sky-bot to get a proper example.

I’ll tell you what I find.

jmmelko commented 4 years ago

Ok, after a quick look, I have 3 comments:

jmmelko commented 4 years ago

await message.edit(

3 questions remain unanswered:

1/ should we write “bot code” directly in our functions, or is there a way to wrap existing code? I hope there is.

2/ how do we wait for user input? I mean, can we just wait for the next text they type, or do we have to create a trigger ?and then the trigger would be very loose, meaning “if any text is typed”. (Maybe the answer is the same as for 3/)

3/ what do we do with the listening functions? @commands.Cog.listener()

They seem to be linked to trigger objects, defined in Utils.utils. Should we be able to use those or will Alex do it?

jmmelko commented 4 years ago

There seems to be a trigger list, a dictionary object with the following structure: `trigger = responder.trigger

chance = responder.chance / 10000 # chance is 0-10,000. make it look more like a percentage

self.triggers[guild.id][trigger] = { 'match_list': match_list, 'response': response, 'flags': flags, 'chance': chance, 'responsechannelid': responder.responsechannelid, 'listenchannelid': responder.listenchannelid } `

As for the trigger object, it seems to be nothing more than a list of words:

trigger = ''.join(words)

t1-tracey commented 4 years ago

Oh I will just add, the only file we need to edit is Music.py in the Cogs folder of That-Sky-Bot.

Everything from our program will be there and can be imported, here is what it first looked like: https://github.com/e-a-h/That-Sky-Bot/commit/50233dc32811b096594533662428a326518606e1#diff-72f124c5161a0c6cab39520863827eea

jmmelko commented 4 years ago

Oh I will just add, the only file we need to edit is Music.py in the Cogs folder of That-Sky-Bot.

Everything from our program will be there and can be imported, here is what it first looked like: e-a-h/That-Sky-Bot@50233dc#diff-72f124c5161a0c6cab39520863827eea

Ok, but clearly a drawing (logical diagram) from Alex would help, showing the interactions with the rest of the bot, or at least a specification sheet telling:

Would be more efficient than looking into Krill.py and try to infer the rules from there. I’ll try my best though.

t1-tracey commented 4 years ago

Yeah that would be helpful ;-;

There is just the discord.py documentation https://discordpy.readthedocs.io/en/latest/

jmmelko commented 4 years ago

Could be useful:

Waiting for a user reply:

@client.event
async def on_message(message):
if message.content.startswith('$greet'):
        channel = message.channel
        await channel.send('Say hello!')
        def check(m):
            return m.content == 'hello' and m.channel == channel

msg = await client.wait_for('message', check=check)
        await channel.send('Hello {.author}!'.format(msg))
jmmelko commented 4 years ago

What is a model? Does he mean that:

https://discordpy.readthedocs.io/en/latest/api.html#discord-models

I don’t think so since those classes are read-only. I have sent him a message to ask him what he meant.

IchigoDaifuku commented 4 years ago

should we write “bot code” directly in our functions, or is there a way to wrap existing code?

What do you mean bot code? I think there is a way to wrap functions - would using decorators or functools.wraps work?

Strawb, if you'd like to push to That-Sky-Bot, just let me know and I'll ask Alex too)

Thanks! I won't be able to push anything any time soon though.

I definitely can create the Renderer again, if needed. Or Strawb can do it if he wants to.

I definitely want to rewrite the renderer but I currently don't have Python 3, PIL and mido installed, so any code I write and push would be untested.

jmmelko commented 4 years ago

What do you mean bot code? I think there is a way to wrap functions - would using decorators or functools.wraps work?

Actually I mean anything that needs the modules discordpy, Utils, and aynscio. My fear is having to use channel.send(), decorators, asyncio, etc directly inside the core functions of the program. Especially I’d like to keep Instruments, Notes, Songs, Parsers, noteparsers untouched.

I definitely want to rewrite the renderer but I currently don't have Python 3, PIL and mido installed, so any code I write and push would be untested.

Ok, so let’s wait 2.5 weeks first ;-). Or rather 2.35.

In any case, before doing that, we’ll have to wait for the dev branch to be pulled to the beta one.

jmmelko commented 4 years ago

Okaaaay.... after talking with Alex (see here) it seems that it won’t be possible to go further if we don’t take the code to a more abstract level. It’s just that “the bot” and the music-maker program don’t talk the same language, so they’ll have to cross at midpoint. I could say that Alex and I don’t speak the same language, that would also apply 👽

Well, actually, we could, by using discordpy functions, and implementing dumb, linear, ask-and-wait interaction between the bot and the player, but I have the feeling that Alex would be somewhat reticent to push that.

Tracey has done a lot with putting main.py into the Responder object, but it was only the first step it seems. I know she has some ideas for the rest.

In any case, I think that everything peripheral to the Song, such as: title, composer, key, notation, is susceptible to become an object, as well as methods such as ask_song_title()

I remember the time when Tracy used her pencil and notebook and came out with this great idea of base 7 and completely revamped the parser. I hope she will succeed in doing that again 🤩

EDIT: I think pencils and notebooks are best suited to do one’s homework 😏

In any case, I’m open for discussion on the new structure; we should open a new issue for this.

The only thing that remains obscure is the partition between our work and Alex’s. I suspect that it will be 90/10% 😱