Add hotcue count library column

[mxmilkiib]

Implements #15461

Adds a new "Hotcues" column to the library that displays the number of hotcues set on each track.

Implementation

Database schema (v39→v40):

• Added column to library table
• Populated during migration by counting existing hotcues from cues table

Column infrastructure:

• Added to ColumnCache enum
• Added column properties with "Hotcues" title, default width 50px
• Included in BaseTrackCache column list so it appears in UI

Display formatting:

• Shows count as integer (e.g., "3")
• Empty cell if count is 0 (cleaner UI)
• Right-aligned like other numeric columns (BPM, Duration, etc.)

Automatic maintenance:

• CueDAO automatically updates count after saving cues
• CueDAO automatically updates count after deleting cues
• Uses SQL COUNT query: WHERE type=1 AND hotcue >= 0

Behavior

• Column shows number like "3" if track has 3 hotcues
• Shows nothing (empty cell) if track has no hotcues
• Automatically updated whenever hotcues are added/removed/modified
• Works with existing hotcues via schema migration
• Sortable and searchable like other integer columns
• Right-aligned for easy visual scanning

Files modified

• res/schema.xml - schema migration
• src/database/mixxxdb.cpp - bump required schema version
• src/library/dao/trackschema.h - column constant
• src/library/columncache.{h,cpp} - column enum and properties
• src/library/dao/cuedao.{h,cpp} - auto-update logic
• src/library/basetracktablemodel.cpp - display formatting
• src/library/mixxxlibraryfeature.cpp - BaseTrackCache integration

[daschuer]

Thank you for this PR.

I have not understand the use case for this new column. Can you add a brief description how do you use it as user in terms of information aiding your DJing or track perpetration. In which situations is it especially helpful?
I am asking, because the vertical space is already limited and I can hardly effort more. Maybe we can find an alternative solution that fits better to your use case.

[mxmilkiib]

I am doing prep, going through many tracks and adding hotcues

knowing which tracks have hotcues means I'm not double clicking a which bunch of tracks around where I thought I left things, and also I know where I've left gaps, plus what the prep state is for any subset/filter of the largest create, etc

my preferred solution would be hotcue marks on the library waveforms. afaiu, this is trivial in comparison, and is convenient for my direct need, and it's something to help others in my situation

vertical space as in the height of the right-click menu? maybe my UI font selections hide that. is it literally causing a problem, or just a long menu that's not too long yet?

would the question be; how high is too high for a menu, what proportion of the screen?

a menu with two columns would be a first thought, but would that be trivial?

[daschuer]

Oh I meant horizontal space. I don't like horizontal scrolling. Bust since you need it only during preparation this shall be no issue. I have no objections to the new column, but let's stress the use cases a bit more.

my preferred solution would be hotcue marks on the library waveforms

That would be a very nice addition. Also during DJing.

How do you use hot cues?

In my case only some tracks have hot cues. So finding non-prepared tracks by number of hot cues will not work for me.

I can confirm the use case though. I look whether a track has a reasonable bpm/genre/year. This also does not work if I import pre-prepared tracks with a sloppy set of metadata. The same will happens to you if there are Serato cues set.

We already have the BPM lock state as manual flag. But we cannot sort by it. I have been also to lazy to use it for all prepared tracks. I set it only for manual adjusted Tracks.

Do you have an idea to improve that situation?

We have a "new" filter in the analyzing view. That does also not work for this purpose.

[Eve00000]

