u/rollandburn

Is sustained HIGH CPU usage in Lexicon states expected behavior, or do these numbers indicate a runaway audio processing / render loop?

System is a MacBook Pro M4 Pro Max, 64GB RAM, macOS Tahoe 26.5, Low Power Mode disabled. (using latest lexicon as of 2026.06.03) The issue is observed after the application is fully loaded and stable (not during startup or import). The library is not new, i'm not doing any batch processes or running anything special in lexicon other than hitting the play button.

During active song playback, Activity Monitor shows Lexicon Helper (Renderer) at ~55% CPU with ~1400 Energy Impact, while Lexicon Helper (GPU) sits at ~15% CPU with ~500 Energy Impact. This by far and away much higher than any other app... it's just doing song playback. No visualizers etc. I notice the audio crackles when moving the mouse over any part of the lexicon interface... and also the waveform stutters and is not smooth at all (this has alwasy been the case).

When playback is stopped but the app remains open, Lexicon Helper (Renderer) still shows ~40% CPU and ~700 Energy Impact, while Lexicon Helper (GPU) drops but remains active at ~2.4% CPU and ~60 Energy Impact.

I don't have audio issues with any other app on my system, or runaway cpu numbers for any other apps.

The main pattern is that the renderer process does not return close to idle when audio is not playing, and overall CPU usage remains elevated in both states, with only partial reduction when playback stops.

Edit: just in the 10 mins since posting this, without a song playing and the app sitting idle.... Lexicon Helper (renderer) is up to 2000 Energy Impact and 80% CPU. After waiting for several minutes without touching things, energy/cpu values drop way down (ie. 50 & 9)... then climbs again quickly to the numbers sbove (700 & 35-40 cpu).

Edit 1hr later... tracks just playing in the background while i work on other things: Lexicon Helper (Renderer) {{business.name}} || Email Notification || Missed call from {{contact.phone}} shows Energy Impact = 2400, CPU = 82%

Hi,

I think the new Smartlist Generator is a great idea and is heading in the right direction, but in its current implementation it produces a lot of impractical results which feel like they may be unintended.

For example, I use:

• Grouping for top-level categories (Drum & Bass, House, Techno)
• Genre for specific genres (Jungle, Deep House, Minimal Techno)

When I generate smartlists using those two fields, the generator creates combinations of every value from both fields. This results in many impossible smartlists such as:

• Drum & Bass + Deep House
• House + Jungle
• Techno + Liquid

These smartlists will always be empty because those combinations do not exist in the library.

In my case, the generator created over 2,100 smartlists in a single folder, many of which were unusable. Adding a third field such as Energy would increase that number to 21,000 smartlists in one single folder... most of which would be empty due to impossibility.

What I expected instead was a hierarchical structure based on the relationships that already exist in the library:

Drum & Bass
├─ Jungle
│ ├─ Energy 1
│ ├─ Energy 2
│ └─ Energy 3
├─ Liquid
│ ├─ Energy 1
│ ├─ Energy 2
│ └─ Energy 3

House
├─ Deep House
│ ├─ Energy 1
│ ├─ Energy 2
│ └─ Energy 3
├─ Afro House
│ ├─ Energy 1
│ ├─ Energy 2
│ └─ Energy 3

Some possible improvements:

1. Avoid generating smartlists for combinations that do not exist in the library.
2. Support folder hierarchy based on the order of fields selected in the generator.
3. Avoid placing thousands of smartlists into a single folder.
4. Generate child smartlists only from values that actually exist under the parent rule.
5. Allow Energy ranges instead of only individual Energy values (not necessarily only about smartlist generator).

The current 1-10 Energy scale is more granular than many DJs actually need for playlist organization. In practice, I find broader ranges much more useful, such as:

• Energy 1-2
• Energy 3-4
• Energy 5-6
• Energy 7-8
• Energy 9-10

This allows tracks with similar energy levels to remain grouped together while keeping the playlist structure manageable.

I've been creating these ranges manually in my own smartlists, but when the Smartlist Generator creates separate playlists for every individual Energy value, it effectively doubles the number of generated playlists without providing much additional utility.

It would be helpful if the generator could optionally support Energy ranges (or user-defined buckets) rather than only generating playlists for each individual Energy value.

I understand there may be technical reasons for the current behavior. for example, the software may treat Grouping and Genre as unrelated fields and therefore has no way to know that "Drum & Bass + Deep House" is impossible. However, I think this relationship-aware behavior is exactly what would make the feature practical for large libraries.

More broadly, if a Grouping value is present, Lexicon could potentially use that relationship elsewhere in the application as well. For example, when selecting a Genre, the available choices could be limited to genres that actually exist within the selected Grouping.

The concept is excellent, but without some awareness of relationships between fields, the generated results become difficult to use in real-world DJ libraries.

Edit: added #5