Recent submissions

Comment · 2 years ago
Comment · 2 years ago
The limitation comes from the underlying model, which can only generate up to 30s, more info about that here: https://huggingface.co/docs/transformers/en/model_doc/musicg...

There's a model version that is able to generate music conditioned not only on natural language prompts, but also on other pieces of music, so it's possible to generate chunks of 10s where each chunk is generated based on the previous one.

The challenge with that model is that it's hard to export it in ONNX format so that it can be run outside of a machine learning framework in Python.

Comment · 2 years ago
Hi HN! Author here, I wanted to show off the latest side hustle that I've been cooking for the past few months.

This is a terminal application that runs the latest AI models for music generation locally, using the CPU or GPU of the device, and without the need of heavy dependencies like Python or machine learning frameworks. It works on Linux, Mac and Windows seamlessly, with a binary size of just ~30 Mb for the non-GPU versions.

The app works like this:

- It accepts a natural language prompt from the user

- Generates a music sample conditioned by the prompt

- Encodes the generated sample into .wav format and plays it on the device

Additionally, it ships a UI that allows interacting with the AI models in a chat-like web application, storing chat history and generated music on the device.

The vision of the project is that it can eventually generate infinite music streams in real time, for example, an infinite stream of always new LoFi songs for listening while coding, but not quite there yet...

Hope you like it!

Comment · 2 years ago
That's taken into account while rendering the graph. The attraction force between two nodes is inversely proportional to the number of edges a node has.

If a node is depended upon a lot, all the resulting edges induce weaker forces to adjacent nodes, so this accounts for the fact that some files will be depended upon a lot, and that's fine.

There's also the option to just exclude that kind of files from the analysis with the --exclude flag. I've found that to be useful for massive auto-generated files.

Comment · 2 years ago
Java is one of the top candidates for being implemented next actually
Comment · 2 years ago
It's a similar idea, but I often find myself very lost on 2d drawings if the codebase reaches a certain size
Comment · 2 years ago
definitely, that and Java sounds like two very good candidates.
Comment · 2 years ago
Yeah, unfortunately custom imports are only implemented if declared in the tsconfig.json as path overrides, but definitely something that should be looked at
Comment · 2 years ago
Thanks for the feedback y'all, I'll take this into account going forward
Comment · 2 years ago
Yeah, that's an option, it's not a perfect fit with the philosophy of the project, but definitely possible. But ideally it would just work between files in a package.
Comment · 2 years ago
Right now it only supports JavaScript, TypeScript, Python and Rust, but it's designed to be extended with any other language. Each language implementation is just some hundreds of lines of code, so it's "easy" to add new ones, I think C/C++ and Java/Kotlin are good candidates that would be very easy to implement.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton