bclindner/cnmn

Elixir Discord bot.

Grading Web Tools

This repository contains an HTML/CSS validator frontend and a plagiarism checker service developed to help streamline my work grading labs as a tutor at Georgia Southern. These services are no longer in use. and I cannot guarantee that they work.

It used the W3C HTML validator API, and CSSHint on the backend.

cnmn's Issues

Organization: Organize features by functionality

Still not sure how this should look yet

Skip music tracks in the queue by index

c-music skip <int> should be able to skip a track at an arbitrary position in the queue, for "surgically" removing tracks

Alpine build

An Alpine build would be excellent for this system as it would shave 600+MB and speed up build time tremendously compared to the existing Debian image. However, Alpine imagemagick does not have support for liblqr which prevents use of liquid rescale, which is IMO essential as the bot this replaced was primarily used for image crunching.

Cleaner handling of music metadata retrieval

Current implementation functionally pulls the track info twice (once at queue time, the other at runtime). Chances are nonzero for a YouTube ratelimit if requests happen too often. Also, this introduces ~1-2 extra seconds of latency that should be unnecessary

YouTube API is the obvious choice but I think we could also get away with streaming the URLs returned by the info JSON directly with a little finagling

Command aliasing

c-music play is too long, being able to define a regular way to do an alias for certain common commands, i.e. c-mp for this one, would be nice

Viewing queue should not be restricted to voice channel members

It's cool to peek at the queue when you can't be in the channel - didn't mean to do have it do this so I consider it a bug

CNMN.Image.crunch efficiency concerns

Current image crunch pipeline is decent, but reliance on Mogrify (& the underlying ImageMagick CLI) seriously limits efficiency. Another transformation method would be preferred.

See Wikipedia article on seam carving - this is a well-known algorithm, and there are several ways I can think of to go about this:

• Direct use of ImageMagick API via NIF
• Direct use of liblqr via NIF
  • Ideally it would be nice to put out a bounty or donate code to remove glibc as this is the only blocker for #8
• Write the seam carving algorithm directly into Elixir/Erlang (probably via something GPU-able like axon or nx)
  • instructions for implementation (albeit link rotted) that would provide a basis for this
  • This looks mathy but potentially very doable for Elixir

Basically any of this work should probably go in its own separately published Hex library unless it is extremely brief to write

Add test step to Containerfile

A working container should probably pass mix test before being put into a runtime configuration.

Only caveat I see here is that this may require the container dependencies to be installed during tests, which will incur more time for uncached builds.

Use application commands

Potentially something to look into, but not absolutely a requirement - application commands would provide a cleaner syntax for the bot as a whole, but would require more general code + structure. A hybrid approach is technically possibly but full conversion seems like the move here if this ends up being the future of the bot

Limit queue when listing queue items

Discord will definitely deny the embed if the queue printed is too long; a static number like 10, 20, 50 tracks max is best here. Depends on Discord's limits.

Listing should also always show queue length if truncated.

More dynamic runtime configuration

Ideally use of a YAML/TOML/JSON file within the config construct would be a lot nicer for configuring on a per-deployment basis; Elixir's Config structure is designed around the ability to map settings in this way, so it shouldn't be too difficult. This would make deployment a lot cleaner as you could point the bot to a config file rather than pass in envs or a .env file directly

I will say I'm leaning towards TOML: its syntax is cleanest and it could easily represent image transformers

More image transformers

Hex has libraries like image that may provide more interesting transformers to add to the bot

CNMN.Music.Manager: tests

This system is probably very brittle and its GenServer backend calls are completely removed from the Nostrum lib so it should be a good candidate for learning ExTest's ins+outs