Hi,
I understand the use case:
The most clear option would indead be displaying the HCs on the library waveforms. (I'm not using those.)
Especially when you change ideas in the last X seconds of a track and you only gave time to choose the right track with the correct placed hotcue(s). (if you don't clean up your collection regularly it can be confusing) .
Just a suggestion:
With the table delegates we can add a [X MHC] (Mixxx Hot Cues) eg to the title in the table or even better: to the tooltip.
I use the tooltips (only) for the library, with a bigger font (to see the info clear from a distance).
In the tooltip we could add a row for each hotcue showing the position, type and the duration (in case of loop).
Disadvantage: you need to hover the field with the mousepointer.

[ronso0]

We already have the BPM lock state as manual flag. But we cannot sort by it.

But we can filter: bpm:locked #14590

For me a track is 'prepared if it has a rating:

• 0 stars (never listened, or postponed preparation, surprise track ; )
• 1 star means listened but shall be removed

[ronso0]

re: Hotcue on library overviews
The (static) overview waveform is rendered by waveformOverviewRenderer (namespace). WOverview handles all the dynamic visual stuff (hotcues, ranges, played overlay).
So even porting just hotcue markers (just the lines) to the overview delegate is a lot of work. Just check what overview is doing (draw.. functions) incl. track update signals etc.

This may be implemented entirely different from the ground up in QML, but for legacy skins this kind of refactoring is insane.

---

Previewing via the overview delegate is certainly feasible, like click and hold to play, drag to seeek. A 'played' overlay should also be rather possible by adopting some stuff from PreviewDelegate.

[daschuer]

CI is complaining about code style.

But we can filter: bpm:locked #14590

Thank you for the reminder.

Just tested a bit. This feature has the the issue that the library column is not immediately updated when adding/removing hot-cues. Sorting is also not yet working.

If we decide to use the info as tooltip, the library column can be reused. I do not expect any regressions because of this additional column. So it is kind of OK for me. What do others think?

The underlying use case, might be covered better by an "is new" or "todo" column. This can be at the basic mode just a manual flag, default checked. We may consider to add hints like "missig year" or ... maybe a set of custom rules to check track propertied for completeness.
Than it becomes complicated ... what do you think?

[Swiftb0y]

alternatively: instead of adding a new hotcue column, would a new filter suffice too? I feel like this should be a fairly simple query with a JOIN, GROUP BY, and COUNT...

[ronso0]

I also prefer the filter.

[ronso0]

The underlying use case, might be covered better by an "is new" or "todo" column. This can be at the basic mode just a manual flag, default checked. We may consider to add hints like "missig year" or ... maybe a set of custom rules to check track propertied for completeness.

I think this is the same situation as described in #14503 / #14689: how to filter "new" tracks?

• not analyzed? (no BPM, no key?)
• no (Mixxx) rating?
• never played?

I think the definition of "new" varies. It may mean "new to Mixxx" or "new to user" (not rated, not sorted into crate, ..).
What if "new" is therefore defined by the user with a set of criteria in the preferences?

[mxmilkiib]

yeah I think there's several optional and overlapping reasons for calling a track "done"

hotcue number is one, but what the count is does not necessarily relate to whether that track counts as done in terms of hotcue quality, and then there are other elements to consider that might be done or not

I agree that the further option of a todo/done column would be cool for those who would use it

but I don't think it's the same

personally I give good+done tracks a green label

[mxmilkiib]

having the track not be moved until the user resorts

vs. the track jumping out of view and not be followed was frustrating/jarring, and I think any view-change mechanism is a spot deeper, so I parked it as it is

[daschuer]

personally I give good+done tracks a green label

That certainly works, but I see you loose the colorimg feature for other sorting/group properties. Is that one of the reason for this PR?

This means a dedicated done flag will help to bring the original coloring feature back for you as well. But the hot-cue column would do it automatically in your case?
Is that correct?

Conclusion: the hot cue tooltip will not help for this.
A semi automatic "prepared" state, maybe covered by a flag field. Seem to be the full blown solution. Suggested by @ronso0 #15462 (comment)

If we treat the number of hot cues as the first property for this, your work could be the foundation.
Maybe we can invent a nice pie chart icon for this?

[mxmilkiib]

no, I don't use hotcue count as a sign that the track is "done"

[ronso0]

would the question be; how high is too high for a menu, what proportion of the screen?

I think menus are already split into columns if they don't fit the screen. See crates or playlist submenu when you lots of them.
I think we try to make LateNight (biggest skin) fit on 1366x768px screens. For me the track header menu is already 740 (and I'm about to add more actions in #14479 😬 ) So, yeah the menu is quite tall already.
Multi-column menus are ideal, but we won't sacrifice columns to make it fit, right 🤷‍♂️

[mxmilkiib]

different font I guess!

does Qt do double column menus? ("a QHboxLayout of QVBoxLayout"?)

[ronso0]

different font I guess

apparently, and a bigger screen (mine is 15") and/or eagle eyes.

does Qt do double column menus?

Jup.

[acolombier]

Perhaps we could render the hotcues in the waveform overview column? Aligned with the tooltip you are working on @ronso0, this should provide all the information needed?

[ronso0]

Perhaps we could render the hotcues in the waveform overview column?

I'm sure we can, but with the current design it's not trivial to port all the mark handling /painting from WOverview (setup colors from skin, connect change signals) to waveformOverviewRenderer / OverviewDelegate.
I mean we could pass a Track pointer to waveformOverviewRenderer::render(), fetch the hotcues and at least draw the hotcue lines as they don't require the WaveformMark stuff.
Updating the overview column on hotcue change is another challenge..

[mxmilkiib]

#14994

[github-actions]

This PR is marked as stale because it has been open 90 days with no activity.