Web Port

[elicwhite]

FYI, I ported this to onnx and put up a small demo site where you can see the results:

https://github.com/elicwhite/LinkSeg-web and the demo site at https://www.eli-white.com/LinkSeg-web

Thanks for sharing this model! Let me know if you want me to change anything in my repo or demo

[morgan76]

Hi Eli,

Thanks a lot for sharing this, this is really cool to see! The browser port and demo look great!

I had one thought about the sensitivity slider. From what I understand, it currently controls tau, i.e. the absolute threshold applied to the boundary activation curve. That makes sense, but I think a more musically interpretable control might be a “segmentation granularity” slider that controls the peak-picking window instead.

In the current peak-picking logic, maxLeft and maxRight are computed values: they correspond to the strongest competing boundary activations in the local left/right neighborhood of a candidate boundary. The actual parameters controlling this are the sizes of those neighborhoods, currently maxPast and maxFuture.

So instead of exposing only an activation threshold, it might be useful to expose a symmetric window size, for example peakWindowSeconds:

const peakWindowSeconds = granularityToWindow(sliderValue);

decode(bound, label, beatTimes, duration, {
  maxPast: peakWindowSeconds,
  maxFuture: peakWindowSeconds,
  tau: 0,
});

The behavior would be:

• smaller window → more local peaks survive → more boundaries / finer segmentation;
• larger window → stronger suppression of nearby peaks → fewer boundaries / coarser segmentation.

You could still keep tau as an advanced parameter, but I think the peak-picking window would probably be easier for end users to understand, because it corresponds more directly to segmentation granularity. Therefore, tau could by default be left to 0.

Thanks again for doing this, it’s really nice to see this model running in this form.

[elicwhite]

Thanks! I updated https://www.eli-white.com/LinkSeg-web

[morgan76]

Thanks, that was fast! The updated granularity control feels much more natural.

I had one additional thought about the section visualization. From what I understand, the current display merges consecutive sections when they receive the same mapped label. I think the raw/unmerged segmentation would be a more meaningful default mode.

Musically, repeated labels are not necessarily redundant. For example, two consecutive verse or chorus regions can still correspond to two distinct occurrences in the form. So I think it makes more sense to preserve the raw predicted boundaries by default, even when neighboring segments share the same label.

Merging adjacent identical labels could still be useful as an optional “simplified view” or “merge repeated labels” toggle, especially for a cleaner high-level summary. But for the default visualization and for inspecting the behavior of the model/decoder, I think the raw version is more informative.

So my suggestion would be:

• default: show raw peak-picked sections, including consecutive repeated labels;
• optional toggle: merge adjacent sections with the same display label.

This would also make the effect of the granularity slider more transparent, since boundaries would not disappear just because two neighboring segments happen to have the same predicted label.

What do you think?

[elicwhite]

Claude is a big help. :D

I've updated the page again, give it a try. I tried a couple different visualizations and liked this the best.