LyricForge Song Generator

First, the thing that trips everyone up: LyricForge Song Generator is not a music model. It doesn't synthesize a single note. It's a text-generation node that sits in front of HeartMuLa and does the tedious job of describing the song you want, in the exact format HeartMuLa expects. You type "j-pop, winter song, female vocal, snow, cafe" into a box; it calls an LLM; it hands you back comma-separated style tags plus a full set of lyrics with structure markers. Then you feed those into HeartMuLa and let the actual diffusion happen.

Why does that exist as a node? HeartMuLa's tag system is a legit schema, not freeform text: eight categories (Genre, Timbre, Gender, Mood, Instrument, Scene, Region, Topic), each with a selection probability that tells the model how much to weight it. Genre is 0.95, Topic 0.10 - so the LLM needs to nail the genre and treat the topic tag as a whisper. Hand-authoring that from scratch is fiddly. This node encodes the whole spec in its system prompt so a plain-English description becomes valid tags. It's the ComfyUI equivalent of a good prompt engineer, minus the invoice.

How it works, mechanically: it builds a HeartMuLa-spec system prompt (the full category/probability table, comma-separated-tags-no-spaces rules, structure-tag vocabulary like [Intro] / [Verse] / [Chorus]), then POSTs your keywords to an OpenAI-compatible /v1/chat/completions endpoint with temperature, and parses the reply into STYLE_TAGS and LYRICS sections. The whole thing is one synchronous HTTP call with a 120-second timeout - the source is ~19KB and depends on exactly one package, requests. No model weights, no HF downloads.

The inputs that matter: keywords (a multiline box - be specific; "cafe song" and "melancholic 90s cafe jazz with vinyl crackle" get you very different tracks) and the trio api_endpoint / api_key / model. Those three defaults are pre-filled for LM Studio (http://localhost:1234, key lm-studio, model local-model), and this is the trap: they're LM Studio's defaults, so if you point it at OpenAI or Ollama you must change all three. The endpoint auto-appends /v1/chat/completions if you leave it off, so http://localhost:1234 works fine. Beyond that: language (Japanese/English/Chinese for the lyrics), song_structure (Standard/Short/Extended), and temperature (0–2, default 0.7).

Outputs are style_tags (a comma-separated string like Pop,Female,Soft,Warm,Piano,Acoustic Guitar,Cafe,Romantic) and lyrics (structure-tagged text). Wire style_tags into the HeartMuLa node's tag input; the lyrics feed whatever text input HeartMuLa's workflow exposes.

Install: the README route is the real one -

cd ComfyUI/custom_nodes/
git clone https://github.com/knishika62/ComfyUI-LyricForge.git
cd ComfyUI-LyricForge
pip install -r requirements.txt

then restart ComfyUI. (ComfyUI Manager can grab it too - search "LyricForge".) That requirements.txt is just requests>=2.31.0, so this is about the lightest install you'll do this week. What it doesn't install: HeartMuLa itself. That's a separate custom node plus a multi-GB checkpoint you'll want a decent GPU for.

Where people get burned: first, the defaults - you'll get a connection error to localhost:1234 if you don't have LM Studio running or haven't swapped in real credentials. Second, this is a blocking call, so ComfyUI's UI freezes for the duration of the generation; that's expected, not a hang. Third, the node's error handling is blunt: on any failure the outputs become literal Error: ... strings, so if your tags suddenly look like error text, read the ComfyUI console - and check your endpoint. And fourth, the output is only as good as the LLM you point at it; the README recommends GPT-4, and honestly a small local model will hand you back generic tags. Your mileage will scale with your endpoint. It's a niche node for a niche workflow, but for HeartMuLa users it kills the most annoying step.