Is it possible to implement aPeak Hold #18
Comments
|
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 (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. |
|
I can confirm the burn in. I did it like this: But i have a Line near the bottom of screen : |
|
@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> |
|
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. |
|
height 74 and the line is away. thanks |
|
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. |
|
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 ***@***.***> 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
<#18?email_source=notifications&email_token=AAIMSJHVEYQNHCRNJBPVPEDPZKPCJA5CNFSM4HVVRMFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXGSBTA#issuecomment-499982540>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAIMSJEVM2AJ2U6WFINGMETPZKPCJANCNFSM4HVVRMFA>
.
|
|
Hello, Adrian, with best regards Peter |
|
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. |
|
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. |
|
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. |
|
hi Adrian, Peter |
|
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. |
|
Hi Adrian, audio_output { Thank you for the great support. |
|
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. |
|
Greetings @supercrab & @antiprism, Any luck in getting SSD1322 display and U8g2 lib working with mpd_oled? @antiprism, Thank you for your mpd_oled s/w, it is amazing |
|
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 Thank you for your offer of help, I will keep it in mind when I start looking at the development code again! Adrian. |
|
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 |
|
Adrian & Mase, Thank you so much for the quick replies. I'll take a look at the links that you have provided, it gives me a starting point for the project. |
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
The text was updated successfully, but these errors were encountered: