News:

SMF - Just Installed!

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - benh

#16
So the end result is in https://github.com/ozbenh/pi-stomp/commits/benh-hackery

(along with the rest of my experimental stuff)

footswitch.set_value() already existed, so the change wasn't super invasive. The behaviour of non-relay midi toggles shouldn't change. The changes should (hopefully only) be
that for the relay switch, halo and LED (if any) are in sync and match footswitch.enabled.

#17
Digging more there are issues with my approach... when the switch isn't associated with presets, it starts toggling the halo on short stomps which doesn't reflect anything.

I feel the code in those areas has ... evolved a bit :-) I need a bit more time to untangle. I am not fan of how the LED is controlled by calls to set_led() without any relation to the "enabled" state of the switch. The disconnect between the LED and the displayed halo is what bugs me. I would think that in absence of physical LEDs the halos should behave like the physical LEDs do.

So I wonder whether I could try (if you don't object) to rework things in that area a bit such that:

- The LCD halo and the LED are always in the same state and reflect footswitch.enabled

- Some logic is added so that footswitch.enabled doesn't "toggle" for a non-plugin switch which has no MIDI message and no preset, such that the leftmost switch "enabled" will effectively only toggle when doing long-presses for bypass control.

I will need more time to get my head around the various code path involved and make sure I can produce the above without breaking stuff, but I would appreciate your opinion as to whether this is an approach you would accept.

I think fundamentally this will turn into anything calling set_led from outside footswitch.py today turns into a new set_state which actually changes the enabled state. set_led becomes private. Then I'll add logic to figure out when a switch should toggle, ie prevent toggles when not associated with a midi control or a plugin.
#18
So unless I misunderstand something or have a weird behaviour... today, a switch that isn't associated with a plugin (Pre+/bypass or a MIDI only switch) will have its halo on the LCD always "grey" (color_plugin_bypassed) regardless of the state of the switch and regardless of the color configured in the .yml.

The physical LED halo (I think from reading the code as I haven't wired those to the GPIOs up yet) however will follow the switch state.

This patch makes those non-plugin switches halo on the "LCD" follow the state of the switch just like the GPIO halo (if any) instead of  just being "always grey".  For this to work, a color needs to be specified in the config, so I suppose I could improve the patch to test for that and stick to the existing behaviour when not.

In the case of the Pre+/bypass footswitch, yes, there is already an indication of the bypass state via the little power icon, but this is not nearly as visible (at least for me) when standing up near the pedal, and I feel having the switch halo reflect the switch state is a more "expected" behaviour from a pedal...

But maybe I'm missing something here.
#19
Hacking pi-Stomp / Pre/Bypass switch color halo on LCD
October 28, 2021, 06:17:33 AM
Hi !

Any opinion on the following patch ? Ie makes the halo of the Pre/Bypass switch on the LCD (leftmost by default) follow the corresponding LED if any and bypass state, which ... I prefer :-) IE, I actually get some color there !

I'll add it to a future pull request if you don't object.

diff --git a/pistomp/lcdbase.py b/pistomp/lcdbase.py
index cf56f31..7bb4d99 100755
--- a/pistomp/lcdbase.py
+++ b/pistomp/lcdbase.py
@@ -188,6 +188,8 @@ class Lcdbase(abstract_lcd.Lcd):
                 continue
             f = fss[fs_id]
             color = self.valid_color(f.lcd_color)
+            if self.color_plugin_bypassed is not None and not f.enabled:
+                color = self.color_plugin_bypassed
             label = "" if f.display_label is None else f.display_label
             x = self.footswitch_pitch[len(fss)] * fs_id
             self.draw_plugin(zone, x, 0, label, self.footswitch_width, False, None, True, color)
diff --git a/pistomp/lcdcolor.py b/pistomp/lcdcolor.py
index 1c23b06..9955bda 100755
--- a/pistomp/lcdcolor.py
+++ b/pistomp/lcdcolor.py
@@ -254,7 +254,7 @@ class Lcdcolor(lcdbase.Lcdbase):
         if is_footswitch:
             if plugin:
                 plugin.lcd_xyz = (xy1, xy2, zone)
-            c = self.color_plugin_bypassed if plugin is None or plugin.is_bypassed() else color
+            c = self.color_plugin_bypassed if plugin is not None and plugin.is_bypassed() else color
             self.draw_footswitch(xy1, xy2, zone, text, c)
         elif plugin:
             plugin.lcd_xyz = (xy1, xy2, zone)
#20
Hacking pi-Stomp / Re: pisound-btn coming back
October 27, 2021, 10:17:18 PM
So sadly, simply not running pisound-btn (I have it removed locally) does NOT fix the encoder. It really needs to be turned very slowly so lengthen the pulses for it to work in polling mode with the current 10ms polling. Works fine with the interrupts patch
#21
Hacking pi-Stomp / Re: pisound-btn coming back
October 27, 2021, 09:01:17 PM
Yes mask should work ... except the .deb package install script turns it back on :-)
#22
Hacking pi-Stomp / Re: pisound-btn coming back
October 27, 2021, 07:55:22 PM
So Blokas is happy for me to split the hostap config to a separate package. I'll work on that when I get a chance
#23
Hacking pi-Stomp / Re: Taking out ttymidi
October 27, 2021, 07:54:43 PM
Yes I tend to side with you on that one, I'll keep the install and just skip the enabling of the service by default unless specified
#24
Hacking pi-Stomp / Taking out ttymidi
October 27, 2021, 12:57:05 AM
Hi !

