pi-stomp ui sometimes not showing all plugins

[dormir]

heya again,

i've been having this issue from time to time that some plugins are not shown on the pistomp ui, despite them being active and visible in the mod-ui. i have not yet really seen a pattern to which plugin is shown and which is not. ps-journal:

Code Select Expand

-- Logs begin at Mon 2022-03-21 14:27:07 GMT. --
Mar 21 14:27:13 greytree systemd[1]: mod-ala-pi-stomp.service: Main process exited, code=killed, status=15/TERM
Mar 21 14:27:13 greytree systemd[1]: mod-ala-pi-stomp.service: Succeeded.
Mar 21 14:27:13 greytree systemd[1]: Stopped MOD-ALA-PI-STOMP.
Mar 21 14:27:13 greytree systemd[1]: Started MOD-ALA-PI-STOMP.
Mar 21 14:27:17 greytree python3[469]: ERROR:root:Cannot connect to mod-host
Mar 21 14:27:17 greytree systemd[1]: mod-ala-pi-stomp.service: Succeeded.
Mar 21 14:27:19 greytree systemd[1]: mod-ala-pi-stomp.service: Service RestartSec=2s expired, scheduling restart.
Mar 21 14:27:19 greytree systemd[1]: mod-ala-pi-stomp.service: Scheduled restart job, restart counter is at 1.
Mar 21 14:27:19 greytree systemd[1]: Stopped MOD-ALA-PI-STOMP.
Mar 21 14:27:19 greytree systemd[1]: Started MOD-ALA-PI-STOMP.


not sure what that python3 error refers to, could this be related?

best,
dormir

ps: attached an example configuration where this occurred

EDIT://

it seems to be that plugins that have stompswitch-actions attached to them are those that are not shown as plugins on the ui. is this expected behaviour? to me it still seems like a bug, because i now cannot disable a plugin that has for example attaced a stompswitch to its tap tempo. trying to wrap my head around the files in .../modalapi/ but i've not yet found where this might happen.

[Randall (Admin)]

That error is expect when MOD-ALA-PI-STOMP is trying to start but mod-host hasn't finished starting yet.  It'll keep restarting until mod-host is up.  So generally not a problem, unless mod-host is not starting.  That's usually because of jack not being happy about the audio setup.

And yes, I think you answered your own question regarding the "missing plugins".  When a plugin has a control assigned to a pi-Stomp footswitch, it won't be shown in the main plugin grid because it'll be shown below as a footswitch.  The thought was that it was confusing to have it shown in duplicate.  However, that somewhat presupposes that footswitches are only used for bypassing, and you've pointed out, they can be used for other two-state inputs like Tap tempo.

So we could display every plugin in the grid, regardless of controller assignments, and the footswitch LCD objects would become controls only.  Still toggle-able via the encoder, but no deep-edit on long-press, cuz it's a control not a plugin.

I'm happy with that.  All that is really just how they are displayed on the LCD.  Unfortunately, as it is, because of the prior thinking, the footswitch LCD objects are kindof a special case of plugin (identified by the 'has_footswitch' attribute of a plugin object and referred to as "bound plugins").  Showing all plugins in the grid is an easy fix.  Getting the click/toggle behavior right is the tricky bit.  If a plugin has a bypass function assigned to a footswitch, toggling either via the footswitch or the encoder, needs to change the bypass indicator for BOTH LCD objects.

Thanks for pointing out that design flaw.   

I've started prototyping a fix.  Feel free to file in issue in github if you'd like to track it.

[dormir]

So we could display every plugin in the grid, regardless of controller assignments, and the footswitch LCD objects would become controls only.  Still toggle-able via the encoder, but no deep-edit on long-press, cuz it's a control not a plugin.

so this refers then to the footswitch control only, yes? all the other "bound plugins" would still be deep-editable on long-press? then this would be absolutely adequate for me, don't need a perfectly elegant solution, just something that works and i'm happy.

i've posted the issue on the github.

best,
dormir