[SOLVED] allow local mpd modifications without overwriting them

[hindumagic]

Just keep in mind that what you are using is a developer tweak meant to make testing new things easier. It's not a feature and it might not exist in upcoming versions of moOde.

Your best bet is to make a case for an MPD fifo output to be included in stock moOde.

Point taken.

I like the current approach with being able to modify mpd's config beside Moode.  But if it is only intended as a transitory development tool, then perhaps investigating my original idea is a good solution.  I could experiment or look at mpd's details, but if the "include_optional" config directive behaves as Moode's current mpd.custom.conf approach then it would be a viable solution.

I like it because it makes things nicely flexible and yet is hidden away from the average user who shouldn't care to be there.

In general, I don't think most would want the extra overhead of having this output so including it in Moode's release isn't that useful, IMO.
Keep in mind that I've only been using Moode for half a week and I don't know how the upgrade cycle works,

[adrii]

Hi Tim

The mpd_oled instructions for Moode set up an MPD FIFO, as they do on all player OSs, and I would say the most frequently asked question for the project is why the spectrum doesn't work with Spotify. Airplay, Bluetooth... On the other hand, being able to enable an MPD FIFO on a release version of Moode would be a help for using mpd_oled compared to not having it, given that I am currently instructing people to patch Moode to enable it (and a help for me, as I have to create these patches).

Adrian.

[adrii]

Hi hindumagic

You might find you can adapt the mpd_oled code to your needs

   https://github.com/antiprism/mpd_oled

It uses cava to calculated the spectrum, and this can be configured to provide a stereo spectrum. You could add a Python wrapper using something like pybind11.

Adrian.

[bitlab]

Hi Tim

The mpd_oled instructions for Moode set up an MPD FIFO, as they do on all player OSs, and I would say the most frequently asked question for the project is why the spectrum doesn't work with Spotify. Airplay, Bluetooth... On the other hand, being able to enable an MPD FIFO on a release version of Moode would be a help for using mpd_oled compared to not having it, given that I am currently instructing people to patch Moode to enable it (and a help for me, as I have to create these patches).

Adrian.

For the time being; Using the dev tweaks is already a lot safer then patching the code 

In an ideal situation you wouldn't have to configure an additional output in mpd, but it is to sounding process layer between the application and the OS to add additional outputs and additional process routes with affecting or need to modify the application.

[adrii]

Hi bitlab

I do plan to take a look at whether I can provide instructions (or a script) for setting up an MPD FIFO using your method. It is better for me too, as I always feel a little bit guilty telling people to patch Moode!

Adrian.

[hindumagic]

You might find you can adapt the mpd_oled code to your needs

   https://github.com/antiprism/mpd_oled

It uses cava to calculated the spectrum, and this can be configured to provide a stereo spectrum. You could add a Python wrapper using something like pybind11.

Hi Adrian,

Yeah, I discovered Cava last night after digging through the projects forum.  Your mpd_oled is a slick integration.  I was going to look into Cava more, but it depends how adaptable it is (or how creative my integration can get).

I despise patching systems (as a programmer, that can get old, quickly), and it gets confusing for the inexperienced especially if the system to patch has changed.  Loosely coupled systems are great - each is flexible and can do things how they want, as long as they expose a simple interface for integration.

Leveraging the optional include config file from mpd would be a good solution for this situation, IMO.  The approach Bitlab outlined that I just used only works for the short term since there is no guarantee that it will be there for the next version.  It is really only good for keeping your custom modifications separate from moOde's config for your currently installed version.

I don't know if this is the place to bring up these ideas, but so far it seems that the only only reason for wanting to modify /etc/mpd.conf is to add the FIFO audio file.  If this is the only change that people could really request, then adding a simple checkbox to moOde's config interface would solve the situation.  BUT, it would make moOde far more flexible to simply include the "optional_include" directive in mpd.conf (assuming that it works like moOde's developer tools).

Ian.

[Tim Curtis]

The dev tweaks thing is not a feature. If we do anything to facilitate providing raw PCM it has to be for all the audio renderers. The only layer common to all the renderers is ALSA and so the solution lies in constructing an ALSA mechanism that can be turned on/off by user.

[hindumagic]

The dev tweaks thing is not a feature. If we do anything to facilitate providing raw PCM it has to be for all the audio renderers. The only layer common to all the renderers is ALSA and so the solution lies in constructing an ALSA mechanism that can be turned on/off by user.

I like that approach.  It is system wide and would clear up Adrian's issue with people complaining that the spectrum visualizer doesn't work for bluetooth, airplay, etc.

I wouldn't want to do it if it degrades the sound quality or taxes the pi too much (I'm pi2).  I came across this last night from the Cava project: https://github.com/karlstav/cava#from-al...ice-tricky

I'm not a fan of messing with ALSA (ran an HTPC for almost 20 years), but I'll be willing to help test out modifying the ALSA setup.  ALSA is fine for what it is, but I found that it gets annoying when you try to do anything fancy.

FYI, I quickly tested the functionality of mpd's include_optional config setting.  I used the devtweak to add the line to the end of mpd.conf.  To verify, I added another named FIFO out to /tmp, as well as defining log_level to debug in my included file.  "moodeutl -r" to restart and I have the new FIFO file in /tmp and my logging went from the previously defined "default" (whatever that is) to definitely debug logging.  Pretty good.

I couldn't easily test out the reverse situation, where mpd's include_optional directive is place before a command in the root config file that would redefine it (reverse my test of the debug log_level).  For some reason, restarting mpd via systemctl wasn't behaving and a moodeutl -r rewrites the mpd.conf file, losing my include_optional directive I manually added at the top of the file.  Ok, boring details...

Ian.

[hindumagic]

my logging went from the previously defined "default" (whatever that is) to definitely debug logging.  Pretty

FYI, and I know that it isn't a big deal, but "default" for a log level isn't defined in the mpd documentation, which is what moOde is writing to /etc/mpd.conf.  Defined options are: error, warning, notice, info, and verbose.

Should I bother raising github issues for little things like this?  Pull request?  Are these little things wanted at all or is this just noise?

Ian.

[Tim Curtis]

my logging went from the previously defined "default" (whatever that is) to definitely debug logging.  Pretty

FYI, and I know that it isn't a big deal, but "default" for a log level isn't defined in the mpd documentation, which is what moOde is writing to /etc/mpd.conf.  Defined options are: error, warning, notice, info, and verbose.

Should I bother raising github issues for little things like this?  Pull request?  Are these little things wanted at all or is this just noise?

Ian.

PR preferable but provide a link to the documentation. I suspect that "default" is still being handled in the code and prolly mapped to "notice"