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 03:10:17 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/langolierz/r_e_c_u_r

Browse Source
This commit is contained in:
langolierz
2018-04-20 06:55:14 +00:00
parent f14097ef60 3d0aebbe9c
commit e787b263fe
2 changed files with 10 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -55,6 +55,10 @@ other things to try is learning how to use abelton as a midi controller and see
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?
i ended up trying cc with some camera paramters. there are plenty more interesting examples of continuous control there. it works well , but it seems like running the methods on every change when they are sequenced / coming in consistantly is a bit much for recur to respond in real time.
one idea to reduce this is to only process a incoming cc message if it is outside a range for that channel - ie only action on every 3rd cc change for each control for example. - this works well. updating every 5 cc values had no lag under heavy use but looks quite jumpy. step size of 2 looks smooth but can lag quite a lot. i have it set to 4 atm but can revist when other features are under cv control etc.

10
dotfiles/investigating_live_video_input.md
View File

@@ -78,17 +78,19 @@ following the picamera docs , i will/have :
- trying some simple python commands with camera
- write some experimental recur code
first hitch : i enabled the camera in the raspi-config , but it seems like the switching screens driver overrides this , so will have to update this too !
first hitch : i enabled the camera in the raspi-config , but it seems like the switching screens driver overrides this , ~~so will have to update this too !~~ fixed this by adding a line to the config.txt
besides that the preview / different parameters and effects work as expected. next step is to try recording something , converting it to mp4 and playing back on omxplayer.
i have installed `sudo apt-get install gpac` and am using `subprocess.Popen` to run the `MP4Box` command from inside python. this way i can poll back into it and map the video only when its finished converting to stop blocking in the meantime. i also updated the display to show when the camera is previewing and recording. this all worked smoother than i expected.
i also made a (suprizingly small) change to the browser to show the pi's videos folder next to the external devices. this will be useful for using the recordings saved and for copying files onto recurs disk.
i also made a (suprizingly small) change to the browser to show the pi's videos folder next to the external devices. this will be useful for using the recordings saved and for copying files onto recurs disk. (the copying feature has been depriotised since it can be done manually with mouse/keyboard and could be risky / might want a confermation window ...)
another thing still to think about is how to protect from overfilling the sd card / external storage.
another thing still to think about is how to protect from overfilling the sd card / external storage.
- i have done this by checking before starting to record and every 10 seconds during recording if the disk space is under 10mb in which case it warns and stops the recording.
also displaying info when camera is not attached and catching other types of errors...
also displaying info when camera is not attached and catching other types of errors...
- this will be handled by bool enabling the capture. if it can not detect the camera it will not allow this to be enabled.
[picamera]: http://picamera.readthedocs.io/en/release-1.0/api.html
[faq]: https://picamera.readthedocs.io/en/release-1.13/faq.html