eessppeelllloo/r_e_c_u_r
1
0
Fork 0
mirror of https://github.com/cyberboy666/r_e_c_u_r.git synced 2025-12-12 11:20:15 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update investigating-midi-support.md

Browse Source
This commit is contained in:
langolierz
2018-04-17 16:41:03 +12:00
committed by GitHub
parent 5d1c2ec7a3
commit 93dd55e0f3
1 changed files with 22 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
dotfiles/investigating-midi-support.md
View File

@@ -32,6 +32,28 @@ i have decided to try using the [mido] python package for responding to midi inp
besides the obvious triggering of clips and controlling parameters, it has also been suggested that the recur could 'sync' to incoming [midi-clock] messages. these communicate a master tempo by sending 24 pulses (clock messages) every quarter note. this could be useful in play modes where the video changes every bar of music (counting pulses from a start message) or even to approximate slowing/speeding of a clip if the speed control of omx would handle it
### getting started with mido
i install mido and rtmidi for backend : `pip3 install mido python-rtmidi`,
i called `mido.get_input_names()` and searched the results for the first containing the substring `20:0` (this is the port my devices came up as - will need to investigate further why this is and if it will be the case for all external usb midi devices)
from here i called a polling meathod that reads the next message coming from that port and if there is one will call into the mapping function (from json file)
i created a midi_action.json mapping in the same format as the key press but with `type (value)` as the keys. eg `note_on 70` is an example, `clock` is another. for now i have mapped exactly the same as with the key presses
this works perfectly for pressing keys on the deluge and seeing the corrosonding action on recur. even when pressing keys with the sequencer running (lots of clock messages being sent) it still responds quickly and consistantly. however when triggering the same notes from the sequencer, it seems to drop lots on the notes : usaully only picking up either note_on or note_off , sometimes both and sometimes neither.
I tried changing the way recur handles the incoming messages (working through a list of unprocessed messages rather than one at a time) , but this didnt help - its not a problem of response time as can be shown by pressing keys with sequencer on. even looking at the raw input to the port on `aseqdump -p 20` i can see some messages missing. i updated the deluge firmware to a stable release but no changes.
however when i tried turning off the clock messages from the deluge , the sequencer messages started coming through clearly ! and it syncs up nicely... how strange.
### futher clock debugging
other things to try is learning how to use abelton as a midi controller and see whether it works there with/without clock messages. could also try other gear that can output midi / controllers with recur and try deluge with other computer / gear
### experimenting with cc
besides figuring out whats up with the incoming clock signal , another thing to experiment with is using a cc knob to control parameters in recur. there is nothing pressing i want for this but could try it with : fades , speed? , length of seeks , seeking?