Skip to content

pragun/mouse-daw-controller

Repository files navigation

Note that this image only boots on RaspBerry Pi Gen 1,
not even on a Raspberry Pi Zero/ZeroW even though they 
have the same processor as Gen 1.

Definitions for this tgz.
This tgz contains three main folders:
buildroot-2019.02: This is the buildroot folder that if you run
'make' in, you would get a spanking new <buildroot-image>. Other than
the options selected in 'make menuconfig', there are several python
packages required. These packages did not come with buildroot, so were
added separately. These need to be enabled in config before 'making'
as follows:
echo 'BR2_PACKAGE_PYTHON_EVDEV=y' >> .config
echo 'BR2_PACKAGE_PYTHON_TABULATE=y' >> .config
echo 'BR2_PACKAGE_PYTHON_SERIAL=y' >> .config

The image that actually runs on the Rpi1 is the <slightly-modified-image>
with some minor, but very important modifications made to the <buildroot-image>.
These are the steps for the modifications.

This tgz, also contains DawController, which is the Python which you'd
need for the Step 2 in <steps-for-modifications>.

--#start: Steps for modifications

Step 1: DropBearSSHD
DropBear will create new ssh host keys everytime it boots up. The fix is to 
0. Set root password
1. Mount / as rw
2. Remove the symlinked /etc/dropbear
3. Create a normal folder /etc/dropbear
4. ssh into localhost, thereby forcing dropbear to create new keys
4(alt). Use dropbearkey to create a host key
5. Enjoy

Step 2:Git-Clone DawController from github or copy the DawController Repo Directly to there
1. git clone https://github.com/pragun/python-evdev-serial-relay
OR
2. copy the files to SD Card somehow

Step 2:Add DawController to Inittab
1. Add this to inittab 
tty1::respawn::/bin/sh -c "cd /root/dawcontroller; /usr/bin/python dawcontroller.py"
2. Move all the sysvinit stuff after dawcontroller

Step 3:Remove ttyAMA0 console from cmdline
To take out about one second of bootup time
1. Remove console on ttyAMA0 from cmdline.txt
2. To do this remount / as rw
3. mount /dev/mmcblk0p1 as /mnt/boot (might have to make that path)
4. nano cmdline.txt, and remove the two console parameters

Why do we do Step 2: DropBearSSHD?
DropBear recreates temp ssh_host_keys if it finds out that the
folder <> where it creates them is a soft-link to /tmp [which
it is by default in the buildroot output].
Also, we'd like to keep the root 'ro' mount to keep the 
SDCard from corrupting (which I'm sure adds to the problem somehow).

So, when you ssh into the image, the host keys keep changing
for every reboot, which is very frustrating. 

The solution was to login into the terminal with a keyboard+monitor
'rw' mount the root, remove the soft-link for the location
where DropBearSSh keeps keys, make it its own spanky-new-folder
and generate spanky-new-keys. After this, you can always
mount the root as 'ro', no problem.
--#end:why...
--#end:steps for modifications


Steps to recreate the BuildRoot Image for a RaspBerry Pi Gen 1.
The following steps can be taken to recreate the SD Card
--#start:steps to recreate SD Card
Steps.
1. First recreate the original partition table
sfdisk /dev/[sdb*] < sfdisk_dump

2. Untar the image files
tar -xvzf boot.img.tar.gz
tar -xvzf root.img.tar.gz

3. DD the boot to /dev/[sdb*1]
dd of=/dev/[sdb*1] if=boot.img

4. DD the root to /dev/[sdb*2]
dd of=/dev/sdb2 if=root.img

[*] is the device for the sdcard
--#end:steps to recreate SD Card

Login:
Username: root, password:root
Very un-imaginative


How does the Python code in DawController work?
--
It uses python-evdev to open /dev/input/eventX for the UtechSmart Venus
MMPORG Mouse. This mouse has two event device nodes, one for the keyboard
events that are generated by extra buttons, and the other one for regular
mouse events.
The python-evdev events are processed and sent over via a usb-serial-serial[*]
port to an Arduino, which enumerates itself as a
<midi-usb>, <usb-mouse>, <usb-keyboard> to a computer.
The Arduino program [inside UsbClient2ClientBridgeArduino] takes these
different commands received over <usb-serial-serial> and sends them as USB
messages over MIDI/USB HID Mouse/USB HID Keyboard/<USB What Have you>.
[Pretty neat eh?]

How is everything connected?

--
Glad you asked, the scheme of things goes as follows:

[Utech Mouse <-> USB Client
       <-> USB Host
       <-> Raspberry PI,
       	   which runs the
	   <slightly-modified-image, containing <dawcontroller>>
	   <-> USB To Serial
	   <-> Serial Port of Arduino
	   which runs the UsbClient2ClientBridgeArduino
	   	 <-> USb Client
		 <-> Usb Host of the Host PC
		     <-> Arduino MIDI Port
		     <-> Reaper
		     	 <-> MouseControllerPlugin]


ToDO:

-Fix folder/file permissions

About

Collection of Subprojects to allow a MMORPG mouse [such as UtechSmart Venus] to deeply control Reaper DAW.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors