No, you’ve got it right! Ideally, they both go on the same box.
The confusion is around HQPlayer Embedded as a daemon within another OS (I run Fedora 44 Server) versus HQPlayer OS.
For the former, which is what you have, running them on the same box is the simplest approach.
For the latter, where HQPlayer is the operating system, you actually can’t install other programs at all, so a separate box is required.
I’m excited to announce that I’m moving forward with one of the prototype mockups for version 2. I think this is a major step towards cohesion and coherence… properties lacking from v1. I also think that, with the help of a ~2 page guide, any newbie should be able to pick up enough speed to comfortably merge.
I’ll post a link to the mockup once it’s finished so that people can play with and poke at it for themselves. In the meantime, this is another teaser… and also another feedback checkpoint. If any of the below doesn’t sit right with you, let me know and I’ll see what I can do.
First and foremost, it’s highly compact: the whole thing fits on a 10.2" tablet screen with no scrollbars anywhere! I never actually intended to make v2 small, it just kind of happened.
No cards, no tabs, no special modes that duplicate settings: just one coherent interface. The default view always shows the core live settings: matrix profile, filters, shapers, and output format, while non-live settings are found in “drawers” that open by clicking on the relevant portion of the signal path. Some drawers are further organized into tabs.
Please don’t be shy with feedback 
and once again, I’ll be posting a link to the mockup for people to play with once it’s ready.
Great update! Running Roon Remote on a tablet is basically my daily setup, so having HQPTuner fit seamlessly on the same screen is wonderful news. I’m sure I’m not the only one thrilled about this.
Hey all! I need a quick opinion check…
Do you actually use “auto” output mode? That is, where output format follows the source: PCM sources output PCM and DSD sources output SDM.
The reason is that auto mode is giving me a lot of headaches… for example, that mode makes both chain’s filters relevant, but there just isn’t room on the main page for two sets of filter dropdowns.
So whenever I ask “is this new idea going to fit?”, the answer is too frequently “yes, except in Auto mode”.
It’s possible there’s a way to make things fit, but I’m not seeing it, so I think the simplest approach by far is just to drop the option. It runs counter to the manual’s guidance of “figure out which your DAC does best and stick with it” anyway.
If people actually use the feature, however, I am stuck with it and will have to figure something out.
Can I raise a possible issue?
Started HQPlayer for a listening session and had a track playing when I decided to load in a new preset. Changing presets in the configuration page works fine normally. HQPlayer will stop while it makes the change but you just wait a few seconds after completion before re-starting the track. Used HQPTuner this time to make the change but after doing an apply HQPlayer vanished. It was crashing because somehow the network interface had been changed to br0 in hqplayerd.xml and that interface doesn’t exist. I had to go into the file and manually correct it and everything worked after re-starting the daemon.
I haven’t tried it again as I want to listen to some music tonight but will try again when convenient. Is HQPTuner doing something naughty here? Using the latest version of HQPlayer Ubuntu Embedded 6.1.
Always! Also, just to encourage anyone else that finds any issues with the app like this to please report them ASAP.
Naughty? No, but possibly quite stupid.
The short version is that HQPlayer Embedded v6.0 had a bug in which the backup xml’s zip file would get returned corrupt/empty. In previous versions of HQPTuner, I worked around this. When v6.1 was released, that bug was fixed, so I adjusted my code accordingly… my working hypothesis is that your bug is somewhere in this new code.
I’m having a hard time recreating it on my own. Would you mind DMing me a zip file containing your state/ directory? And/or enable debug logging in the container, reproduce it, and send me the log.
I’d also appreciate it if you could file an issue on GitHub and we can work from there, but this thread is also fine if that’s too much effort.
Let me see if I can repeat this first and take it from there.
Just to be totally clear, were you mixing controlling HQPlayer via both the default interface and HQPTuner? Because, while there is probably a bug underneath it all (I have no idea where br0 could have come from), mixing the two like that will cause an issue.
The main reason is that I don’t use the daemon’s preset system at all; I built my own preset management system internal to HQPTuner. The daemon only ever sees changes to [default] via HQPTuner. I did this to work around the daemon’s “cool preset change, but I’ve decided to load [default] instead” behavior. This was the only way to meet my promise of “always get back the settings you send” without having to dual-restart the engine on occasion.
My system syncs presets to the daemon, so you can use HQPTuner’s presets from the daemon. But HQPTuner doesn’t understand “the daemon has a saved preset loaded now” and that’s probably what broke your setup.
My recommendation for now is to let HQPTuner manage preset saving/loading and, if you want to use the default UI for other changes, that shouldn’t be an issue.
On my end, I’ll see what I can do, but at first glance, it appears that the daemon continues to answer with a profile name even after switched back to [default] until it fully resets via systemctl restart. I could add some kind of guard for when there’s an active profile, but it may be overly aggressive if you’ve already gone back to default.
As promised, please find a link to the v2 mockup below. There’s a control strip at the top of the page that you can use to imitate various playback scenarios and screen sizes.
https://claude.ai/artifact/TDCf3zE1nWfFgKFvui58G7
This is a mockup: a dummy program that I’ve been using to nail down the visual language before I translate it into the real app.
While this is far, far more polished than the screenshots I sent before, it’s still a work in progress, so whenever I update anything, the mockup may freeze and reset on you. That said, most of the visual language is locked in, I’m mostly just tweaking the finer details at this point. The Builders are the areas that still need the most work, but you can get the gist regardless.
Certain things, like the Setting Switcher, aren’t wired up at all on purpose: the intended behavior is obvious, so use your imagination. Other things like the DSP pipelines had to be wired up to the extent that you can get a feel for how the interface manages them.
It is highly compact and fits on a 10.2" tablet screen with no scroll bars. As I said before, this was never an explicit goal of mine, it just happened, and I didn’t fight it.
The main settings are always on the front page. Everything else is either in “drawers”, or in Settings (top right). Click on a portion of the signal path to open its drawer and see the related settings.
The bottom bar can be switched between the Setting Switcher, volume control, or being hidden.
Easy Mode filters are now found in the “Filter Presets” popover.
Any feedback at all is helpful, thanks
I have been able to reproduce it.
mcast_interface=“br0”
I had to manually amend these to get HQPlayer working again.
I believe the preset was loaded and saved so I’m a little confused about the dual save buttons.
Should not your tool reproduce what the HQPlayer is doing? It shouldn’t matter which method is used.
This looks amazing, Adam! Can’t wait to actually use this!
Pretty sure everything we need is right here. If I had to be super picky though, having the HF filter settings and the spectrogram on the same screen would be awesome.
Oh, and one more thing: I’m a total sucker for bouncy VU needle meters. Feel free to shove “level meter visual overhaul” all the way to the very bottom of the roadmap 
I got it.
All of your presets have br0, and HQPTuner loads a preset by writing the whole thing into HQPlayer’s main settings file, including (erroneously) that interface. HQPlayer’s own preset load leaves the interface alone.
The fix is for HQPTuner to just not overwrite that part of the config, similar to HQPlayer.
As much as is feasible, yes. In this case, that discrepancy is a bug and is being fixed right now.
But as for the preset system, I did have to blind HQPlayer to which preset is active and always use [default] to prevent it from reverting to default to keep my promise of “you always get back the settings you sent”. That said, I don’t think this actually affects your bug, which is a separate issue.
As for Apply and Apply and Save, the difference is:
So for example if your preset is locked on two filters, but you want to experiment with a different filter, you could apply only.
Personally, I always use auto-save so that everything is exactly where I left it, making both buttons redundant, but that’s not necessarily how everyone uses the program.
Hm, I think my old poll above for v2 missed the point and didn’t give the right options. I mean, of course there’s still work to do, it’s a mockup.
Let’s try this:
If you choose the last two options, please explain!
If you just want to experiment with filters, you can switch on the fly without touching any of the configuration files. Configuration files only contain static startup default values for things like filter, modulator, etc. But those can be dynamically changed to anything else on-the-fly during playback, at any time.
Intention is that any experimentation happens through the dynamic settings which are really quick to change, and once settled to something semi-permanent, would get written to a configuration file.
Configuration profiles are mostly to facilitate different configurations for different output devices, where you have various DACs/NAAs around and want to switch between.
Fair, and my example of switching filters was a bad one. I mean, some people get overwhelmed by the list, pick “sinc-M” because they’d read about it somewhere, and may only experiment occasionally (I’ve talked to someone who had that exact approach) without wanting to change the default. I’d hope HQPTuner would be sufficiently informative to break that habit… but as the old saying goes, you can lead a horse to water but you can’t make it drink.
Perhaps a better example of the difference between “Apply” and “Apply & Save” is tweaking an EQ curve; one approach is to make a matrix profile for every iteration and switch between them live. A quicker approach to see if you even like the direction is just to make the tweak and hit Apply, listen, and then decide whether or not to save. If you don’t like the change, you can just revert the preset to what it was before.
This can apply to lots of settings that one might want to experiment with without writing to their preset, e.g., IIR to FIR.
That said, there is probably a simpler way than to have separate Apply/Apply & Save buttons. It’s clear the system is somewhat confusing between the two buttons and the auto-save feature (which then makes apply & save entirely redundant with Apply), so I’ll have to think on what I can do.
This is why the dynamic (runtime) settings exist, without having the adjust the configuration.
This is what the matrix profiles are for, so you can create various matrix profiles with different configurations and switch between those on the fly while music is playing.
Strictly speaking, this doesn’t require engine restart, unlike changing things on the main configuration part. But the entire settings things is now handled as a bundle. Like now settings and library are separate. Theoretically matrix could be also a separate part, but it still needs to have an atomic point where the settings are consistent.
Fair on all points. I’m cutting Apply & Save and Auto-save from v2’s mockup now; Apply will always write to the preset from now on.
I’ve also uploaded v1.15.4, which fixes the bug described above. It also renames the previous “Hybrid” modulator family the “Multi-bit” family, which is more accurate now that the multi-level modulators are gone and replaced with other multi-bit designs.
Is there a really basic guide for how to install HQPtuner.
I have never touched Linux until this weekend installing Ubuntu and then HQPlayer embedded.
I am keen to try HQPlayer tuner and happy to pay for it if it works well. Has a price been released yet?
I need really simple install instructions. I had a look at the GitHub folder and didntvunderstand anything
Regards
Andrew
Not yet. Version 2 will come with a guide, but there isn’t one yet. I’m actively writing it.
No worries, getting started with Linux can be intimidating at first, but it’s perfectly manageable.
It’s free
Let’s get started: Are you on Ubuntu Desktop or Server?
Either way, you probably at least got that HQPTuner is currently distributed through a system called Docker.
Docker runs applications in ‘containers’: an independent, isolated, and pre-packaged virtual machine containing everything the app needs. Unlike traditional VMs which require dedicated CPU cores and memory, a container shares the host’s resources and kernel for efficiency. It cannot access the filesystem unless you give it explicit access to a folder.
For the Docker Compose system, the application and its top-level settings are managed by a file compose.yaml, which tells Docker how to build the container and how it communicates with the outside world.
So the overview of the workflow is:
compose.yaml file from the GitHub repo and place it in your HQPTuner folder.If not all of that made sense, don’t worry yet.
First and foremost, if you haven’t, set the HQPlayer credentials:
hqplayerd -u <username> <password>
If you’re on Desktop and have a graphical interface for software installation, use that to install Docker and Docker Compose; otherwise, use:
sudo apt install docker.io docker-compose-v2
Do NOT install Docker Desktop; the networking is not the same and it won’t work.
Now, once it’s installed, we’re going to have to dive into the command line a little bit to configure it, because “real” Docker has no GUI by default. First, start the service:
sudo systemctl enable --now docker
Now, we’ll prepare for HQPTuner by making a folder for it in your home folder:
cd ~ # move to your home folder if you're not there already
mkdir -p hqptuner/state # this makes both folders at once
cd hqptuner # move into the new HQPTuner folder
Now, create the file compose.yaml in the HQPTuner folder (not state/) and fill it out with the contents from here. Save and close (if you need to do it from the CLI, that’s nano compose.yaml, paste, then Ctrl+X to save).
Finally, you’re ready to “pull the image” (download the container) and build it:
# one of these two will work
sudo docker compose up -d
sudo docker-compose up -d
That’s it, HQPTuner should now be running, check 127.0.0.1:8090 in a web browser if it’s running on the same machine, or <ipaddress>:8090 if it’s on a separate server. You’ll need to enter the credentials in HQPTuner; if the connection window doesn’t pop up automatically, click the status pill in the top right.
Don’t hesitate to reply back or DM me if any of that’s confusing or if you hit a snag somewhere!
Last but not least, I highly recommend two additional containers:
I made version 2 fit on an iPad Mini by stacking the clipping and apod lamps and expanding the signal chain up into the engine row
The Mini is a little wider but ~66 px shorter than the 10.2" format, and the signal chain’s height/density is the main thing stopping me from going smaller than this. Going smaller than this would eat into either/both the top bar and/or the Setting Switcher bar at the bottom; the only alternative would be forcing people to give up portions of the signal chain… like two minimum. A UI that says “sorry, you can’t go that small until you cut at least two signal chain options” is bad by any metric in my book.
I’ve also finally moved the mockup code into the repo and have begun the refactor that will prepare it for integration. I am so excited to use this myself! Version 2 looks so much better that I can barely stand to look at v1 anymore 
That means no more new features for v1; patches only from here.
Last but not least, I’m also so grateful and happy to announce that I am more than 50% of the way to my goal of being able to distribute signed macOS executables! Thank you so, so much to everyone who has donated so far 
! (and sorry Windows is taking so long! the computer is sitting next to me right now, it just needs swapped out…)
