dragsbruh

shipping this, am tired. updated the delay logic a bit, should be all good

completed the openai api wrapper and wrote a UI for the demo, chunking was a pain

now looking at the demo myself people not knowing the context of what grall is will probably think this is slop lol

oh well, please read the devlogs before voting :3

this is absolutely silly, worked on a sequential chunked training system but i got clapped at the merging part so hard. it was fast and produced correct models but didnt really run. wasted 6 hours and oh it didnt get logged cool

the unix socket api is done

started working on chunked training because that will massively boost the training speeds i imagine. im working on training chunks sequentially atm but every step there is always support for making it run in parallel.

i almost completed the sequential chunked training i just need to check for half-serialized files and then k-way merge all trained model chunks then ill proceed with the parallel training

and then i gotta work on the openai api and then a demo ui

working on the unix socket api rn

im not doing the training optimizations rn because i plan to change a few things about how it fundamentally works

so far so good, worked on an stdio api but it turned out shitty because of the throughput i needed.

this also means i can use the same grall process across multiple dependent processes and each connection uses a different thread, therefore performance!!!

after some small optimizations we hit our first 5MB/sec. training is very slow so ill optimize that, ive figured that array insertions are causing the slowdown so ill move to a different data structure for training. im glad i completely separated the training and runner chains from the beginning.

currently microoptimizing the hell out of a string compare function for a very specific case but will generalize soon. hits 1MB/sec otherwise but i want it to go faster. shoutout to a fine maiden named pbl for a c implementation that uses linked list and is blazingly fast, although its word-word not byte-byte BUT I WANT IT TO GO FASTER RAHHHH

https://github.com/bitpbl/ferrite

completed the base markov runtime, working on features like ending styles and yaml serializations (already completed the file serialization)

still need to work on chunking the input text data across multiple models and k-way merge them

so far, 222mb textual data after training, uses 15MB on disk and ~~150 MB ram during runtime (must fix!!) and generates text at ~~600KB/sec

markov chains are silly

Made the scanner slightly more robust and did some finishing touches

Hosted a public instance on nest with >100 tracks for demo

Cool

Almost finished up gng!!!

1. artist/album/track pages complete
2. queue system and queue page

playlists, scrobbling, history are still very missing but the current priority is now

1. search feature
2. clean up player controls
3. ship demo

got a lot of bug fixing to do after i went changing how audio works

but now we got (atleast a reference implementation) for

• playback queues
• fancy home page
• erm smht

also the db queries are a bit messy but it works so ill fix it later

completed pagination, it was kinda weird

switched completely to raw sql on the database rewrite and implemented most of the earlier stuff just need to implement the api and i can continue working on the project normally

yeeyeee!!!!

the new backend has very nice code structure albeit the inline sqls are getting messy
found out about this extension that highlights and lints them, really cool
also found out about json agg so will use that in most places

i also need to cache api requests so that too

meh

not much visible update since its a backend rewrite so heres a picture of the todo

the backend is getting a little weird because i couldnt get advanced querying with sqlc

you could say that it could not keep up with frontend (lol)

im rewriting, this time ill keep track of what the api needs to be exactly and do it gng!!!

also we got

the frontend is inprogress and i quite like it! as i said im using svelte and svelte5-router

im so deep into typecasting in typescript just to make the library page a bit more dynamic

still need a lot more work to make it functional!

rewrote the indexer with a much cleaner codebase and now working on the actual music server gng, using svelte for the frontend as all good music servers should!

also plaintext passwords because im adding subsonic compatibility :sob:

idk what picture to upload so heres a piece of the code in the best theme ever (Orangey Darker 1)

Going tight, we got 5.5k songs indexed in 2 minutes from scratch with metadata scaling and apis for both administrators to trigger scans and manage users (via http over unix or tcp sockets) and a basic api to manage tracks

proud to say that we do not still use spotify or musicbrainz, i do not intend to use anything other than lastfm to get similar artists

cool

i should've probably not used Spotify and have had the plugin system provide its own metadata

a bit more hassle on the plugins' side but would've definitely avoided this issue with broken metadata.

oh well i guess i have to rewrite half of the code now :sob:

but until now we got
1. Plugins injected at compile time
2. Plugins can provide and receive currently playing tracks
3. Spotify metadata (Will remove this and make a helper function to get it from Spotify if needed)
4. Tracks/albums/artists stored in database (postgres + sqlc btw)

still a lot of work to do, havent even started with the UI yet