Custom Made FX Mute Foot Switch (TCP/IP)

[[XAP]BobParticipant]

You can get USB/Ethernet hubs for OTG ports though, that could provide both options easily enough.

[ZueriParticipant]

HI guys
I just ordered the components to finally build my own foot switch. I just wait for Raspi3 to arrive. I also plan to implement some new features and make it configurable.

@Doc: I took the freedom an created a Github project using your source (https://github.com/chriszuercher/quPy). Hope this is OK. If not let me know. I will add my changes there as I think it is an easy why to contribute to a project.

I keep you updated on my progress. And of course I invite everyboy to contribute to the Github project (as long as it is ok for Doc).

[KeefParticipant]

Bob, thanks for that and the hub seems like a nice inexpensive solution as well!

Zueri, welcome on board and Githib is a great idea – couple of things that might ease you into the code and save you a bit of time when you get your Pi 3:

config.py – needs the correct IP address for your QU desk – you can also edit mute group numbers vs buttons/leds on the footswitch in that file.

quPy.sh – needs the correct path info to files on your Pi

startup.sh – needed some attention on correct path as well – not sure why, but it’s maybe the way I have Linux set up on the Pi or something to do with the ‘dirname’ command?

Anyway, let us all know how you get on when your Pi arrives.

[DocDocDocDocParticipant]

@zueri: Well, since the stuff is open source, I can’t keep you from continuing anyways. 😉 Beware that there is code that is not really open source (it says so in the headers/comments of those files), so you need a solution for that on the long run.

@Keef: config.py indeed needs the IP address. This could be improved by a quick scan on the local subnet which should work for almost all cases.

The dirname thing: This is nothing more than a bash command that finds the name of the current directory. It ensures that from which working directory ever you start the script, it knows where it lives itself.

If I remember correctly, I used quPy.sh as part of the PyCore Linux system init structure. (I’d need to log into my foot switch to check.) Basically, it attaches STDIN of start.sh to a FIFO, so that it later can send a shutdown command via that FIFO. startup.sh redirects it output to the system log.

The purpose of this: a) getting the foot switch software up and running on system start b) being able to later on log into your foot switch and monitor the debug output of the code on via the system log.

I think quPy.sh does not use the dirname trick because I symlinked it from the system init directory structure of piCore Linux, so dirname would think the script lives in some other place.

During development, you would simply run python ./App.py as root.

@zueri: I am not a regular user of Github. Could we continue this rather detailed technical discussion there? If so, please make a start and feel free to copy this forum post here to an appropriate place.

[ZueriParticipant]

I created a first wiki page with some of the topics here and created the first issues for missing features. Feel free to add commentts to the issues or other issues if there are some missing features.

I’m also new to Github in the role of project owner so I just try to do my best 😉

[KeefParticipant]

@zueri – nice work. Let us know how you get on with your Pi 3.

@Doc – one quick question on the code – what is the shutdown procedure when running the foot switch headless?

[DocDocDocDocParticipant]

Mh, so there is a “proper” shutdown routine via the quPy.sh script. However, people won’t do that with a foot switch. As described in my blog post about the project, I used piCore Linux (the SSH variant, that comes without X11/graphics). One hassle but also but advantage of piCore is that it never stores stuff to the SD card. The hassle is that things need to be unpacked/loaded from the SD card on startup (which is slow) and that this probably needs quite a bit of RAM since all data end up in RAM disks. The huge advantage, however, is that it never performs any write access to the SD card, unless you issue a special command. Resulting in: a) damage of the SD card is unlikely, since SD cards get “spent” mostly on write access b) you don’t need a proper shutdown because the system cannot leave behind corrupted file systems (since it never leaves behind anything anyways) – simply pull the power and you’re safe.

[DocDocDocDocParticipant]

Actually it would be cool to have a “distro” for the foot switch based in piCore. Something you simply copy to a SD card using dd on the command line and then let it rumble. I think this would make it easier for many people and enlarge the user base. However, there are 2 things to solve: 1) generating a unique SSH key on first startup 2) getting one user account set up properly (or have a default user with default password, which is… well, a backdoor in many routers, still 😉 Mh could work if the user is forced to change the password on first login.

[RingoParticipant]

Hi,

I realise this is an older post but by the looks of it you guys know your stuff and will know if this can be done.

So I am wondering if the QU-PAD and QU-You can be made MIDI compatible so that it could then be controlled via something like the iRig Blueboard ??

I’m no expert on this kind of stuff but it looks like it works well with other midi compatible apps. It would be really cool if you could control mute on/off for effects, and even use an expression pedal to control volume and other parameters inside QU-PAD and QU-You.

Thoughts??

[[XAP]BobParticipant]

I’ll run up the code for first boot new SSH key.
No serious risk in terms of default password, it’s not on a public access network.

[RingoParticipant]

Okay….. Way over my head but let us know how it goes.

[DocDocDocDocParticipant]

I have never seen the iRig Blue Board in real life. But from the description, I read: You need an app or software for iOS or OS X that converts the button presses on the board into MIDI messages.

OK, you cannot control the Qu Apps this way. But you could control a Qu console. In this case, you would need to “virtually wire” the Blue Board App with the Qu console. I think the Qu provides a MIDI driver over the network for OS X, which means on OS X you should have a) the Blue Board as virtual MIDI connetor and b) the Qu console as virtual MIDI connector. And hopefully some means of actually connecting them. I do not use OS X so I can’t tell.

It is also likely to work via the USB/MIDI of the Qu console. Since the Qu is class compliant, it might show up as MIDI device in iOS when connected via the camera kit (for old iOS devices, newer ones I don’t have). However, the “virtual wiring” on Mac products again…

And then of course you’d have to teach the Blue Board App all the MIDI commands.

Just my educated guesses/5¢.

Best
Doc

[RingoParticipant]

Or theres this….https://www.morningstarfx.com/

[[XAP]BobParticipant]

Connect that to an android device with MixDroid and you have a solution.

[KeefParticipant]

Good post and thanks to the OP for starting this discussion.

Just another possibility for footswitch control but would probably need comment from Harry or Nicola from A&H on integration with QU-Pad or QU-Control on an iOS device.

Use the iRig BlueBoard:

https://www.ikmultimedia.com/products/irigblueboard/

with the Midiflow app:

https://itunes.apple.com/gb/app/midiflow-midi-router-processor/id879915554?mt=8

to send midi commands to QU-Pad and/or QU-Control apps to control mutes, etc. I’m not familiar with the way these apps communicate/work at the coding level, hence the need for comment from A&H.

Anyway, just a thought!

[Author]

Posts