gabimtme

The model has some limitations, for example: - it can only generate 30 seconds of audio - there's performance differences between music genres

You can read more about the limitations here https://huggingface.co/facebook/musicgen-small

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.

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!

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.

Java is one of the top candidates for being implemented next actually

It's a similar idea, but I often find myself very lost on 2d drawings if the codebase reaches a certain size

definitely, that and Java sounds like two very good candidates.

Yeah, unfortunately custom imports are only implemented if declared in the tsconfig.json as path overrides, but definitely something that should be looked at

Thanks for the feedback y'all, I'll take this into account going forward

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.

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.

The visualization is actually inspired by Gource, but taken to the 3D space, it's a really cool project.

Golang is very challenging to implement, because dependencies between files inside a package are not explicitly declared, you can just use any function from any file without importing it as long as they both belong into the same package, so supporting Golang would probably require spawning an LSP and resolving symbols.

The reason for implementing dep-tree in Go was because things were going to get algorithmic af, and better to choose a language as simple as possible, knowing that it also needed to be performant.

Yeah, the web app is quite limited, it doesn't accept any kind of configuration. Implementing the Python absolute path resolution mechanism was actually quite challenging, as there is just too many ways you can handle absolute imports.

I've seen people using tricks like the `sys.path.extend(["src"])` in the main file for being able to place source code into an `src` folder, but unfortunately, dep-tree is not able to take that into account.

That's because dep-tree doesn't know it needs to resolve names starting from `src/`, as your imports have that piece of information trimmed. You can solve this by setting the PYTHONPATH env variable like this:

export PYTHONPATH=src

That's really interesting!

And even with discipline, sometimes introducing tech debt in order to ship something fast is actually something desirable at the short term, specially in the startup world, so I don't think that anybody with deadlines is completely free from twisting things up.

Well, that's one of the drawbacks of the smart color auto generation... it's not that smart.

That's definitely is an improvement point, I have just calibrated things looking at my screen, which might have a high saturation/brightness setting.

Thanks for the feedback!

Nah, nothing like that, "entropy" in the colloquial meaning of level of disorder, it has proven to be a useful word for people to understand what it is about, even though it's strictly incorrect.

The portion of the code in charge of rendering lives inside the `internal/entropy` (https://github.com/gabotechs/dep-tree/tree/main/internal/ent...).

Force-directed is an algorithm for displaying graphs in a 2d or 3d space, which simulates attraction/repulsion based on the dependencies between the nodes, the wikipedia page explains it really well https://en.wikipedia.org/wiki/Force-directed_graph_drawing

> Love it, I think dependency trees are super underused data for static analysis.

Definitely, specially for evaluating "the big picture" of a codebase

> It sounds like the team could benefit from better stack technologies and a bit more discipline in how it is applied to solutioning.

For our specific case it's actually pretty good, we've built a lot of discipline around maintainability, but in general this is a recurring problem in tech teams who might not be able to afford the time it takes to gain discipline.

> What is the alternative to this tool that lowers the cognitive barrier / builds the right muscles for the team to understand what they should / shouldnt depend on?

Some programming languages allow you to split the codebase into modular units (npm workspaces, cargo workspaces, etc..) which forces developers to modularize things, and dependencies between modules need to be explicitly declared.

This is good, but usually not enough, as nothing prevents you to mess things up within a module/workspace.

There's some other tooling with similar functionality to dep-tree, but language-specific and with visualizations not suitable for large codebases (.dot files, 2d svgs...)