Messages

Ah oops, ****t in my eyes :-)

You might have to stop jack as well to get audio in test mode

Hopefully this fixes it: https://github.com/TreeFallSound/pi-stomp/pull/28 (not very well tested as I don't have a v1)

I broke something ? =P

I don't see anything "obvious" looking at the test code, I'll try to run a variant of it adapted to "core" later

From an implementation perspective, I wonder if it's worth splitting the footswitch object which sends internal "events" (up/down) from the object that translates these into actions/MIDI. This would allow to have such action objects source multiple footswitches or example.

There's a bit of a trick here. To handle chords, we would need the action/policy object to receive both foot down and foot up events. Those aren't really synchronized so we would need to keep track that a given pair are both down for at least a minimum amount of time.

However, currently, we only really send events on "up" due to how we do the long vs short handling.

The leads to a couple of question:

- What should be the behaviour of "chords" if one of the two switches does a short press and the other one a long press.
- Is the current behaviour that great ? ie, the user might expect an action to happen as soon as a switch is pressed, not when it's released, though that would make dealing with long press difficult

The least disruptive way I can think of right now to implement chords would be to move the MIDI message logic out of the footswitch to the handler (or a separate object), and have the footswitch send event tuples (event, timestamp) to it, including "down" events.

That way, on an "up" event on a switch that is part of a chord, the handler can check if the other switch is down, and treat that as a chord. Otherwise, treat that as a normal singleton event.

We could move that to a separate object "event mapper", as well rather than the handler.

You are right :-( I got confused by the fact that the Zero had inputs and incorrectly assumed they all did

I don't know if you guys saw it but there's also https://www.raspberrypi.com/products/iqaudio-dac-pro/ which is rather cheap and has differentials in/out

It's apparently meant to go with a separate XLR board which is sadly nowhere to be found.

So I did a quick experiment... it appears that by default, the RPi3 bootloader reserves 64MB for the GPU.

If like me (and probably most pi-stomp users), you don't use HDMI, this is a waste. Adding this to config.txt:

Code Select Expand

gpu_mem=16

Brings it down to 16MB and thus frees an extra 48MB of memory for use by pi-stomp. We aren't running short
today with typical pedal boards but the more the kernel has, the less it's likely to do weird things in the back
ground to reclaim some which tend to result in extra latencies.

Randall, is this something we should add to config.txt in the setup scripts ?

Right. So if/when Blokas takes my change, we'll be able to remove the pisound-btn package and keep patchbox-wifi, which should solve this (and the pisound-btn package updates re-starting its service)

See my updates here: https://community.blokas.io/t/split-wifi-hotspot-config-from-pisound-btn-package/3391/7 on moving the wifi hotspot bits out of pisound-btn to a new patchbox-wifi, so we can properly remove pisound-btn

Randy, is there anything else in pisound-btn that we might depend on ? Do we use the BT stuff ? I can move it too later if needed.

Also not sure you noticed, but the test mode does more interesting things if jackd isn't running... ie, I'm currently using Alsa directly so it conflicts

BTW. You mentioned you had problems using interrupts before. I don't know whether you are aware or not, but I believe RPi GPIO uses a separate thread to handle GPIO interrupts, and the callbacks are called from the context of that thread. This means that unless you are careful about thread synchronization, bad things can happen. This is why I implemented it the way I did where the callback only handles an atomic counter which is read from the normal polling loop.

In fact I think we have a potential problem with the footswitch for that reason. "toggle" should probably just set a flag that we read from the main poller.

If you want faster "response" than the 10ms loop, we could replace the sleep there with something we can wake up from those callbacks. Either that or use a global lock.

The stuff in the hackery branch will be split into separate PRs yes. As for the existing PR with the encoder interrupts & setup script fix, do you want me to split that one into two separate PRs ?

Thanks. Yes of course, it does need testing :-) It's in the same branch as my "test" backend, so feel free to look at both when you have a chance. I rebase that branch regularly (it's a "work in progress" pile), I've added quite a few things to the test backend since last I mentioned it.

The main difference with v1 is what ? LCD ? My change to lcdcolor.py might need a matching change there then... a quick look indicates lcdgfx.py probably needs some work, maybe more.

Out of curiosity as I only had a cursory glance so far... what does 'MODEP' add to the moddevices original stuff ?

So far, I looked at Blokas repo, and mostly I see debian packaging around old versions of moddevices components, is there more ? Is there actual code / logic I'm missing or it's just a convenient way of packaging moddevices components (mod-host, mod-ui...) on debian based distros ?