I noticed ttymidi is eating CPU in the background on my system where I didn't wire any MIDI ports to the UART.

I'll send a PR making the installation of the ttymidi related components optional in setup.sh (default on or off ? for now it's default without and -m adds midi but I can change it before I submit). That said, before I do that, am I missing anything in pistomp itself that relies on ttymidi being present ? I didn't notice anything on my side but I could have missed something.

Another option could be to always install it but make the enabling of the service optional.
#25
Hacking pi-Stomp / pisound-btn coming back
October 27, 2021, 12:19:48 AM
Hi !

I noticed that pisound-btn was running and eating up quite a bit of CPU in fact, on what is a reasonably fresh re-install. I suspect and apt-get update caused the service to be restarted.

I wonder if it's worth taking it out completely from setup.sh, ie, apt-get remove pisound-btn.

The consequences as far as I can tell will be:

- It takes out these packages: modep-btn-scripts modep-ctl-scripts pisound-btn pisound-ctl pisound-ctl-scripts-common pisound-ctl-scripts-puredata
  pisound-ctl-scripts-system. Do we have anything that relies on any of these ? A bit of grepping around didn't show anything obvious but I'm not
  quite an expert in pi-Stomp yet :-) I took them out here, rebooted and things seem to still function.

- The hostapd configuration (hotspot mode) is part of the pisound-btn debian package, including the dhcp config and the systemd service. I don't know
   if we can convince Blokas to split these into a separate debian package, I'll ask, but in the meantime, we could just ship our own versions of these
   in pi-stomp/setup and copy them over.

Thoughts ?

#26
That's awesome. I did ask Blokas on their forums, the respond was they would gladly take pull requests for such updates
#27
Building pi-Stomp / Re: Encoder issue on first build
October 25, 2021, 06:10:31 PM
So I just randomly threw things at a board that idles at about 75% CPU.. (using the RT kernel). With my interrupt patch for the encoder, If I go crazy with the encoder, I see the CPU usage raise to about 83% but no XRUNs and everything is responsive.
#28
Yup, I went looking a bit this morning, it looks like most of blokas "stuff" is ... stale (except midihub). They are probably too busy.

There is a guy who has a script to get pistomp to 1.10 .. but as you said it's not as "proper"...

Another option would be to take time to actually do a PR for Blokas to consider. I don't know if I"ll have time for any of that myself in the near future, tbh, i'd rather spend my time building a whole 64-bit pistomp env. with everything rebuild from scratch for ARMv8 with NEON instructions and auto-vectorisation using a more recent gcc... :)
#29
Building pi-Stomp / Re: Encoder issue on first build
October 25, 2021, 03:57:10 PM
Right, I will do some more testing but my time is limited at the moment... Also at some point I want to also play with moving it all to 64-bit, using a newer MOD etc.. :-) I might end up having to build a second  one just to toy with while I give this one to my son :)

That said, could your original interrupt problems relate to the old issues you had with the screen before numpy gave it a boost ?

One option could be to have both modes supported (polling and interrupts) via a config option, so users who have problems can tweak. I think the existing sample rate is just too slow for some encoders out there, they aren't broken per-se. That's actually why I moved the core debouncing code to a separate _process_gpios() so it can still be called from read_rotary() if we want to, easy change. I'm a bit sad about YAML though :-) JSON would have probably been a bit nicer and allowed maybe to avoid subclasses completely by having the entire HW def in a config files. I could look into it but ... time .. :-)

As for core pinning, it's a bit nastier than I originally thought because Broadcom was stupid enough not to provide a way to target interrupts. So all IRQs end up on core 0, always. That includes the audio DMA interrupts which are the critical ones.

That said I don't think the GPIO interrupts are enough to cause problem here, there isn't much done in a GPIO irq handler. It's more storate/SD that gets in the way. I suspect at this point the RT kernel will help more than any other game of CPU pinning. That said, I need to dig more at some point into the hardware, if we can make the audio IRQs FIQs (thus preempt other interrupts), we could have a fast path for them or even shoot an IPI to the core dedicated to audio processing and handle them there, with hopefully not much extra latency as a result.

#30
Latest is 0.24.12...