Is it possible to implement aPeak Hold

[Roughtrade]

Hi, advance thanks for the great application. My compliment ! Now my two concerns. Is it possible to switch Spectrum analyzer in full screen mode, or to change over a little change of the source code.

Furthermore, my question is it possible to implement a peak hold.

Best Regards Peter

[antiprism]

Hi Peter

Thank you for your comments and suggestions.

There is no configuration option for a full-screen spectrum, but you could make the change by modifying the source code. In main.cpp, edit the draw_spect_display function to look like

void draw_spect_display(ArduiPi_OLED &display, const display_info &disp_info)
{
  draw_spectrum(display, 0, 0, 128, 64, disp_info.spect);
}

(I notice, when doing this, that there seems to be some "burn in" of the clock screen on my display.)

Regarding a peak hold spectrum display, I have been lloking at adding configurable screen layouts to mpd_oled and when that is done it should be posible to include some extra spectrum display options. I will leave the issue open for now.

Adrian.

[Roughtrade]

I can confirm the burn in.

I did it like this: void draw_spect_display(ArduiPi_OLED &display, const display_info &disp_info) { draw_text(display, 2, 0, 5, "63"); draw_text(display, 17, 0, 12, "1"); draw_text(display, 21, 0, 12, "00"); draw_text(display, 35, 0, 128, "400"); draw_text(display, 57, 0, 128, "1k"); draw_text(display, 72, 0, 128, "2"); draw_text(display, 76, 0, 128, "."); draw_text(display, 81, 0, 128, "5"); draw_text(display, 91, 0, 128, "6"); draw_text(display, 95, 0, 128, "."); draw_text(display, 100, 0, 128, "3"); draw_text(display, 109, 0, 128, "16k"); draw_spectrum(display, 0, 10, 128, 64, disp_info.spect); } Starting with 7 Bars Gap 2 mpd_oled -o 6 -a 3c -b 7 -g 2 -f 20 -R

But i have a Line near the bottom of screen : https://pasteboard.co/IikrQgi.jpg

[supercrab]

@antiprism I'm excited to hear you've considered about custom screen layouts! :)

I've ordered a 256x64 oled screen and it's a SSD1322 so once i get it I'm going to make it work with your code. I'll have lots of extra pixels to play with and I want implement an album art to monochrome image function so there'll be a picture of whatever is playing.

Just an idea but you could have an xml file that defines rectangles/areas where you want specific items to be drawn, so you could define a layout for whatever pixel dimension screen you have relatively easily. Is this something that would be good as a solution?

<layout>
	<eq>
		<top>0</top>
		<left>0</left>
		<width>64</width>
		<height>32</height>
	</eq>
	<track>
		<top>32</top>
		<left>0</left>
		<width>128</width>
		<height>8</height>
	</track>
	<artist>
		<top>48</top>
		<left>0</left>
		<width>128</width>
		<height>8</height>
	</artist>
        <!-- AND MORE XML -->
</layout>

[antiprism]

Hi Peter

The spectrum widget parameters are x_start, y_start, width, height, and so if you start at y=10 then the maximum value for the height is 54. The height of 64 that you are using should cause the line to be written outside of the screen area, but maybe it is actually being written to the screen as the unwanted line you are seeing.

It is a nice idea to print the frequencies.

Adrian.

[Roughtrade]

height 74 and the line is away. thanks

[antiprism]

Hi

I am currently trying to get U8g2 working on the RPI to use as the base for mpd_oled rather than the modified Adafruit library. U8g2 has support for the SSD1332 controller and so if this works out then you will be able to use your display mpd_oled.

The U8g2 library sems really good, and well maintained, but requires custom code to work on the Raspberry Pi that doesn't seem to be available as a package. I believe all the necessary code is in ucgdisplay, but I am still in the processes of trying to make a working C++ library from it.

For the layout configuration I considered libconfig, XML and JSON. I liked the libconfig file format but I wanted to have base config files that could have their settings overridden by user supplied files, and libconfig didn't support this. Out of XML and JSON, I preferred the JSON format for its simplicity, and the "JSON for Modern C++" library works well and allows the overrides.

