bytesnake / hex Goto Github PK

The music coding supports only stereo for now. To change this we have to improve the implementation in music-container a lot and use Spherical Harmonic approximation. For very basic Mode-Matching support we could:

• use GLS to calculate SH (e.g.)
• use pseudo inverse to calculate the decoding matrix

We can do better at the file upload. For now each file or youtube upload is seperated, therefore it is painful to do multiple uploads simultanously. If a local instance for each user handles each upload, then the overview would be greatly improved.
On the backend side, I can magine something like this: First the client send the the server a request to upload a certain youtube url. The server will start a process in the background and saves an instance associated with the message key in the connection state. Then the client can asks periodically for progress of any upload. This could trigger multiple conversion steps.
On the frontend side, this redesign could improve the handling:

The add button would open an overlay, where the source can be selected. Perhaps we could use event more sources, like soundcloud, but this must follow later on.

It would be very useful to create dynamic playlists based on some search query. They would be recreated every day or so and appear just as a normal playlist. For example a playlist with the 20 most liked songs can be handy.

In order to change the playlist connected to a token, the frontend has to show the connected Zyklop. We could add an icon to the header and show whether the Zyklop is connected or not. The user can click on the icon and change the connected playlist.

The buffering mechanism in the frontend is loading the whole song into a buffer. This is suboptimal, especially because this buffer gets very large for long songs (or podcasts). A better mechanism would use a ringbuffer and refilling it every time we are jumping in the song (which is happening rarely to say at least)

The download is for now totally missing. You should be able to select a file format and then download multiple songs in an archive. These have to carry the information of the database in the tag or filename. Perhaps a special syntax can be used to describe the filename, like "{title} - {artist}". This will be quite complex to implement.

The protocol is at the moment implemented in the server, frontend and stream-client in three seperate files. To simplify this we could just move all the protocol stuff into its own crate and write a wrapper for webassembly for it. This would have the advantage to:

• simplify the code in general, because we have only a single implementation
• switch to binary encoding instead of JSON format, therefore saves a ton of transmission space

For this we need to:

1. Rewrite the server/proto.rs code to work as server and client
2. Switch to binary protocol in websocket and use binary encoding with bincode
3. Write a wrapper for the library in webassembly and use it in the frontend

Use the spellfix module in sqlite to compute the Levensthein distance between search query and database entries. https://stackoverflow.com/questions/49779281/string-similarity-with-python-sqlite-levenshtein-distance-edit-distance

The playlist overview of each track should allow you to delete a track from a playlist.

For now the frontend supports only english as a language. We should really internationalise it .. https://github.com/download/preact-i18nline

For now each song has to be edited seperately, without any ability to delete, modify or bundle selections. This required no new implementation on the backend side, but some effort in the frontend. The selected songs must be highlighted and then a new bar, which fits somehow nicely in the existing design, should show further options, like delete or download or create a new playlist from it.

Every song is played by a group of people with instruments. Basic support for them is already builtin, but it can be improved by far. We could add a tab besides "playlist" to add new people to the song (with support of icons).

From an implementation point of view, what do they actually do? Looks like they act as some kind of struct to refer to albums. But I'm not sure.

Hex should allow changing the image of a playlist. This could use the same binary upload as the file upload for a song.

This is a nice have, but (at least for me) not really useful. The sound volume can already be controlled in the system and you don't need a seperate control element. Perhaps if some songs are not equal equalised.

Because of the slow SD card in the RaspberryPi the conversion and download of a track is very slow. At the moment we need half a minute for a 3min track. Perhaps there is a way to speed this up, especially because we're buffering everything as files.

git clone https://github.com/bytesnake/hex.git
cd hex/server
cargo build
# error: failed to read `~/code/hex/server/protocol/Cargo.toml`

Not sure why it is looking for protocol/Cargo.toml

Would hex be able to read and play mp3 files or aac files?

I have several ideas of the startpage. It could carry for example:

• a short list of most-loved songs
• a heatmap with number of listen per day
• number of total songs/playlists
• chart with uploads vs time

This is kind of a nice tool, but not really necessary.

At the moment each playlist has to be created by hand. We could pick some low hanging fruit by allowing the user to create a playlist from the uploaded files and the songs in the queue. In both cases a button could just add all songs to a new playlist.
For example the user uploads a bunch of youtube songs from a playlist and they are listed in the upload menu. Then the button would create a new playlist, add them all to the new playlist and open it in the fronted. Then the title and description can be edited.

The music-container is equalising every song to a full 16bit range for now. This is working for now, but problematic for quiet songs with some peaks. We could introduce a replay gain to adjust the loudness. This perceived loudness is dependent on the number of loudspeaker, therefore the reproduction step and should be applied directly after the decoding step.

The nightly-worker should remove duplicates by a heuristic. We could for example compare the title/album and fingerprint to find duplicates.

The server should be not available in public at the moment because there is no kind of encryption and login mechanism. Therefore reasonable improvements would be to:

• implement login mechanism in the webserver
• enable websocket encryption

The nightly-worker bot has to be rewritten in order to use transitions instead of actions. At the start page we could

• show number of transition per day as a heatmap
• number of songs (as before)

The history could give an overview by

• showing a graph of all transitions

The sidebar is not yet updated when an extern source creates a new playlist, this should be done. For example if a song is added to a new playlist, which did not exist, then a new playlist with just this song is created, but the page has to be reloaded to show the playlist in the sidebar.

The real reason for all this effort is still missing. It will be the central music hub and allows to store playlists in an extern ridge.