Hi @wanthalf,
All the buttons you originally made do not respond to a longpress anymore.
Cheers,
Maarten
Recent updateā¦ Oram=Vangelis: Midi-Recorder still broken.See Oram-2409.3 Stable Point Release - #70 by fussl
Where is the GitHub issue for this?
Here is a working zynthian_gui_midi_recorder.py
Mind the difference to the one on Github.
Sorry. Maybe Iām too stupid to make Issues shown in Github. Maybe my github account is broken somehow.
zynthian_gui_midi_recorder.py (13.0 KB)
Yes, something has recently been changed in Zynthian which only affects the touch keypad and - even more strangely! - only the long press. That does not make any sense to me, but we will need to have a look at itā¦
1 Like
Sorry, i still canāt reproduce your issue. The MIDI recorder and player works perfectly for me.
If you donāt give a full report with all the details itās very difficult to fix your issue.
Regards,
Did you notice where @fussl posted a āworkingā zynthian_gui_midi_recorder.py above?
I do understand that more details on how to reproduce would still be nice to have but just thought you might have missed @fussl 's post.
This was not missed. That file rolls back the changes to the info display which is not causing an issue in a fully updated zynthian. Both @jofemodo and I have tried to reproduce this issue but without a proper bug report and associated data, logs, etc. we canāt help. Despite repeated requests, we are yet to receive a proper bug report. We try very hard to help users but they must also play their part.
2 Likes
Fan Control. I see pwm fan control in the change list for 2409.3 (I assume itās in the latest Oram staging as well). It does not seem to be working for me but Iām not sure what the exact syntax is. Iām using:
dtparam=cooling_fan=on
dtparam=fan_temp0=50000
dtparam=fan_temp0_hyst=5000
dtparam=fan_temp0_speed=255
in /boot/firmware/config.txt
Expecting to hear the fan clearly (it momentarily runs very fast at one point during boot) as my ambient is 68 deg. C. but itās very quiet. Any suggestions?
Harry
Strange. A short or bold press triggers the correct secondary CUIA action:
Jan 04 21:55:13 zynthian startx[3086]: DEBUG:zynthian_gui.zynswitch_short: Short Switch 4
Jan 04 21:55:13 zynthian startx[3086]: DEBUG:zynthian_gui.callable_ui_action: CUIA 'MENU' => None
Jan 04 21:55:13 zynthian startx[3086]: DEBUG:zynthian_gui.prune_screen_history: SCREEN HISTORY => ['audio_mixer', 'main_menu', 'admin']
Jan 04 21:55:13 zynthian startx[3086]: DEBUG:zynthian_gui.prune_screen_history: PRUNE 'main_menu' FROM SCREEN HISTORY => ['audio_mixer']
But a long press triggers this:
Jan 04 21:55:20 zynthian startx[3086]: ERROR:zynthian_gui.cuia_thread_task: CUIA 'unknown' failed with params: ['4', 'P']
Jan 04 21:55:20 zynthian startx[3086]: Traceback (most recent call last):
Jan 04 21:55:20 zynthian startx[3086]: File "/zynthian/zynthian-ui/zyngui/zynthian_gui.py", line 2360, in cuia_thread_task
Jan 04 21:55:20 zynthian startx[3086]: zpi = zynthian_gui_config.zynpot2switch.index(i)
Jan 04 21:55:20 zynthian startx[3086]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jan 04 21:55:20 zynthian startx[3086]: ValueError: 4 is not in list
There should be CUIA ZYNSWITCH 4,P triggered on press and CUIA ZYNSWITCH 4,R on the release of the switch-1 (zynswitch nr. 4]. The above mentioned error appears after the long press timeout (ca. 2s) of the switch passes, even if I donāt release the push at all. Why CUIA āunknownā and 4,P after the timer registers a long press? May it be connected to some changes in the press timer? Why does it only concernthe touch buttons and not the physical ones?
I agree that user updates of stable release should not be compiling software. This adds risk and substantial time to the update. There are some software that we create deb packages for and some others that we create binary packages and that is our aspiration. We should move towards a binary package process this year.
Hi @Baggypants - putting aside for the moment your request to get rid of compilation inside updates which @riban agreed with generally, Iām interested in Zynthian on smaller CPU configurations. A few questions:
1 - What model of Raspberry Pi are you using?
2 - Did you get past the problem by stopping the webconf service via systemd?
3 - Have you had other issues running with 1GiB ram?
Thanks!
Some considerations:
- We do not enable swap so any process that consumes more than the available physical memory will trigger an critical OOM error.
- The
/tmpdirectory is a very small tmpfs partition. This consumes some RAM which may aggravate the above point plus, many build processes use /tmp and may exhaust the available space and fail. - We put a work-around in place for RPi3 (possibly due to limited memory) failing to build patchage. We simply skip the build (which is suboptimal but was a quick fix for a blocking issue).
My opinion is that we describe the steps (maybe in the forum or wiki) of how to build packages to support the developers and intrepid adventurers but provide binary packages for normal users (whoever they may be!).
2 Likes
Hi, I have a quick question, The repository screen in webconf states that I use the āstableā repository, but I donāt see any update ?
Should i switch to the āoramā repository to be able to update ? is it safe to do that or should I erase my SD Card and re-install ?
If you are on the Oram release, stable release then you should get updates to the stable release when they are released. If there is not update availble indication in the UI then you are likely to be on the current latest stable. What does your webconf dashboard show for each repo?
That is wrong. What image did you start from?
I had my kit in April 24, I used the stable image at this time, should I change ?
Yes. The old stable version is no longer supported. You cannot update to the new version through software update. You need to flash a new image.
ok it makes sense. I made a backup, do you think the backup will work with tne new version ?