My current plan has a default config for the supported screen sizes. Screens are displayed according to player status (play, stop, etc). A default screen could be overriden by redfining the layout. A particular setting on the screen could be overriden. An alternative screen could be specified as a replacemnet (a number of screen layouts could be supplied with mpd_oled). This seems like it will allow a lot of flexibility while being easy to configure and easy to implement. Here is an incomplete base configuration I have been using for testing, so you can see what it might look like: layouts.txt

Adrian.

[supercrab]

Adrian, I think you’ve nailed there! Both with the U8g2 library and your JSON approach. Loads better than XML - it is 2019! ;) You have some great ideas there already.

My screen will probably takes weeks to come to from China and I’m not in any rush at the moment. I’d be happy to help with any coding and will able to test with my super wide screen, so I’ll let you know when I get it :)

On Fri, 7 Jun 2019 at 19:02, Adrian Rossiter [email protected] wrote:

Hi

I am currently trying to get U8g2 https://github.com/olikraus/u8g2 working on the RPI to use as the base for mpd_oled rather than the modified Adafruit library. U8g2 has support for the SSD1332 controller and so if this works out then you will be able to use your display mpd_oled.

The U8g2 library sems really good, and well maintained, but requires custom code to work on the Raspberry Pi that doesn't seem to be available as a package. I believe all the necessary code is in ucgdisplay https://github.com/ribasco/ucgdisplay, but I am still in the processes of trying to make a working C++ library from it.

For the layout configuration I considered libconfig, XML and JSON. I liked the libconfig file format but I wanted to have base config files that could have their settings overridden by user supplied files, and libconfig didn't support this. Out of XML and JSON, I preferred the JSON format for its simplicity, and the "JSON for Modern C++" library works well and allows the overrides.

My current plan has a default config for the supported screen sizes. Screens are displayed according to player status (play, stop, etc). A default screen could be overriden by redfining the layout. A particular setting on the screen could be overriden. An alternative screen could be specified as a replacemnet (a number of screen layouts could be supplied with mpd_oled). This seems like it will allow a lot of flexibility while being easy to configure and easy to implement. Here is an incomplete base configuration I have been using for testing, so you can see what it might look like: layouts.txt https://github.com/antiprism/mpd_oled/files/3267111/layouts.txt

Adrian.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/antiprism/mpd_oled/issues/18?email_source=notifications&email_token=AAIMSJHVEYQNHCRNJBPVPEDPZKPCJA5CNFSM4HVVRMFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXGSBTA#issuecomment-499982540, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIMSJEVM2AJ2U6WFINGMETPZKPCJANCNFSM4HVVRMFA .

[Roughtrade]

Hello, Adrian, I really need a tip. The spectrum display is at least half a second faster than the music. I already have all configurations with buffer_time and so on through without a nominal effect. it is possible to set a latency for the fifo in the main.ccp.

with best regards

Peter

[antiprism]

Hi supercrab

Thanks for the offer of help. I don't know how long the initial changes wil take me (weeks or months?), but once they are implemented I will see if I can document the remaining tasks, in case any of them seemed interesting for you to look at.

Adrian.

[antiprism]

Hi Peter

I am running Moode at the moment and I have been unable to make any changes that affect the spectrum synchronisation in any way. Increasing the MPD buffer size had no effect beyond delaying the start of audio. Changing the "buffer_time" parameter did nothing. On further review, it looks like "buffer_time" isn't used for "fifo" audio_output, and only works with alsa audio_output. If you coud set it to a small value in the alsa audio_output section of mpd.conf then you might be able to reduce the delay, see here: https://github.com/karlstav/cava#from-mpds-fifo-output

Adding the delay in the mpd_oled code is not a simple change. It would require the spectrum data to be buffered until the delay time was up before writing to the display.

You could try to track down the source of the delay on your system. It seems like the audio fifo is being written, and then some other procesing is happening to the audio that is played. Maybe it is being buffered or some time delay applied after the FIFO is written. Could this come from an equaliser?

Adrian.

