| Thread Review (Newest First) |
| Posted by Squar0L - 25-11-21, 17:31 |
(25-11-21, 00:34)bbishop Wrote: I'm very interested in your use of pygame to repackage the menu system, I've been looking for a way to display information from pure data (which I'm running alongside samplerbox for audio processing and digital synthesizer voices) while the menu system isn't actively engaged (my dream would be to plot wavetable coordinates onto the display as a sort of oscilloscope, or even just print the function and value of the last midi cc used)
Please take a look at the new fork of Hans's repo, under Python3-migration
|
| Posted by bbishop - 25-11-21, 00:34 |
(21-11-21, 16:47)Squar0L Wrote: Hi Hans,
I've added wiring to access i2c, and pygame/pygame-menu for framebuffer support. Here is the snippet from the Dockerfile I use to build the image:
Code: RUN apt-get update && \
apt-get -y --allow-downgrades install libsdl1.2debian/buster && \
apt-get -y install git python3-dev python3-pip \
python3-numpy cython3 python3-smbus portaudio19-dev libportaudio2 alsa-utils wiringpi \
libffi-dev python3-pbkdf2 python3-tk usbmount libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev libsdl1.2-dev \
exfat-fuse exfat-utils
RUN pip3 install rtmidi2 rtmidi-python pyaudio cffi sounddevice future wifi \
pyalsaaudio psutil serial RPi.GPIO RPLCD wiringpi pygame==1.9.6 pygame-menu
Pygame fully abstracts out the details of the display. I'm using a 320x240 SPI attached 2.4" Adafruit PiTFT LCD. Not using the resistive touchscreen, I could have. I wrote a rotary encoder python driver to feed into the pygame event queue, to look like a keyboard, so the pygame-menu operates off the encoders. No audible artifacts of any kind when using them during audio play.
I'm very interested in your use of pygame to repackage the menu system, I've been looking for a way to display information from pure data (which I'm running alongside samplerbox for audio processing and digital synthesizer voices) while the menu system isn't actively engaged (my dream would be to plot wavetable coordinates onto the display as a sort of oscilloscope, or even just print the function and value of the last midi cc used)
|
| Posted by Squar0L - 21-11-21, 16:47 |
Hi Hans,
I've added wiring to access i2c, and pygame/pygame-menu for framebuffer support. Here is the snippet from the Dockerfile I use to build the image:
Code: RUN apt-get update && \
apt-get -y --allow-downgrades install libsdl1.2debian/buster && \
apt-get -y install git python3-dev python3-pip \
python3-numpy cython3 python3-smbus portaudio19-dev libportaudio2 alsa-utils wiringpi \
libffi-dev python3-pbkdf2 python3-tk usbmount libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev libsdl1.2-dev \
exfat-fuse exfat-utils
RUN pip3 install rtmidi2 rtmidi-python pyaudio cffi sounddevice future wifi \
pyalsaaudio psutil serial RPi.GPIO RPLCD wiringpi pygame==1.9.6 pygame-menu
Pygame fully abstracts out the details of the display. I'm using a 320x240 SPI attached 2.4" Adafruit PiTFT LCD. Not using the resistive touchscreen, I could have. I wrote a rotary encoder python driver to feed into the pygame event queue, to look like a keyboard, so the pygame-menu operates off the encoders. No audible artifacts of any kind when using them during audio play.
|
| Posted by hansehv - 19-11-21, 22:35 |
Hi Squar0L,
Both are interesting.
I never got to adding rotary encoder support for the simple reason I don't use buttons anymore and therefor don't have the hardware. But it sure is an enhancement for those using buttons (and perhaps for me in future), because the menu system is cumbersome via buttons alone.
However I believe they can be attached to the available ports without needing an extra MCP23017.
And as I see it, the menu system can be operated with two buttons and one rotary ending in the need of 4 data pins - which are available. But you may have made another setup.
Besides, it may be a good idea to use an MCP, because then the occasional noise of the direct GPIO attached hardware might be suppressed (interesting thing to test..)
Framebuffer display is even more interesting.
- Did you need to install extra software/drivers on the image ?
- What pip install packages did you have to add ?
- Are you using it as a display only ?
So I welcome PR's, some notes on this:
Please make separate optional modules.
I am about to release a new version which some serious changes:- The image has a changed setup (OS, folder structure etc), giving (amongst others) PI4 support.
- The language is upgraded to python3, which has some incompatibilities with python2. During the 2=>3 migration I also changed & optimized the samplerbox code itself at various places.
Given the short time for the new release I am not accepting PR's on current version to be ported to the new version anymore. Sorry for this, but it's too complicated to merge incompatible branches - I hope you understand.
So options are to wait till the release (around christmas) or send me a PM to discuss a workaround.
The python3 branch on GitHub is subject to updates, so for the moment use this for information/introduction only. At release date it will be transferred to master and the python2 version will become a separate frozen branch.
Thanks for your input!
Hans
|
| Posted by Squar0L - 16-11-21, 19:22 |
|
I wonder if anyone interested in adding/using MCP23017 based rotary encoders instead of push buttons and frame buffer based LCD instead direct SPI drivers. It will make the Zynthian hardware and SamplerBox compatible and you can go back and forth. I have some rotary and frame buffer/pygame code working. If there's interest I'll clean it up and send a PR.
|
