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.


Messages - benh

Pages: [1] 2 3
1
Ah oops, ****t in my eyes :-)

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

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

4
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

5
Using pi-Stomp / Re: More questions about footswitches
« on: November 17, 2021, 04:24:56 PM »
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.

6
Building pi-Stomp / Re: Building a Pi-Rack
« on: November 12, 2021, 06:01:31 PM »
You are right :-( I got confused by the fact that the Zero had inputs and incorrectly assumed they all did

7
Building pi-Stomp / Re: Building a Pi-Rack
« on: November 10, 2021, 10:39:14 PM »
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.

8
Hacking pi-Stomp / increase memory availability
« on: November 08, 2021, 06:55:51 PM »
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]
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 ?

9
Hacking pi-Stomp / Re: pisound-btn coming back
« on: November 02, 2021, 05:43:05 PM »
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)

10
Hacking pi-Stomp / Re: pisound-btn coming back
« on: November 01, 2021, 08:15:23 PM »
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.

11
Hacking pi-Stomp / Re: Pre/Bypass switch color halo on LCD
« on: October 30, 2021, 06:39:27 AM »
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

12
Hacking pi-Stomp / Re: Pre/Bypass switch color halo on LCD
« on: October 30, 2021, 05:55:02 AM »
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.


13
Hacking pi-Stomp / Re: Pre/Bypass switch color halo on LCD
« on: October 29, 2021, 07:15:00 PM »
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 ?

14
Hacking pi-Stomp / Re: Pre/Bypass switch color halo on LCD
« on: October 28, 2021, 08:04:53 PM »
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.

15
Hacking pi-Stomp / Re: Any reason why we stick with an old lilv release ?
« on: October 28, 2021, 07:22:20 PM »
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 ?

Pages: [1] 2 3