[antiprism]

Hi Peter

Setting a large buffer_time in the "alsa" audio_output advances the spectrum display for me, so setting a small one should help you. However, if you are on a system that autogenerates /etc/mpd.conf then it may be difficult to get the change to stick or even to make the change at all (on Moode, if I make the change and restart MPD manually to avoid the regeneration then the Modde UI doesn't work correctly).

Adrian.

[Roughtrade]

hi Adrian, I also have moode running. But my installation is very adapted, because I have some things adapted for me. I make all changes to the console. But exactly the things you just described I did without success. But now it's time to think. I have a crative aptx Bluetooth adapter that is recognized as its own sound card when I want to listen to Momentum 2 with my Sennheiser. With Apt-x the visualization and audio runs syncron. About the Allo kali/piano dac/i2c the described problem is present. Very well suited for testing is the koln concert by Keith jarret.

Peter

[antiprism]

Hi Peter

It looks like the delay is introduced by the Kali reclocker

https://forum.kodi.tv/showthread.php?tid=321521

I am not sure if this can be worked around by system configuration.

Adrian.

[Roughtrade]

Hi Adrian, Thank you for wasting time together on an unsolvable problem. But my consoles knowledge participated in it. I have now deactivated everything that is possible for the piano dac in the MPD Config.

audio_output { type "alsa" name "PIANO DAC / KALI" device "hw:0,0" mixer_type "none" auto_resample "no" auto_format "no" auto_channels "no" replaygain "off" use_mmap "yes" dop "no" always_on "yes" } When I now play SACD ISO and the DAC plays the DSD files, mpd_oled is syncron with the audio signal. Unfortunately not with normal flac and mp3 files.

Thank you for the great support.

[antiprism]

Hi Peter

If the Kali (or other) reclocker introduces a delay then mpd_oled should really have a delay option to be able to work with this equipment. I'll take a closer look at what is involved in implementing the delay. If it seems like something I could do quickly then I'll add it in straight away. I'll let you know.

Adrian.

[apauliah]

Greetings @supercrab & @antiprism,

Any luck in getting SSD1322 display and U8g2 lib working with mpd_oled? I recently got a SSD1322 (256x64) display and would like to use it for mpd_oled. I can do a bit of coding, so would love to help in my spare time if needed.

@antiprism, Thank you for your mpd_oled s/w, it is amazing Regards Alex

[antiprism]

Hi Alex

Thank you for your comments on the mpd_oled project.

I checked the feasibility of using U8g2 on the raspberry Pi, and created a repository that bundled the required components here: https://github.com/antiprism/libu8g2arm_test

I did quite a bit of work on custom layouts for mpd_oled earlier in the year, which I wanted to finish before integrating U8g2, but I then had to put everything on hold. I am optimistic I will be able to return to this soon.

Thank you for your offer of help, I will keep it in mind when I start looking at the development code again!

Adrian.

[supercrab]

Hi @apauliah

I did manage to get my SSD1322 working but the refresh rate on my Pi 0 was too slow so I abandoned it. I asked someone else to try my code but it never worked for them and I never got to the bottom of why. There was another library based on U8g2 that looked good: https://github.com/wuhanstudio/u8g2-arm-linux

When I tried this it didn't work for me either, so there must be something weird with my environment or something. I never tried my screen on anything other than a pi zero as in my use case I wanted to use a cheap microprocessor in the system.

I know that the good man Adrian is on the case with a new version (albeit on hold) with u8g2 support and customisable screen layouts.

It might be worthing looking at

https://github.com/diehardsk/Volumio-OledUI

and

https://github.com/Maschine2501/Volumio-OledUI

They had success with their screens using python...

Cheers Mase

[apauliah]

Adrian & Mase,

Thank you so much for the quick replies. I currently use mpd_oled with a ssd1309 2.4in display that works very well. I am working on a new player (RPI4 + ssd1322 + volume control + sound card <- still deciding) for my wife's office.

I'll take a look at the links that you have provided, it gives me a starting point for the project. Once again thanks very much for the info. Regards & stay safe Alex