Super cute. Had never seen such a thing. This is an LP correct?
Correct; an LP.
1 Like
Here’s a really simple way to implement this: just add tag support to saved DSP profiles. Whenever a track plays that has a tag listed in the profile automatically apply the profile. Don’t allow the same tag in multiple profiles to avoid ambiguity.
1 Like
FWIW this would be next level functionality to really distinguish the value prop of Roon for streaming users. There’s plenty of poorly mastered streaming content that could be corrected this way and really set Roon above the native streaming apps.
1 Like
Hey @miguelito!
It’s a great idea for sure; setting custom DSP settings per album and/or track. Thanks for starting this thread and raising it to the Roon team.
Surely there are more pressing features than this, but this is one that everyone I have asked about is like “Yeah!”
It’s a great idea for sure but, as @rockphotog mentioned, we can’t possibly know how many people are requesting this among all other feature, issue, or bug requests. As a product designer myself, I’m confident the team at Roon appreciates and values your input and ideas. But there’s a product roadmap and backlog product teams need to work through to maintain and continue to deliver 
Totally get this, I work in software development as well. But I can motivate for sure… 
1 Like
You can go and vote for it here, it isn’t doing so well, so far…
Hi Bob, you say: “just add tag support to saved DSP profiles”. Can you provide link or a screenshot. Nothing found anywhere in Roon to do that. Thanks a lot…
Is that an official poll?
Not sure it is that simple… If you just did that, it would still be endpoint-associated, meaning you could not have another parametric eq on top. The Roon team seems to generally think about the feature in the context of the bigger software, not just to get a quick and dirty solution that resolves the use case (and I agree with their approach in this regard).
No just users.
Unfortunately lists like this become a catch-all for random stuff that is really not value add at all. Like “more themes”, or “native pdf support”, or “more liner notes”, etc - all things that are frankly not serious asks for various reasons (specifically for example the number of themes, native pdf support - what we have is fine, more liner notes is not something Roon can resolve)…
I do like some of the asks and voted for them. For example SACD-ISO support (though I won’t use it), by-track notes, etc.
Nevertheless I don’t know HOW it should work. For me its just a assertion at the moment. “just add tag support to saved DSP profiles”. Can you provide link or a screenshot. Nothing found anywhere in Roon to do that. Anybody knows? No words on that in the KB https://kb.roonlabs.com/DSP_Engine
My guess of how the architecture works is all DSP is endpoint-attached. This is why no overall DSP can be applied to grouped speakers for example - and there’s a feature request floating around for that.
In my view, we could have an overall DSP stage - applied to music - and an endpoint-specific DSP post that. The former is something that I gather doesn’t exist in Roon. It might require some complex architecture reshuffling to add it, as well as some GUI work.
So as I said, I don’t think this is an easy thing to do right, but in my opinion a very worthwhile thing that would further separate Roon from the competition and would definitely lock users in.
Sometimes an incremental approach makes sense. If they’re not sure how many people will use it, do something simple that they don’t have to put a big investment into to test the adoption. If it then proves to be valuable then they can do it from scratch with a fully integrated solution. Meanwhile the users that have been asking for the feature have something to use and can provide feedback on how the full solution should work.
You can definitely have two sets of parametric eq active on an endpoint. What I’m proposing is you create a DSP filter and then you can add tags to it that trigger that filter when a track contains the same tag. This reuses the whole tag system that most users know how to use to also control the DSP active for any given endpoint. This would be super flexible for advanced users to setup things however they want.
So say for this album I want crossfeed and a 3db bass boost. I simply tag the album like this:
In my DSP settings for my endpoint I would add the tags like this.
They could also add something to allow you to select which zones you want these filters to apply to. But to start you could just recreate the filters for the zones where you need this. Most people have only a couple of zones that are full range enough to benefit from this anyway. Zones that don’t have tagged filters aren’t effected. This is a simple way to add this feature without reworking the whole interface.
Personally I’d like to see this sooner rather than later… Too bad they don’t have code contributors. I’d be happy to prototype this for them… 
Actually if they exposed tags for the next playing track in the status API and DSP enable control in the volume API this could be written as an extension…
I work in something close to industrial software development, and I will say this is not usually a good idea. Not that all i’s need to be dotted and t’s crossed, but architecturally suboptimal decisions should be avoided. It is a slippery slope.
Yes I understood exactly what you proposed. It would always have to be a form of tag.
Still I am sticking to my comment above. You don’t and should not develop software that requires all features and options present on the first release, but you should as well have discipline not to create architecturally bad choices that have a tendency to become a cancer. I know because I have seen it countless times. As an example, if you set “Parametric Eq” to be tag-associated within an endpoint, people would complain that it removes their ability to make an endpoint have some sort of specific eq for that endpoint, for all tracks.
An intermediate solution that would be endpoint-based could be to add a new type of eq - “Parametric Eq By-Track” - as a duplicate to “Parametric Eq”. This would be a little cleaner, but doesn’t address the other asks floating around such as applying Eq to a grouped set of speakers.
In my opinion a layer of DSP prior to endpointing makes sense architecturally. But then again I am just guessing what the Roon team has built already in terms of DSP and how it intertwines with endpoints.
Nice Description👍 But I thought that already works😂 Sorry my misunderstanding
There is the potential for some confusion around what endpoint DSP is for versus what it is for when applied to a specific track/album.
To my mind when you specify DSP for an end-point you are mostly likely dealing with a broad brush, either room correction or equipment correction of some kind.
If you specify DSP for a track/album you are correcting in a specific way for poor mastering, or low output level, personal preference etc.
In that case would it not make sense to actually overlay the DSP for both the endpoint and the track? It could well make a mess of things of course, but then it would be up to the user to ensure that they have differentiated their DSP settings appropriately according to the application; room/equipment or track.
EDIT: Just to say I know very little about how DSP is applied and what it would mean to ‘overlay’ settings, it could be total nonsense for all I know. However it would seem to make sense, from a purely logical perspective.
Correct. But I use that because I have no choice.
I don’t understand what you mean by “overlay”. The way I would do it is simply a step pre-endpoint selection where I can apply DSP by track, then routing to endpoint or grouped endpoints where a second DSP step could be applied. I think this would make the most sense - if you don’t do it this way, then you have all sorts of usability issues like for example having to set the by-track DSP by hand on every endpoint - just a mess.
But as you can also see this makes the ask not so simple as you would have to create a layer in the code plus a control entry in the Setting menu to control this new layer. So it is not so simple, I acknowledge that, but I think it would be of great value-add to have a DSP layer associated with the material distinct from a DSP layer associated with the endpoints - this makes sense to me architecturally.
Mathematically, figuring out by frequency what the “total correction” should be vs simply applying each correction one after the other is equivalent, assuming each correction is not large.