mirror of
https://github.com/cyberboy666/r_e_c_u_r.git
synced 2025-12-05 16:00:06 +01:00
removing docs from repo - and put in wiki
This commit is contained in:
Tim Caldwell
@@ -1,101 +0,0 @@
|
||||
# beta access , notes and limitations of v2
|
||||
|
||||
while at signal culture the concept of what recur could do underwent a large enough change that it will likely become v2 once im ready to release it offically in this form. however i dont know how long that will take and want it to be possible for current users to try / test / play with the new stuff before then. (warts and all !)
|
||||
|
||||
you can read the highlevel overview / roadmap of what v2 is about in the [signal_culture_and_future_plans] doc.
|
||||
|
||||
this doc will explain how to try out and use the new features, and also keep track of the known issues and my thoughts/ plans to fix them. if any testers find additional bugs i will keep track of them here.
|
||||
|
||||
## flashing the new img.
|
||||
|
||||
i have created and uploaded the new [image] you can download it from here and flash to your sd card in the same way as before (note in case anyone was using a 4gg sd card before, you will need more than that now im pretty sure)
|
||||
|
||||
## receiving updates
|
||||
|
||||
with this new img recur should be exactly as usable as before in the default configuration, with the options to enable some new features if you want. (incase you are on the fence about trying it).
|
||||
|
||||
- a new option in the OTHER subsetting is availabe called UPDATE_CODE. this means if you are on a network (either plug in ethenet cable or connect to your home wifi) you can get any updates/bugfixes i push up. i will try to push fixes for any critical bugs asap so pls help me find em lol
|
||||
|
||||
## c_a_p_t_u_r
|
||||
|
||||
piCaptureSd1 compatibility is now built in (this sets the sensor mode, autowhite balance and exposure to optimise picaptures input )to captur, you can now see a 'TYPE' option in capture subsetting which allows to switch between these settings and standard piCamera settings. also included in same menu is PICAPTURE_INPUT , which should allow software switching between different sources on the card.
|
||||
|
||||
FUTURE NOTE: if i or anyone ever wants to try with a piCaptureHd1 (or that other hdmi-to-pi board floating around) custom settings for these could be added here...
|
||||
|
||||
~~also keen to try with usb-web-cam / cheep capture cards for lofi/locost options~~ usb capture is now supported
|
||||
|
||||
## i_n_c_u_r
|
||||
|
||||
### hardware
|
||||
|
||||
the program is now set up to read inputs from more external devices. i have been working with a little circuit that connects to the gpio pins. i hope to have a little pcb that can be attached as an option. more info about this will be available soon. here is the [schematic] i am using. it is just a standard midi-serial to RX , plus a MCP3008 a2d taking 4 linear pots and 4 (0-5v) cv inputs.
|
||||
|
||||
the GPIO pins i am using are:
|
||||
|
||||
- 2 -> 5v
|
||||
- 6 -> GND
|
||||
- 10 -> RX
|
||||
- 17 -> 3v3
|
||||
- 35 -> DOUT
|
||||
- 36 -> CS
|
||||
- 38 -> DIN
|
||||
- 40 -> CLK
|
||||
|
||||
NOTE: any of the 5v,3v3, GND could be used, (and in fact any 4 pins for SPI too with a small code change since its using softwareSPI right now. those pins are also possible with hardwareSPI although i couldnt get this working with the lcd-driver - might investigate this further if the performance over spi becomes the bottle neck )
|
||||
|
||||
i will write more about how to wire this up when/if a pcb is ready. because of the lcd-screen/picapture using the gpio header, i decided the easiest way to access the pins was to solder wires from a IDE cable onto the bottom of the pi board. this wasnt so difficult even with my limited soldering skills... and then the IDE socket can be plugged in and out of the incur circuit as desired.
|
||||
|
||||
### software
|
||||
|
||||
reading from the a2d can be enabled with the ANALOG_INPUT option in the OTHER subsetting. these mappings are made in the [analog_action_mapping.json], i would only have this on when using it as it will increase load etc. the response speed can be tweaked a bit from analog_input.py , although the current python architecure does limit how fast these read. moving this to openframeworks is one way i am thinking about to improve this.
|
||||
|
||||
din-midi input over serial is now also an option. in the MIDI subsetting the INPUT option now cycles through usb , serial and disabled. again i would only have these listening if midi was being used.
|
||||
|
||||
another new MIDI option is called CYCLE_MIDI_PORT - this is kind of vague, but i noticed when attaching a midi controller over usb (a broken Edirol PCR50 for what its worth..) that three midi ports were created but only one was receiving the data from controller , and it wasnt the port recur listened to by default. if you are trying to use a usb-midi device thats connecting but not working , it is worth trying CYCLE_MIDI_PORT and see if that helps ....
|
||||
|
||||
## c_o_n_j_u_r
|
||||
|
||||
this is the biggest and least stable addition to vanilla recur. basically i wanted to experiment with replacing the OMXPLAYER backend for loading and controlling video playback with OPENFRAMEWORKS videoplayers (talking over OSC).
|
||||
|
||||
the existing stable OMXPLAYER backend option is still available and is the default. if you want to try c_o_n_j_u_r you will need to switch backends in the OTHER subsetting.
|
||||
|
||||
once in this mode, you can try loading and switching a sample just as before (ie press `0` , watch for `NEXT LOADED` then hit `->`),
|
||||
|
||||
~~if the video is a box in bottom left corner OF thinks its in dev mode , selecting the OF_SCREEN_SIZE option in OTHER subsetting a few times should fix this (i just need python to tell of when dev mode is changing - should fix soon)~~ <- this should be fixed now
|
||||
|
||||
most of the usual sampling functions should work same as before. loading , switching , pausing , sublooping, rand-start etc. at this point some of the VIDEO settings such as BACKGROUND_COLOUR and SCREEN_MODE do not work here. (it is possible to implement these but low prioty for me rn...)
|
||||
|
||||
it seems like sampling video through openframeworks is more demanding on cpu than omxplayer. from running some tests, my SD videos through composite out run fine but even 720 starts to lag (unlike omxplayer which either plays full fps or nothing , of can slow right down when its struggling ). __i would recommend using this for SD video only__
|
||||
|
||||
also, i have noticed occasionally the openframeworks app will crash (usually with a specific video file/action on this file it cant handle.) when this happens the output will freeze.. ~~this is a critical error i want to priotize reducing / handling more gracefully. if you can reproduce this let me know how, for now a soft reset will restart another working version of OF-app , however the crashed one will still be in memory which is not ideal. the only way to stop it i know now is killing the process in task manager , or a hard reset. im sure theres other ways so will be working on improving this !~~ this shouldnt happen so much now but if it does the `reset openframeworks` option should fix
|
||||
|
||||
### shaders
|
||||
|
||||
cycling `DSPY` now also has a `SHADERS` mode. this gives a similar folder_nav view as BROWSER but is used for selecting glsl-fragment-shader files (usaully .frag). entering (`square`) on a shader file loads it (first line of DSPLY). the loaded shader can now be toggled on and off by pressing `FN + 6`
|
||||
|
||||
if a shader is marked '0in' it will replace currently playing sample (similar to captur's preview), if it is marked 'pro' the sample will become processed through the shader.
|
||||
|
||||
if a shader has parameters that can be set by recur these will be displayed next to the loaded shaders name and type in SHADER display mode. (eg `x0:00 x1:78`). params are best controlled with continuos inputs (cv/pots/midi-cc) but can also be set on numpad:
|
||||
|
||||
- entering (`square`) on the loaded shader will change the CONTROL_MODE to SHADER_PARAM. from here a param should appear highlighted. the value of param is changed with `<` and `>` , the selected param changed with `[` and `]` and the SHADER_PARAM mode is exited with `square` (finer control could be set with a small code change...)
|
||||
|
||||
see [this page] for more info on writing shaders for conjur. if a shader output is white it has probably failed to link (ie glsl hasnt compiled for some reason) i hope to improve the handling of errors from openframeworks in future.
|
||||
|
||||
## c_o_n_j_u_r + c_a_p_t_u_r
|
||||
|
||||
running live input through a 1-input shader is an exciting possibility once you have live input and 1-input shaders already. this also is responsible for aprox half my time/stress while at SC !
|
||||
|
||||
to process the captur input with a glsl-shader it needs to be read from openframeworks using ofxRPiCameraGrabber addon rather than the piCapture python package. for all other sampling / previewing uses ~~i recommend using the python (default) option ,~~ both options seem to work - not sure if one is better than other... (even if you are in openframeworks-backend mode, you can still capture/sample as before, and process these samples etc)
|
||||
|
||||
- to truely process live input you need to switch the USE_OF_CAPTURE to on, (and make sure VIDEO_BACKEND is openframeworks ) , ~~depending on the capture state before this you might also need a soft reset (RESTART_PROGRAM in OTHER )~~ <-- this should be fixed. , now when you start capture preview it should be running through openframeworks ! any 1-input shaders run now will effect this input !
|
||||
|
||||
- ~~if you are using piCaptureSd1 this will probably only work on composite output, and even there it may have some weird artifacts (like a glitchy line down the right side of screen) , i am working on getting some of those optimized settings into the openframeworks addon which should improve this.~~ piCaptureSd1 + openframeworks is working smoothly together now !
|
||||
|
||||
- note : ~~the sample-playback seems to be heavily impacted by of having created the capture object. this means currently if you go back to samples after starting of_capture it will likely be laggy. this is a big issue and i hope to fix it asap (releasing the capture resources when its not being used). for now a quick switch of VIDEO_BACKEND or hitting the soft RESTART_PROGRAM will fix it...~~ <-- this should also be fixed now
|
||||
|
||||
|
||||
[schematic]: incur_board.pdf
|
||||
[signal_culture_and_future_plans]: signal_culture_and_future_plans.md
|
||||
[analog_action_mapping.json]: ../json_objects/analog_action_mapping.json
|
||||
[this page]: https://github.com/langolierz/c_o_n_j_u_r/blob/master/notes_on_shader_formats.md
|
||||
[image]: https://drive.google.com/open?id=1C8WavPTi6fw2u1GxnpOg9F8Znv4r9MJe
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 280 KiB |
@@ -1,139 +0,0 @@
|
||||
# how to build a r_e_c_u_r - diy enclosure
|
||||
|
||||
## get some parts
|
||||
|
||||
for using other parts and other questions check out the [faq] , or get in touch.
|
||||
|
||||
these are the parts you need to get. to reduce shipping costs to nz i sourced them through aliexpress.com but you could equally get them from ebay or elsewhere.
|
||||
|
||||
### main parts:
|
||||
|
||||
- [raspberry pi3] *37 USD*
|
||||
|
||||
- [raspberry pi screen] *12 USD*
|
||||
|
||||
- [usb keypad (AliExpress)] or [usb keypad (Amazon)] *9 USD*
|
||||
|
||||
![main parts][main parts]
|
||||
|
||||
### optional c_a_p_t_u_r addons:
|
||||
|
||||
- [raspberry pi camera] *7 USD*
|
||||
- or [piCaptureSd1] *149 USD*
|
||||
|
||||
![capture parts][capture parts]
|
||||
|
||||
(note piCaptureSd1 is better supported in v2beta)
|
||||
|
||||
### other bits and pieces:
|
||||
|
||||
- 4x m2 and 6x m3 screws, 6mm is long enough - i ended up using 4 2-gauge and 6 4-gauge self tapping screws instead which were easier to get into the plastic case.
|
||||
|
||||
- 4 gb or greater mircoSD card
|
||||
|
||||
- a stable 5volt, 1A microUsb power supply
|
||||
|
||||
- some rubber feet for the bottom ? i had [these rubber feet] around from a previous project that work nicely
|
||||
|
||||
## print some things
|
||||
|
||||
- i 3d printed my enclosure using these files for the [top] and [bottom]. if you dont have access to a printer you can upload these files to a popular printing service in you region (eg ...)
|
||||
|
||||
- _note on enclosure: you could also just buy a standard raspberry pi3 (+screen) case and use the numpad externally. i personally found the 3d printing took a bit too long so am working on a lasercut-able option too. watch this space_
|
||||
|
||||
- 2d print these [key stickers] if you want to use the default key mapping, or modify the svg file (in inkscape or something) to create your own. you could print them onto vinyl, label paper or just normal paper and attach with with double sided tape...
|
||||
|
||||
## put it together
|
||||
|
||||
- using [etcher] (or otherwise) flash the micro sd with my [modified image] of raspbian (or follow these [instructions to install] from scratch.)
|
||||
|
||||
- _quick note about versions: i have uploaded a new modified image which you can read about and find [here]. this fixes some old bugs and adds some new features (and maybe some new bugs) this will replace the above image soon_
|
||||
|
||||
- insert sd card into pi
|
||||
|
||||
- use the 4 small screws to attach pi+screen to the bottom piece of enclosure
|
||||
|
||||
- attach the lcd screen via the pi header pins so it fits exactly on top of the pi. (some little spacers could be used to support the top corners of the screen)
|
||||
|
||||
- put a battery in the keypad , insert its usb dongle into the pi. fasten the keypad to the baseplate; i used some double sided tap along raised strips - although now im thinking superglue might hold better...
|
||||
|
||||
- use the 6 large screws to hold the top panel to the bottom
|
||||
|
||||
you are done ! wasnt that easy ?
|
||||
|
||||
## try it out !
|
||||
|
||||
( [operate docs] )
|
||||
|
||||
## my build gallery !
|
||||
|
||||
|
||||
|
||||
all the parts and tools i used in this build
|
||||
|
||||
|
||||
|
||||
the main playaz : raspi-lcd-screen , raspi3 , generic usb-keypad
|
||||
|
||||
|
||||
|
||||
tools even your mums house would have lying around...
|
||||
|
||||
|
||||
|
||||
|
||||
3d printed baseplate and top panel
|
||||
|
||||
|
||||
|
||||
ctrl-c
|
||||
|
||||
|
||||
|
||||
ctrl-v
|
||||
|
||||
|
||||
|
||||
held in with double-sided tape on bottom
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
its easier to flash and insert the sd card before screwing it in !
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
r_e_c_u_r looking happy among friends !
|
||||
|
||||
|
||||
|
||||
[raspberry pi3]:https://www.aliexpress.com/item/RS-Version-2016-New-Raspberry-Pi-3-Model-B-Board-1GB-LPDDR2-BCM2837-Quad-Core-Ras/32789942633.html?spm=a2g0s.9042311.0.0.FkRWty
|
||||
[main parts]: build_all.jpg
|
||||
[capture parts]: capture_parts.jpg
|
||||
[raspberry pi screen]:https://www.aliexpress.com/item/3-5-Inch-TFT-LCD-Moudle-For-Raspberry-Pi-2-Model-B-RPI-B-raspberry-pi/32707058182.html?spm=a2g0s.13010208.99999999.262.bV4EPV
|
||||
[usb keypad (AliExpress)]:https://www.aliexpress.com/item/USB-Wireless-Numeric-Keypad-19-Keys-Numpad-Number-Pad-Wireless-2-4GHz-Mini-Receiver-for-Laptop/32821720854.html
|
||||
[usb keypad (Amazon)]:https://www.amazon.com/gp/product/B076GZDC14/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1&fbclid=IwAR3fNd1z0Cu137GE0ONYP2vmoTm0rJIvDA9plHlvCjNGZrSZFsV_naCHax0
|
||||
[raspberry pi camera]:https://www.aliexpress.com/item/RPI2-raspberry-pi-2-model-b-b-plus-camera-5-million-pixels-professional-ip-webcam-module/32403602769.html
|
||||
[piCaptureSd1]: https://lintestsystems.com/products/picapture-sd1
|
||||
[top]: ./topplate.stl
|
||||
[bottom]: ./baseplate.stl
|
||||
[key stickers]: ./keystickers.svg
|
||||
[etcher]: https://etcher.io
|
||||
[modified image]: https://drive.google.com/file/d/1SlqM13jxLlk_zajXgdub1fpu-k76jE1e/view?usp=sharing
|
||||
[operate docs]: ./operate_docs.md
|
||||
[instructions to install]: ../dotfiles/README.md
|
||||
[these rubber feet]: https://www.aliexpress.com/item/40-Self-Adhesive-Rubber-Bumper-Stopper-Non-slip-Feet-Door-Buffer-Pads-Furniture-DIY-Tool/32849514475.html?spm=a2g0s.9042311.0.0.6ee14c4dFXynVK
|
||||
[faq]: ./faq.md
|
||||
[here]: https://github.com/langolierz/r_e_c_u_r/blob/c_o_n_j_u_r/documentation/beta_access_notes_and_limitations_of_v2.md
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 173 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 182 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 113 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 123 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 138 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 162 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 254 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 195 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 151 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 139 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 161 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 265 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 252 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 273 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 379 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
@@ -1,40 +0,0 @@
|
||||
# how to develop r_e_c_u_r
|
||||
|
||||
i have tried to write this application so it can easily be read and modified for different use cases. i recommend forking the repo to experiment with the codebase. open a pull request into origin <your_branch> if you want to contribute your changes back into the project.
|
||||
|
||||
this [diagram] might help understand the design :
|
||||
|
||||
![design_overview][design_overview]
|
||||
|
||||
here are some examples of changes you might want to make:
|
||||
|
||||
## rearranging the _keypad_ controls
|
||||
|
||||
to simplify the key-mapping process, i have pre-mapped the numpad keys to the _labels_ `a` to `s` like this:
|
||||
|
||||
![premapped_keys][premapped_keys]
|
||||
|
||||
(see [dotfiles] for description of this process)
|
||||
|
||||
for each _label_ the application will read the [keypad_action_mapping.json] file and map it to an [action]. the format also allows unique actions per _control_mode_ and per the `FUNCTION` toggle :
|
||||
|
||||
```
|
||||
...
|
||||
"x": {
|
||||
"NAV_BROWSER": ["trigger_this_action_in_browser_mode"],
|
||||
"DEFAULT": ["trigger_this_action_in_any_other_mode_with_FN_off","trigger_this_action_in_any_other_mode_with_FN_on"],
|
||||
}
|
||||
```
|
||||
## creating a new action
|
||||
|
||||
## beyond
|
||||
|
||||
i hope the foundations iv provided encourage you to make larger changes for more ambitious features. if so you could try getting in touch (langolierz@gmail.com) first and maybe i could help align your approach with the rest of the project
|
||||
|
||||
[diagram]: https://docs.google.com/drawings/d/1ltWCv82rKVzOiFe6GaDDPlneG2oki0yRujArPU5V2ss/edit?usp=sharing
|
||||
[design_overview]: design_overview.jpg
|
||||
[premapped_keys]: vectorfront_blank_keys.png
|
||||
[dotfiles]: ../dotfiles
|
||||
[keypad_action_mapping.json]: ../data_centre/json_objects/keypad_action_mapping.json
|
||||
[action]: ../actions.py
|
||||
|
||||
@@ -1,42 +0,0 @@
|
||||
# hdmi drop out bug
|
||||
|
||||
some time between when i did compatibility testing , and now - high res videos now often (and consistently cause hdmi drop outs. all 1080 do , and some 720 also) - on my hdmi-to-vga computer display.
|
||||
|
||||
also (possibly related) when trying it on full hdmi projector, it drops out playing all video no matter the resolution ! whats going on ?
|
||||
|
||||
some research suggests that not enough power can cause this problem.
|
||||
possible fixes / things to rule out include :
|
||||
|
||||
- trying signal-boost in config
|
||||
- try overclocking the pi
|
||||
- try an old version of the code
|
||||
- try an old version of firmware
|
||||
- try changing some other config settings (camera mode etc)
|
||||
- try creating a new img from old img (with bare minimum) and update piece by piece until it doesnt work.
|
||||
|
||||
## results:
|
||||
|
||||
### vga-hdmi display
|
||||
|
||||
- signal boosting didnt help ,
|
||||
- old version of code didnt help
|
||||
- old firmware improved a little bit but didnt fix
|
||||
- changing config etc didnt help
|
||||
- turning off raspi2fb didnt help
|
||||
|
||||
### drastic measures ! :
|
||||
|
||||
- flashed a new sd with old raspbian from last year. only installing the minimal to play video.
|
||||
|
||||
- while running old code it plays better but not perfect - still drops from time to time but mostly working.
|
||||
- tried installing some newer dependencies , still running old code :
|
||||
|
||||
didnt investigate this route any further
|
||||
|
||||
### solved ?
|
||||
|
||||
by chance i tried switching the video output to composite and back - ~~somehow after this the hdmi plays 1080 videos just fine. no idea why or when it was introduced , but i created an action to run this on startup and seems fine now. phew.~~ this didnt seems to fix it after all.
|
||||
|
||||
i tried setting the hdmi output to 720 instead of 1080 and from here all the videos including 1080 load and play fine. still some dropouts for 1080 video on my vga converter though...
|
||||
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
|
||||
# some of what follows is out of date since i have improved a number of problems since i did this. i will have to revisit this page with updates soon !
|
||||
|
||||
# compatibility testing
|
||||
|
||||
so far i have only been using a small selection of video files while running **r_e_c_u_r** .
|
||||
|
||||
i want to try it with a number of different video containers , codecs , resolutions , lengths etc on
|
||||
both hdmi and composite displays. by compiling and downloading a number of test clips from various places online ,
|
||||
i now have a folder of videos named in this format : 'width-container-codec'
|
||||
|
||||
clip | expectation | results
|
||||
--- | --- | ---
|
||||
120-mov-svq1.mov | i wouldnt expect/need this to play with apples custom codec | omx cant reconise codec
|
||||
240-webm-vp8.webm | i believe vp8 codec is supported on omx but not sure if webm container is | omx cant play webm
|
||||
360-webm-vp8.webm | same as above | ""
|
||||
480-avi-mjpeg.avi | this should play fine | ~~wont map `dbus exception no reply`~~ on second try it does map but doesnt play - normal omx player opens but cant play it either
|
||||
480-flv-vp6.flv | i think this should work although not too worried about supporting flv ! | omx cant play this ?
|
||||
576-mov-mjpeg.mov | this should work | this works surprisingly well - never lags on load
|
||||
576-mp4-h264.mp4 | this should work fine | plays good, sometimes lags on custom start
|
||||
720-mkv-h264.mkv | this should play fine - interested if seeking / sublooping looks ok | plays ok , customstart seems to weirdly jump to middle ...
|
||||
720-mp4-h264.mp4 | this should play fine | plays good, sometimes lags on load
|
||||
720-mp4-h264-60fps | ~~my computer struggles to play this~~ think just a laggy video | plays suprisingly well - never lags on custom start
|
||||
1080-avi-mpeg4.avi | i think this should play ok | does play - sometimes struggles to load the next loop though - similar to the other 1080 one but a bit better (seems to load if current video is paused)
|
||||
1080-flv-flv1.flv | wouldnt expect/need flv with custom codec | omx doesnt recognize codec
|
||||
1080-mkv-h264-60mbps.mkv | dont expect this to work | surprisingly this video played though on pi (didnt even open on my computer.) however is showing a weird new bug where when the video finished , the next one wont load but also wont error... _UPDATE: works now gpu has more memory_
|
||||
1080-mp4-h264.mp4 | hopefully this plays okay ?? | this wouldnt load , error getting video length : `dbus exception no reply` (although it played ok in normal omxplayer) _UPDATE: works now gpu has more memory_
|
||||
error-mkv-mpeg4.mkv | should fail but not sure how.. | just wont load
|
||||
|
||||
an interesting note : ~~all the videos above behaved the same on hdmi and composite out except for 1080-mp4-h264 which didnt have the failing to load next problem , instead , would flash green for a bit at the start of each clip even on custom starts~~ this also started happening on hdmi out - seems to be unpredictable how it handles 1080p files
|
||||
|
||||
## the same mp4 video at different resolutions
|
||||
|
||||
i use adobe premiere to edit videos. i imported a raw 10s mts file from a digital camera and exported 3 times : 480 , 720 and 1080. these three were loaded and tested on recur :
|
||||
|
||||
- 480 played fine - no lags when custom starting (both on hdmi and composite)
|
||||
- 720 played ok - video played through and loaded all good. sometimes would lag on custom start point , seemed to be better / not do this when composite out mode
|
||||
- ~~1080 doesnt work - the video can play through once alright , but it seems like the omxplayer/dbus connection cant load another 1080 file while an existing 1080 file is playing~~
|
||||
|
||||
UPDATE: turns out the 1080 files couldnt load because the pi hadnt been assigned enough memory to its gpu . i added `gpu_mem=448` to the config.txt and now 1080 videos seem to load and loop just fine. (still sometimes lags when change is triggered/ custom start)
|
||||
|
||||
# summary of findings :
|
||||
|
||||
- .mp4 containers with h.264 codec seems to be the best format - long videos play fine (tested up to 3 hours) besides some display confusion for durations over 99 minutes as expected. can play files up to 1080 resolution fine. the chances of micro lags on changeover/custom starts seems to increase with higher resolution (no problems with 480 now) but can still be avoided by setting another custom start just after the position that is lagging.
|
||||
- .avi , .mov and .mkv containers also work. h.264 is best , mjpeg worked in a .mov container but not in .avi ... there was some issues with setting custom start in one of the .mkv files i tried - this might need some more investigation...
|
||||
@@ -1,68 +0,0 @@
|
||||
|
||||
|
||||
### serial midi from rpi gpio pin
|
||||
|
||||
i believe it is possible to read midi in from an i/o pin (that can read serial) which might be desirable in some cases but this is a good start for now. this [instructable] explains how to input/output midi with the gpios, it looks like the tx/rx (serial?) pins on the pi3 are currently used/covered by the gpio screen that i am using. if i was serious about external circuits interfacing with pi/recur, i might look into using an lcd screen that doesnt use up the gpios. (would also be worth checking if piCapture would work with the gpio screen i have...)
|
||||
|
||||
### gpio pins :
|
||||
|
||||
the [adafruit tft display] mentioned above also uses the gpios to connect to the pi - in particular it uses 5 spi pins and two standard pin outs. by cross referencing the [raspi gpio] docs it does not use either of the rx serial pin , which would be needed if i were to receive midi directly (rather than through usb), it also leaves plenty of pins for receiving cv from a [mcp3008] through software spi for example. it is likely that my gpio lcd screen communicates with the pi in a similar way and that i could figure out a way to connect these extensions if desired.
|
||||
|
||||
what follows is the interface of cheep lcd from the shop page :
|
||||
|
||||
PIN NO.| SYMBOL | DESCRIPTION
|
||||
--- | --- | ---
|
||||
1, 17| 3.3V | Power positive (3.3V power input)
|
||||
2, 4 | 5V | Power positive (5V power input)
|
||||
3, 5, 7, 8, 10, 12, 13, 15, 16 | NC | NC
|
||||
6, 9, 14, 20, 25 | GND | Ground
|
||||
11 | TP_IRQ | Touch Panel interrupt, low level while the Touch Panel detects touching
|
||||
18 | LCD_RS | Instruction/Data Register selection
|
||||
19 | LCD_SI / TP_SI | SPI data input of LCD/Touch Panel
|
||||
21 | TP_SO | SPI data output of Touch Panel
|
||||
22 | RST | Reset
|
||||
23 | LCD_SCK / TP_SCK | SPI clock of LCD/Touch Panel
|
||||
24 | LCD_CS | LCD chip selection, low active
|
||||
26 | TP_CS | Touch Panel chip selection, low active
|
||||
|
||||
from this i should b able to work out which pins i can use for midi in and for analog-to-digital inputs (also piCapture needs some inputs too)
|
||||
|
||||
# gpio inputs for recur:
|
||||
|
||||
here are the pins needed for different parts of the recur connections:
|
||||
|
||||
note that pins 1 to 26 are covered by the lcd screen, even though not all are used by it
|
||||
|
||||
## lcd screen
|
||||
|
||||
as stated above, the screen uses the following pins:
|
||||
- 1 , 17 : 3.3v
|
||||
- 2, 4 : 5v
|
||||
- 11 : TP_IQR (for touch panel)
|
||||
- 18 : LCD_RS
|
||||
- 19 : LCD_SI
|
||||
- 21 : TP_SO (touch panel output)
|
||||
- 22 : reset
|
||||
- 23 : LCD_SCK
|
||||
- 24 : LCD_CS
|
||||
- 26 : TP_CS
|
||||
|
||||
## piCapture
|
||||
|
||||
piCapture be default will use pins 3, 5, 7 to comunicate
|
||||
|
||||
## serial-midi in
|
||||
|
||||
pin 10 (rx) is needed for midi in plus 3.3v (combined with octocoupler 6n138 etc and resistors)
|
||||
|
||||
## analog in
|
||||
|
||||
using a MCP3008 via hardware SPI, can connect up to 8 analog inputs using pins 35, 36, 38, 40 (SPI1) + 3.3v , can also connect with software SPI with any four pins if more inputs were needed. these inputs can be used for pots/sliders & gate/cv jacks. by default will react to 0-3.3v. if wanting to use larger range than this will need some kind of scaling electronics (tl074d?)
|
||||
|
||||
providing 4 pins on under the lcd screen cover can be accessed by the board (and 3.3v can be distributed) i should be able to create a circuit that connects all these inputs to the pi.
|
||||
|
||||
|
||||
[instructable]: http://www.instructables.com/id/PiMiDi-A-Raspberry-Pi-Midi-Box-or-How-I-Learned-to/
|
||||
[adafruit tft display]: https://www.adafruit.com/product/2441
|
||||
[raspi gpio]: https://www.raspberrypi.org/documentation/usage/gpio/
|
||||
[mcp3008]: https://learn.adafruit.com/raspberry-pi-analog-to-digital-converters/mcp3008
|
||||
@@ -1,33 +0,0 @@
|
||||
## firmware bug
|
||||
|
||||
at some point i must have updated the raspi firmware. this caused the recur application to present a bug that makes it basically unusable:
|
||||
|
||||
### the bug
|
||||
|
||||
the video freezes / lags often , usually at the same spot : 10s in, 2minutes in etc. when a video is reload (ie another video player created underneath current one) the current video usually freezes.
|
||||
|
||||
### investigation
|
||||
|
||||
- i tried checking out an old version of recur code to rule out a change on my code causing it. this still behaves the same way
|
||||
|
||||
- i created a new version of recur from the newest (april) version of stretch. this also displays the bug.
|
||||
|
||||
- finally i created a new version of recur from the older version (november) and made sure to not install any of the new packages (midi / capture). this worked without the bug on an old version of the code ! wahoo. i now tried installing those new packages and running the update code. still working !
|
||||
|
||||
- next i created an image of this working recur. (known issues with the image so far : screen saver is on, our home wifi is included)
|
||||
|
||||
- the firmware that is working is `uname -a : Linux raspberrypi 4.9 59-v7+ #1047 SMP Sun Oct 29 ...`
|
||||
|
||||
- next i will try a `sudo apt update` and `sudo apt upgrade` to rule out a package update causing the bug - can confirm its still working after apt upgrades ! must be the firmware :
|
||||
|
||||
- the gpu firmware (not sure the exact dif..) is obtained from `sudo /opt/vc/bin/vcgencmd version` and is `Oct 24 2017 .. a3d7660e6749e75e2c4ce4d377846abd3b3be283 (clean) (release) `
|
||||
|
||||
the new firmware says its : `754029b1cb414a17dbd786ba5bee4fc936332255` which is what i started typing into `sudo rpi-update 754029b`
|
||||
|
||||
now `uname -a` reads `.. 4.9.60-v7+ #1048 .. Fri Nov 3` and the player still works. `sudo /opt/vc/bin/vcgencmd version` says `Nov 3 .. 1bcf9152... (clean) (release)`
|
||||
|
||||
pushed forward to v 4.14.20 which failed. pushing back: did this a few times. got it working on 4.9.78 but failing on 4.9.80. looks like it might be this issue : https://www.raspberrypi.org/forums/viewtopic.php?t=195178 - just need to figure out how to turn it off for testing
|
||||
|
||||
found it ! i have the latest firmware version and by adding `audio_pwm_mode=0` to the config it now plays as before . phew what a relief !
|
||||
|
||||
gonna create new version of the image with this fixed , the wifi removed and the screensaver disabled.
|
||||
@@ -1,98 +0,0 @@
|
||||
# video input
|
||||
|
||||
### background
|
||||
|
||||
a common feature of audio samplers is the ability to 'live sample' ie have a line in to the device and use this to record a sample directly onto it - usually to be played back again immediately as part of a performance.
|
||||
|
||||
from what i can tell some hardware video samplers also offer this feature. it would be interesting to explore the possibility of this with recur. some ways to record video into recur include:
|
||||
|
||||
- a usb dongle / external capture card
|
||||
- using a pi camera for live video or rescanning off a screen
|
||||
- piCapture : a custom video card built for pi to use the pi cam protocol
|
||||
|
||||
the first option seems fiddly and difficult / a compromise. i might be interested in trying to capture with a Blackmagic Intensity Shuttle if i get one some day...
|
||||
|
||||
options 2 and 3 both seem plausible, and hopefully will be interchangeable once things are working (piCapture claims to act exactly like a piCam so should painless). also this allows both a cheap/hacky solution (rescanning through $2 camera) or a more professional option ($130 addition) and i can start experimenting now with a cheep cam before investing in the expensive piCapture.
|
||||
|
||||
i know piCam and piCapture recommend using python and there is libraries for this
|
||||
|
||||
### things to find out
|
||||
|
||||
i want to know how plausible it would be to add live sampling to my current recur stack (gpio lcd screen, omxplayer video backend).
|
||||
|
||||
some things i want know are:
|
||||
|
||||
- how to set up the piCam on raspberry pi
|
||||
- how to record the input from the piCam onto the pi
|
||||
- will these files play back in omx/recur
|
||||
- can you preview the stream on the hdmi/composite output ?
|
||||
- can you preview the stream on the lcd display ?
|
||||
- can this preview be adjusted / resized etc ?
|
||||
- can you adjust params of camera ? in real time ? framerate , brightness , contrast , zoom etc ?
|
||||
- how does rescanning look ?
|
||||
- how could i control piCaptures additional params ?
|
||||
- is there any reason to think piCapture wouldnt be interchangable with a working piCam feature ?
|
||||
|
||||
### research
|
||||
|
||||
[cheep cameras] for raspi can be bought from china with 5 mega pixels / recording 1080p video for around $5usd. i have borrowed a camera ~~which i think is a night-vision version~~ to experiment with , although should order one of these myself.
|
||||
|
||||
i started by reading the [picamera] python package docs. this seemed to have lots of options regarding recording video , including starting and stopping both previews and video recordings , the ability to set the resolution , framerate , shutter speed of the camera , switching preview to full screen or setting the size and position of it.
|
||||
|
||||
also a bunch of parameters that might be of interest including brightness , colour effect , contrast , flips and rotations , preview alpha , saturation , sharpness. these apear to be controllable in real time while previewing or recording.
|
||||
|
||||
it seems like the output from the camera is raw (without frame per second meta data) h264 and to play the video back at correct speed will need a program to wrap it in an mp4 container :
|
||||
```
|
||||
$ sudo apt-get install gpac
|
||||
...
|
||||
$ MP4Box -add input.h264 output.mp4
|
||||
```
|
||||
|
||||
the [faq] also addresses the 'can i preview to the lcd screen' question : looks like no - at least not without copying the exact framebuffer , similar to my experiments displaying omx on the lcd screen. (this still might be possible in the world of openCv but off the table for now! - or maybe not even then - this [adafruit] tutorial talks about the limitations of displaying on a tft screen - "accelerated software will never appear on the PiTFT (it is unaccelerated framebuffer only)" )
|
||||
|
||||
|
||||
|
||||
### research continued : piCapture
|
||||
|
||||
[picapture] is a video capture card designed for the raspberry pi to emulate the piCamera and take advantage of the pi's hardware acceleration. it comes as a 'hat' that also uses ic2 (or serial)
|
||||
to communicate. there is a python package to access these additional options.
|
||||
|
||||
these come in two types :
|
||||
|
||||
- standard def - composite and s-video in , $139usd
|
||||
- hi def - hdmi and component in $159usd
|
||||
|
||||
im not sure which one i would like to try, but they sound cool ! would need to check the pins dont clash with the display but i think these should work together nicely !
|
||||
|
||||
### getting started with piCamera
|
||||
|
||||
following the picamera docs , i will/have :
|
||||
|
||||
- plugged in the camera
|
||||
- turned on camera in the config
|
||||
- tried take an image
|
||||
- installed package with `sudo apt-get install python3-picamera`
|
||||
- run `sudo apt-get update` and `sudo apt-get upgrade` (for firmware)
|
||||
- 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 !~~ 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 (surprisingly 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 de-prioritized since it can be done manually with mouse/keyboard and could be risky / might want a confirmation window ...)
|
||||
|
||||
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...
|
||||
- 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
|
||||
[adafruit]: https://learn.adafruit.com/adafruit-pitft-3-dot-5-touch-screen-for-raspberry-pi/easy-install-2
|
||||
|
||||
[cheep cameras]: https://www.aliexpress.com/item/5MP-Camera-Module-Flex-Cable-Webcam-Video-1080-720p-For-Raspberry-Pi-2-3-Model-B/32860830711.html
|
||||
[picapture]: https://lintestsystems.com/products/picapture-sd1
|
||||
@@ -1,66 +0,0 @@
|
||||
# midi support
|
||||
|
||||
my investigation into controlling recur with midi will be documented here.
|
||||
|
||||
### aim
|
||||
|
||||
i want to be able to read midi messages to control recur - the simplest intergration would be loading and triggering clips from midi. other paramters controled over cc or otherwise should be easy to add when required. in a similar way to the keypad controls, i would like the mapping to be read from a json file and use this to run actions.
|
||||
|
||||
### cheep midi9to-usb dongle
|
||||
|
||||
i have decided to start by trying a cheep [usb-to-midi cable] i got for just over $3.
|
||||
|
||||
plugging the midi dongle into the pi , i can see it in `client 20` by calling `aconnect -i` , however when connected to a midi controller (deluge) it is not receiving messages when `aseqdump -p 20` is running (besides a few ghost note off events)
|
||||
|
||||
running midiox on my windows machine to test the cable also didnt help, it wouldnt receive any messages and complained about not having enough memory...
|
||||
|
||||
something seems wrong with the dongle. it also seems like these cheep dongles are not very reliable or useful anyway according to [sy35er] on a yamahamusic forum
|
||||
|
||||
update : by using ableton on my windows i could successfully send midi out off usb and receive it on deluge. still no luck reading midi to usb though.
|
||||
|
||||
|
||||
### usb midi
|
||||
|
||||
next i tried using the deluge to output midi over usb. midiox on windows still wouldnt work , but when i tried `aseqdump -p 20` on the pi it recorded the midi perfectly. i will use usb midi to test this feature on recur. (better adapters exist that convert serial midi to usb midi /could make one with ardunio or teensy!), so that will be a good start
|
||||
|
||||
i have decided to try using the [mido] python package for responding to midi input.
|
||||
|
||||
### midi clock
|
||||
|
||||
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 method 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 corresponding action on recur. even when pressing keys with the sequencer running (lots of clock messages being sent) it still responds quickly and consistently. however when triggering the same notes from the sequencer, it seems to drop lots on the notes : usually 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.
|
||||
|
||||
### further 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?
|
||||
|
||||
i ended up trying cc with some camera parameters. 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 consistently 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 revisit when other features are under cv control etc.
|
||||
|
||||
|
||||
|
||||
|
||||
[usb-to-midi cable]: https://www.aliexpress.com/item/Hot-Selling-1pcs-Keyboard-to-PC-USB-MIDI-Cable-Converter-PC-to-Music-Keyboard-Cord-USB/32813475019.html
|
||||
[instructable]: http://www.instructables.com/id/PiMiDi-A-Raspberry-Pi-Midi-Box-or-How-I-Learned-to/
|
||||
[mido]: https://mido.readthedocs.io/en/latest/
|
||||
[midi-clock]: https://en.wikipedia.org/wiki/MIDI_beat_clock
|
||||
[sy35er]: https://yamahamusicians.com/forum/viewtopic.php?t=8218
|
||||
@@ -1,16 +0,0 @@
|
||||
# notes on demo video
|
||||
|
||||
recur is quite hard to demo in general because it has three parts that need to be recorded - and synced - for it to make sense :
|
||||
the _live_ , showing which buttons are pressed; the _screen_ , showing the ui - it is too hard to see from live ; and the resulting _video_ output.
|
||||
|
||||
since this is the second time i have tried to do this i wanted to leave some notes for futrue me - or anyone else who might want to demo similar.
|
||||
|
||||
## recording
|
||||
|
||||
i used my cellphone to record _live_ - at 720, used `recordmydesktop --no-sound` application on the raspberry pi to record the _screen_ and this time a usb3-intesity-shuttle to record _video_
|
||||
|
||||
the video out went through a tbc - ave5, taking the svideo out from the mixer - not sure if it made any differnece. then the huge raw files were compressed to mp4 my vlc to be edited
|
||||
cellphone video was already compressed and compadiable with adobe premeire 6 where i did editing. the recordmydesktop output was ogv which i converted online - freefileconvert.com as vlc messed up the timestamp.
|
||||
the colour from recordmydesktop is tinted pink which can be altered in premeire.
|
||||
|
||||
i synced the three channels by allining a button push that changes state of video out and screen
|
||||
@@ -1,52 +0,0 @@
|
||||
# porting to other sbc
|
||||
|
||||
a collection of thoughts / research / attempts at porting r_e_c_u_r
|
||||
|
||||
## attempting to port r_e_c_u_r to an orange pi plus
|
||||
|
||||
i bought an [orange pi plus] at the same time as my raspberry pi 3 , thinking that since they are
|
||||
similarly spec-ed (orange pi is a little weaker but also much cheaper ~18US vs ~38USD i payed for rpi3) this might be an interesting alternative to offer.
|
||||
|
||||
i (naively) figured since opi claim to support raspbian as an os, that this might be as simple as installing the same dependencies outlined in the [preparing image] notes and maybe some fiddling with the lcd-screen drivers...
|
||||
|
||||
it seems like the only raspbian image for orange pi plus was a fork of wheezy distro from 2015 with pre-installed desktop. this is not supported or updated by orange pi and seems to be a token gesture to compete on paper with raspberry pi. with this image i managed to install some dependencies, but the dbus packages needed for the omx wrapper couldnt be installed (i think the os was too old). also their is no config.txt on orangepi so settings like composite video out and different hdmi modes was going to be more difficult (not to mention the lcd screen driver)
|
||||
|
||||
## porting to armbian
|
||||
|
||||
however what is supported and updated is an os called armbian , which (similar to raspbian)
|
||||
is a version of debian (or linux) made for ARM dev boards. if i can get r_e_c_u_r working on opi running latest armbian , it might also work on a bunch of other sbc including other orange pis, ondroids , banana pi etc (beaglebone's run straight debian so perhaps i should see if it works there too)
|
||||
|
||||
given that the software dependencies are available in these alternative os (im not sure if they are yet but will just have to try it) some other problems to solve when trying to port r_e_c_u_r to other sbcs are:
|
||||
|
||||
- connecting a lcd screen / playing video to one framebuffer while running python on another.
|
||||
[Kaspars Dambis' blog] describes how to configure a similar lcd display to mine on an orange pi zero running armbian so hopefully this could help porting it to orange pi pc
|
||||
- playing the video through one framebuffer (hdmi or composite) while the python code displays on another (lcd screen)
|
||||
this kindof 'just worked' for me on raspberry pi running rasbian but i dont know how it will translate...
|
||||
- video playback might be weaker depending on the gpu acceleration of these alternative boards
|
||||
(omxplayer is accelerated for rpi but probably not for these others). also things like h.2 video codex
|
||||
licencing things etc might come into it
|
||||
- configuring different hdmi and composite video settings. (pi seems to do this particularly well)
|
||||
|
||||
## conclusion for now
|
||||
|
||||
some more research into this is required , but at this point it seems like the extra effort to get recur running on other smc's might not be worth the savings in cost or flexibility.
|
||||
|
||||
r_e_c_u_r is an embedded solution and the choice of hardware (raspi3) is tied to the application :
|
||||
|
||||
- lcd screen drivers
|
||||
- omxplayer w acceleration
|
||||
- (future features using pi camera / capture devices)
|
||||
|
||||
right now rpi3 still seems like the best tool for the job and the benefits of running cross-boards are
|
||||
not enough to distract from improving this implementation. (perhaps a future recur independent of omxplayer might benefit more from running on main debian / armian)
|
||||
|
||||
## r_e_c_u_r on other raspberry pi boards
|
||||
|
||||
as an aside, i am still hopeful that r_e_c_u_r will run on rpi2 and/or zero with little to no changes required. this might be a more useful and achievable port to focus on for now.
|
||||
|
||||
|
||||
|
||||
|
||||
[orange pi plus]: https://www.aliexpress.com/item/Orange-Pi-PC-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/32448079125.html?spm=a2g0s.9042311.0.0.kWJI0G
|
||||
[preparing image]: ./preparing_image.md
|
||||
[Kaspars Dambis' blog]: https://kaspars.net/blog/linux/spi-display-orange-pi-zero
|
||||
@@ -1,73 +0,0 @@
|
||||
|
||||
# frequently asked questions
|
||||
|
||||
a place to document the questions and thoughts asked about r_e_c_u_r so far. if you have any other questions please ask them in the fb group or get in touch directly.
|
||||
|
||||
## what kind of lcd screens can i use for recur _display_
|
||||
|
||||
the cheep 3.5 lcd screen i suggest in the [build] guide is already set up (with drivers etc) to work with the card img i have shared. this is the easiest option as it will be straight plug-and-play.
|
||||
|
||||
however it will be possible to config some other lcd screens to work. the _video output_ uses framebuffer0 on either the hdmi or composite output (i have not heard of these outputting simultaneously ). for this reason you cannot use a lcd screen that connects via hdmi for the display. the default _display_ uses framebuffer1 over the gpio pins. any lcd screen that receives video over gpio should work with recur given the correct drivers (note: some hdmi displays still use gpio for power / touch info; these will not work as a display)
|
||||
|
||||
besides _gpio_ and _hdmi_ , the third option to connect a lcd display is over _dsi_ (used by official raspi display). i have not tried this and am not sure if it would (or could) work for recur. i would be keen to hear thoughts / experiments if anyone has one, or have a go at this at some point...
|
||||
|
||||
## can i use a pi2/pi1/pi0 for this ?
|
||||
|
||||
im not sure. will update here when i have a chance to try... the pi3 is the highest spec available right now, and for playing hd videos seamlessly it is already at its limit. an older model might work fine for composite but would struggle sooner with hd content. besides gpu , i think a pi2 should _run_ recur out of the box. would be keen to try recur composite playback on the pi0
|
||||
|
||||
## how do i connect composite out / why is my composite cable just outputting corruption ?
|
||||
|
||||
you will need the correct 3.5mm TRRS to RCA cable. the [correct cable] has video on fourth pole and ground on third. if your cable is outputting junk / not working it is possible you (like me) have gotten the wrong type: [my cable] had ground on the fourth pole and video on the third (most digital cameras are wired this way) i fixed this by cutting an old rca cable and swapping the ground / video around
|
||||
|
||||
## can i use a usb keyboard / some other usb keypad to control recur ?
|
||||
|
||||
yes ! the key mapping has been abstracted out to a .json file that can be edited to allow different input options. the flashed img maps the keys for the keypad i recommend (from [build] docs) to the letters a - s with the [.keymap] . the a - s keys are then assigned in the [keypad_action_mapping.json] to their corresponding actions.
|
||||
|
||||
if you are using a full usbkeyboard, you should be able to just press a - s keys for corresponding actions , and rearrange the letters in mapping for your own custom mapping.
|
||||
|
||||
you can also flatten out the FN actions and add new actions (such as shortcuts / hotkeys) to map to the extra keys. hopefully more info about this will be on the [develop page] at some point.
|
||||
|
||||
## i want to edit a keymapping or do something on the pi without looking at the lcd screen
|
||||
|
||||
i also get sick of looking at the lil screen for developing , from the OTHER settings you can run DEV_MODE_RESET , when it reboots the hdmi is the main output and your video out should be in a smaller window.
|
||||
|
||||
## i keep getting a yellow lightening bolt in the upper right corner ?
|
||||
|
||||
this is the pi signaling it is underpowererd. running video and the lcd screen and powering a harddrive and a camera etc etc starts to add up. i havnt had any problems using a 2a supply..
|
||||
|
||||
## how can i access / delete files i have created using capture ?
|
||||
|
||||
these are saved to the user Videos folder at path : `/home/pi/Videos/recordings`
|
||||
|
||||
to get to these you will probably need a usb keyboard (a usb mouse can help too)
|
||||
|
||||
- if you are happy with command line this can be accessed by pressing ctrl+alt+f1 from keyboard (ctrl+alt+f7 will return to recur)
|
||||
- if you would rather navigate from a mouse, the recur program can be exited by pressing `.` key. moving the mouse to bottom of screen should bring up raspi toolbar where filebrowser can be opened etc
|
||||
|
||||
### note : also you can copy videos to the `internal storage` folder inside this Videos folder if space on the sd allows
|
||||
|
||||
## when i use the hdmi out on my tv/projector/screen the video keeps dropping out ?
|
||||
|
||||
yes - this seems to be the pi responding to running out of memory when two videos are loaded at 1080 resolution on some displays. to fix this you need to change the `HDMI_MODE` setting to `CEA 4 HDMI`, this sets the pi output to 720 which should play without dropout (even playing 1080 videos)
|
||||
|
||||
## my video files do not show up in the browser ?
|
||||
|
||||
at the moment recur will filter out all files that do not have a '.mp4' (recommended), '.mkv', '.mov' or '.avi' file extension in their name. (so you can not try to map .docx, .jpeg /other obvs non-video files) ..perhaps there is a better way to tell if a file is video without reading the extension ?
|
||||
|
||||
## when playing short loops <=3s or manually switching players quickly sometimes the player crashes / gets stuck `LOADING` ...
|
||||
|
||||
hmm - this does happen sometimes. in my experience pressing the video key you want to load again then the switch key will get the video playing again. I havnt been able to create crashes that require a reset, but if you do please let me know.
|
||||
|
||||
## when setting the start/end points of a clip there is a small lag before starting the next cycle .. can i improve this ?
|
||||
|
||||
this could happen because your cycle is too short to allow the NEXT video to load before NOW has finished. making your cycle a little longer could make a difference here.
|
||||
|
||||
HOWEVER, i have also noticed that this lag can happen even with longer clips sometimes and i dont know why. it seems that resetting the `start` point can sometimes fix it. i wish i could figure out why this happens... if you have any insight hmu ! i feel like this could be improved if understood ! (this could be a limitation of seeking in a H264 container ... )
|
||||
|
||||
[correct cable]: https://www.adafruit.com/product/2881
|
||||
[my cable]: https://www.aliexpress.com/item/4-poles-3-5mm-Mini-AV-Male-to-3RCA-Female-M-F-Audio-Video-Cable-Stereo/32769544207.html
|
||||
[.keymap]: /dotfiles/.keymap
|
||||
[keypad_action_mapping.json]: /json_objects/keypad_action_mapping.json
|
||||
[develop page]: /documentation/develop_docs.md
|
||||
[build]: /documentation/build_docs.md
|
||||
|
||||
@@ -1,43 +0,0 @@
|
||||
|
||||
## BOM
|
||||
|
||||
REFERENCE | QUANTITY | DESCRIPTION | PACKAGE | NOTE
|
||||
--- | --- | --- | --- | ---
|
||||
R1, R2, R3, R4 | 4 | 1K Resistor | through-hole | -
|
||||
R5 | 1 | 220 Resistor | through-hole | -
|
||||
R6 | 1 | 100K Resistor | through-hole | -
|
||||
R7 | 1 | 470 Resistor | through-hole | -
|
||||
D1, D2, D3, D4, D5, D6, D7, D8 | 8 | BAT85 Diode | through-hole | -
|
||||
D9 | 1 | 1N4148 Diode | through-hole | -
|
||||
U1 | 1 | MCP3008 IC | DIP-16 | you can get these from mouser ,adafruit, even ali
|
||||
U2 | 1 | 6N138 IC | DIP-8 | -
|
||||
RV1, RV2, RV3, RV4 | 4 | 10K_LINEAR_POT | ALPHA | tayda ones work although shaft may be too short
|
||||
J1, J2, J3, J4 | 4 | 3.5MM_JACK | THONKICONN | from thonk or 50pc from modular addict
|
||||
J5 | 1 | MIDI_DIN_IN | SD-50BV | mouser
|
||||
J6 | 1 | 1X1_PIN_HEADER | - | -
|
||||
J7 | 1 | RCA_JACK | RCJ-024 | mouser or ali
|
||||
J8 | 1 | 20X2_PIN_HEADER | tall long stacking header | from [amazon] like this - the tall is needed to clear the ethernet port
|
||||
|
||||
### OPTIONAL :
|
||||
- some long enough screws and spacers note:measure these to hold it together.
|
||||
- if you want your ic's in sockets you should buy some DIP-8 /16 also now
|
||||
- if you __only__ want the _analog_inputs_ and not interested in _serial_midi_, you already have usb midi etc, then you can omit _R5_, _R6_, _R7_, _D9_, _U2_ from the BOM - see circuit schematic for details
|
||||
|
||||
## BUILD
|
||||
|
||||
start with the lowest to place components : resistors, diodes, ic's
|
||||
|
||||
next i would place the two headers since soldering from the top can be awkward with too many components - __NOTE__ these need to be placed __upside down!__ ,:
|
||||
- _J8_ needs the pins facing up from top of pcb so the screen can go ontop and raspberry pi can go underneath
|
||||
- _J6_ also needs to soldered from the top so a jumper from the pi board can be run to bottom of circuit
|
||||
|
||||
finally place the pots and jacks.
|
||||
|
||||
### rca video-out
|
||||
|
||||
if you want RCA video out from the pi on this pcb a jumper needs to be run from _J6_ to the composite video out on the raspberry pi board. on pi0 this is a labelled pin, however on pi3 you will need to solder directly to the board. i used a header-cable, cut one side to be soldered.
|
||||
|
||||
need to add some images and links to this guide !
|
||||
|
||||
[amazon]: https://www.amazon.com/2x20-pin-Female-Stacking-Header-Raspberry/dp/B071FT161B
|
||||
[these]: https://www.adafruit.com/product/2243
|
||||
@@ -1,49 +0,0 @@
|
||||
# license info
|
||||
|
||||
## software
|
||||
|
||||
i have chosen to [license] r_e_c_u_r's software under [GPL-3.0] for the following reasons:
|
||||
|
||||
- i agree with the copy-left philosophy and want to empower the users, ensuring it remains (as intended) an open community project.
|
||||
- although i have not modified any existing open-source projects to create r_e_c_u_r , it does run on top of many dependencies, some of which have GPL licenses (omxplayer in particular). i wish to respect the sentiment of these developers, even if not required legally.
|
||||
- for low-level utility tools with numerous, varied uses, a permissive open-source licence like MIT can empower other developers to create and license without restrictions. however r_e_c_u_r is an embedded top level application that is unlikely to be useful in any other context
|
||||
|
||||
this licence only applies to the code in this repo. see below for a list of external programs that r_e_c_u_r uses and their respective repos/sites for more information.
|
||||
|
||||
## hardware
|
||||
|
||||
besides the application code licensed above , i would like all original hardware designs licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License]. this includes the enclosure design , custom key stickers and assembly. it does __not__ apply to, and i am __not__ the copyright holder for _Raspberry Pi 3 Model B_ , _3.5 Inch TFT LCD Module For Raspberry Pi_ , _Generic Wireless USB Numeric Keypad_ or any other third party extension / accessory.
|
||||
|
||||
# program dependencies
|
||||
|
||||
dependency | use | licence
|
||||
--- | --- | ---
|
||||
rasbian | the os on pi | based on debian , made up of different licensed programs
|
||||
python | lanuage | open-source , gpl-compatible
|
||||
omxplayer | the media player | GPL-2.0
|
||||
omx python wrapper | for controlling omxplayer | LGPL
|
||||
dbus-python | dependency for omx wrapper | permissive, non-copyleft
|
||||
tkinter | the ui display | BSD
|
||||
picamera | interface with capture | BSD
|
||||
mido | interface with midi | MIT
|
||||
python-rt-midi | midi backend | MIT / modified MIT
|
||||
gpac (mp4box) | creating mp4 file | LGPL
|
||||
git | used to install and update | GPL-2.0
|
||||
|
||||
## some research / thoughts about how licences work and interact.
|
||||
|
||||
i have not modified any of the programs that are used in recur. they are all being used either under a permissive license or as part of the operating system. i can license my program however i choose, i can not license (for example) an img that contained gpl-2.0 programs with a non gpl compatible license.
|
||||
|
||||
there are no restrictions on selling a product under any of these licenses.
|
||||
|
||||
some [interesting discussion] around difference between modifying a gpl program and using one as a dependency ,
|
||||
- if it is part of the os it is ok.
|
||||
- if it is not 2-way interacting / sharing data structures etc - just an input -> output usage it is ok
|
||||
|
||||
there is no restrictions to permissive installer scripts downloading gpl licensed programs
|
||||
|
||||
[license]: ../LICENSE.md
|
||||
[GPL-3.0]: https://www.gnu.org/licenses/gpl-3.0.en.html
|
||||
[markings]: https://wiki.creativecommons.org/wiki/Marking/Creators/Marking_third_party_content
|
||||
[interesting discussion]: https://softwareengineering.stackexchange.com/questions/289785/can-i-distribute-a-gpl-executable-not-a-library-in-a-closed-source-application
|
||||
[Creative Commons Attribution-ShareAlike 4.0 International License]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
@@ -1,288 +0,0 @@
|
||||
# how to use r_e_c_u_r
|
||||
|
||||
## getting started
|
||||
|
||||
- prepare a usb with some videos you want to sample
|
||||
- connect the hdmi output or composite (via [3.5mm trrs]) to the display you want to use
|
||||
- power the raspberry pi. you should see red lights on the pi board, the lcd display light up and the r_e_c_u_r splash screen on your video output
|
||||
- after a few moments the interface should appear on lcd screen.
|
||||
|
||||
|
||||
## controlling the sampler
|
||||
|
||||
## controls
|
||||
|
||||
![keys][keys]
|
||||
|
||||
the controls on r_e_c_u_r work by mapping `keys` to `actions`. this map can be fully customised by editing the respective [json file].
|
||||
|
||||
the default layout uses a hard mapping for every key except the `<` - `>` - `■` in red. this means every other key triggers the same actions independent of the state r_e_c_u_r is in.
|
||||
|
||||
the _control keys_ ,`<` - `>` - `■` use a soft mapping. the action they trigger depends on the state , displayed on screen as `control_mode` in red.
|
||||
|
||||
these let you navigate and select folders, video files and settings when in `BROWSER` / `SETTINGS` mode, and by default control video playback (seek forward and back, pause/play) of the currently playing [NOW] sample in `SAMPLER` mode.
|
||||
|
||||
the display modes `SAMPLER`, `BROWSER` and `SETTINGS` are cycled by using the `DSPLY` key. (`FN + DSPLY` cycles back)
|
||||
|
||||
some actions are accessible through a _function_ layer, toggled by the `FN` key.
|
||||
|
||||
- `→` (`SWITCH`) is used to switch the [NEXT] loaded sample to the [NOW] current sample
|
||||
- loading the sample in slot `x` into [NEXT]; where `x` is a key from `0` to `9`
|
||||
- cropping the current sample to start (`[`) or end (`]`) at the current time
|
||||
- cycling forward (`PRV BNK`) or back (`NXT BNK`) through the banks of sampleS , or clearing a bank (`CLR BNK`)
|
||||
|
||||
some keys are empty to leave room for future features and user experimentation. i encourage you to modify your keymap or add custom actions you would like to use.
|
||||
|
||||
## parts of the lcd display
|
||||
|
||||
![display_image][display_image]
|
||||
|
||||
## `PLAYER` display
|
||||
|
||||
![player_example][player_example]
|
||||
|
||||
this section displays information about what is in the video player : the position from the start and the end of currently playing sample (yellow), what slot is playing [NOW] and what slot is loaded [NEXT]
|
||||
|
||||
## `SAMPLER` display mode
|
||||
|
||||
![sampler_example][sampler_example]
|
||||
|
||||
this is the main display mode for using r_e_c_u_r. from this view you can see details of all the samples loaded into the sampler. a `bank` contains 10 `slots` labelled `0` - `9`. pressing the corresponding `key` will load the `sample` in this `slot` to start when the current sample finishes. the `slot` of the currently playing sample is highlighted.
|
||||
|
||||
## `BROWSER` display mode
|
||||
|
||||
![browser_example][browser_example]
|
||||
|
||||
this is where you can load samples from your usb or internal Videos folder into the `SAMPLER`
|
||||
|
||||
- in this mode , the `<` and `>` keys will move the selection up and down
|
||||
- folders are displayed ending in `|` for closed and `/` for open , the depth is displayed as indentation
|
||||
- pressing the `■` key while a folder is selected toggles it open/closed
|
||||
- pressing the `■` key while a video is selected loads it into the next available slot (note : you can see the first slot a video is loaded into on right column)
|
||||
|
||||
## `SETTINGS` display mode
|
||||
|
||||
![settings_example][settings_example]
|
||||
|
||||
this is where you can configure r_e_c_u_r's settings.
|
||||
|
||||
- navigate the menu with `<` and `>` keys like above
|
||||
- pressing `■` on a setting will either cycle through it's `options` or run an `action` depending on its type
|
||||
|
||||
## `MESSAGE DISPLAY`
|
||||
|
||||
the bottom line shows the `control_mode` by default (what mapping the keys are currently using), but is also for displaying messages:
|
||||
|
||||
- shows a yellow bar when _function_ layer is selected
|
||||
- shows a blue bar for `INFO` messages
|
||||
- shows a red bar for `ERROR` messages - full message and trace for these can be found in the log files
|
||||
|
||||
![message_example][message_example]
|
||||
|
||||
# extensions
|
||||
|
||||
the feature set of this project has grown beyond the simple 'seamless' video player it started out as. with more options inevitability comes more complexity and confusion. feel free to try whatever extensions interest you and ignore the rest.
|
||||
|
||||
<details>
|
||||
<summary> capture </summary>
|
||||
|
||||
## capture
|
||||
|
||||
live video-input is possible for _previewing_ and _recording_. this can be enabled in the `SETTINGS` display mode. you need to ensure the capture type is set correctly : choose from `piCamera`, `piCaptureSd1` or `usb`.
|
||||
|
||||
- `piCamera` reads from raspberry pi's CSI input. it is a performant, reliable and cheap (see build docs) way to get video input into recur - note: limited to camera / rescanning
|
||||
- `piCaptureSd1` is currently the best solution for a general composite-video input to raspi. it is low latency with reasonable quality, and also handles s-video / component inputs (watch this space for possible other options to be supported)
|
||||
- `usb` ; with this setting the recur attempts to read video from an attached usb source. integration, quality and performance is less predictable but i have tried it using these [cheap ezycap] dongles with some (lofi) success.
|
||||
|
||||
|
||||
<img src="operating_examples/capture_example.jpg" width="700">
|
||||
|
||||
with `capture` enabled in the settings you can toggle _preview_ by pressing the `⦿` key. the capture input will take priority over any video-samples playing.
|
||||
pressing `FN + ⦿` will toggle sample recording. this can be enabled with or without `preview` on. the state of capture is displayed on the `PLAYER` display between the NOW and NEXT.
|
||||
after a `recording` is stopped the displayed state will be `saving..` while the raw video-footage is converted. after this the sample can be loaded from `video/internal_recordings/<date>-<count>.mp4` in _browser_. recur will automatically map new recordings to your current bank if there is space
|
||||
|
||||
NOTE: for users of _piCaptureSd1_: please ensure you have the composite video source active and plugged in to the HAT __before__ powering on recur. there seems to occasionally be issues with recognizing the hardware otherwise and a reboot is required.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>user-inputs</summary>
|
||||
|
||||
## user-inputs
|
||||
|
||||
the _usb-numpad_ is a convenient way to manually trigger __discrete actions__ within recur (any usb-keyboards can also be used). this is fine for basic sample loading and switching however more advance features benefit from __continuous control__ of parameters.
|
||||
this is where alternative user-input options are useful.
|
||||
(another use is to sequence recur using external gear)
|
||||
|
||||
<img src="operating_examples/midi_example.jpg" width="700">
|
||||
|
||||
### usb-midi
|
||||
|
||||
this is by far the easiest way to control recur externally / with continuous control. plug a controller into one of recurs existing usb-sockets and set _midi_ to __usb__ in the `SETTINGS` display mode. you should see a message with the name of your device pop up. the [midi-map] can be configured in the same way as key-mappings.
|
||||
|
||||
### i_n_c_u_r pcb
|
||||
|
||||
for anyone interested in a diy 'standalone' solution i designed a pcb that allows continuous control via `analog input` (four knobs and four 0-5v cv inputs) + `serial-midi`. see the [build guide] for more info. they can also be enabled in the `SETTINGS`
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>shaders</summary>
|
||||
|
||||
## shaders
|
||||
|
||||
fragment shaders are small text-files of glsl-code that can tell your graphics card what to show. these can be used to create your own colours, shapes and patterns on the screen. for an introduction to writing shaders i recommend Patricio Gonzalez Vivo's [The Book of Shaders].
|
||||
|
||||
recur can `load` a shader in a similar way to loading a sample, allowing you to trigger them and update their `parameters` in real time.
|
||||
|
||||
<img src="operating_examples/shader_example.jpg" width="700">
|
||||
|
||||
ensure that `shaders` is enabled in the settings and then use `DSPLY` to cycle to the `SHADER` display mode.
|
||||
here you can navigate folders and files using `<` `>` and `■` same as `BROWSER/SETTINGS`. selecting a shader (`■`) will `load` it, and pressing `FN + 6` will toggle it on and off.
|
||||
|
||||
the top line of SHADER_DISPLAY shows you the state (`stopped` and `running`), name and parameters (x_0, x_1 etc) of the current shader. beneath this is the file-menu you can use to select this current shader.
|
||||
|
||||
- `0-input`: these shaders use no input, everything you see is _generated_ by the code and graphics card
|
||||
- `1-input`: shaders can also _process_ video. when active your current output will be passed through this shader (either from a `video sample` or `capture preview`) this is similar to the _effects_ section on a v4 mixer except now you can create, customize and share them too !
|
||||
- `2-input`: allows you to perform fades, wipes and keys between two video-input sources - eg between `capture preview` and a `video sample` or even two `video samples` (see notes below on how to set this up)
|
||||
|
||||
the shader `parameters` are best controlled by _continuous inputs_ ( see user-inputs above) however can also be set by the numpad (somewhat clumsily):
|
||||
- pressing `■` on a shader will `load` it; pressing `■` on the _loaded_ shader enters `SHADER_PARAM` control mode (written in red at bottom)
|
||||
- from here you can cycle through the params with `[` and `]`
|
||||
- `<` and `>` will change the amount of the currnet param. (`FN + <` and `FN + >` will change the delta)
|
||||
- pressing `■` will exit `SHADER_PARAM` control mode back to `NAV_SHADER`
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>loop vs parallel playing mode</summary>
|
||||
|
||||
## loop vs parallel playing mode
|
||||
|
||||
recur was created to try loop videos seamlessly. it does this by using two video-players and preloading the `NEXT` player while the `NOW` is playing. this is most useful for short samples where a few frames every loop is very noticeable. however there are some situations where this is not so important: for example when working with long samples, or when a 1080p video loaded twice maxes out the pi's memory. if you do not require the seamless _switch_ there is now a new option `LOOP_TYPE` to choose between; _seamless_ and _parallel_ .
|
||||
|
||||
- `seamless` is the default behavior described above
|
||||
- `parallel` : in this mode when the current player finishes it takes a moment to load the next sample itself. there is no `SWITCH` action and pressing a `SLOT` key will start loading the corresponding sample into this player immediately.
|
||||
|
||||
<img src="operating_examples/parallel_example.jpg" width="700">
|
||||
|
||||
introducing __parallel__ mode also allows the possibility of having two different samples playing at the same time (using roughly the same amount of memory as one in _loop_ mode). to access the second (`NEXT`) player press `FN + ->` (player switch). you can tell which player is selected by the colour of the player bar - yellow for now, cyan for next. with _next_ player selected you can load, seek, toggle_pause the same as normal. pressing the `->` key now will 'switch' which player is displaying. (`FN + ■` can manually toggle_show for the current player)
|
||||
|
||||
other forms of _mixing_ between the two players can be done using the `2-input` shaders mentioned above.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>detour demo (frame-sampling) </summary>
|
||||
|
||||
## detour demo
|
||||
|
||||
d_e_t_o_u_r is a frame-sampler created to address some limitations of sampling with video-files (eg very short loops, instant switching, varying speed and direction). although conceived as a standalone instrument i also wanted (brave) recur users to be able to test it. this is a rough integration with basic (and confusing) ui and some crashes (a `RESET_OPENFRAMEWORKS` should recover these) use at your own risk !
|
||||
|
||||
to use detour_demo you must have continuous controls (either midi or i_n_c_u_r pcb). after enabling it in the settings you can cycle to __FRAME_SAMPLER__ with `DSPLY` key. information about the state of the program is displayed here.
|
||||
|
||||
a __detour__ is an array of frames which, when played back together, simulates video (imagine pictures in a flip-book).
|
||||
the __mix-shader__ combines _sampler-input_ (output from recur : can be a video sample playing or capture preview) with the _current frame_ from __detour__.
|
||||
|
||||
![detour_block][detour_block]
|
||||
|
||||
from the __FRAME_SAMPLER__ display:
|
||||
- pressing `FN + 7` will toggle __FRAME_SAMPLER__ mode on and off
|
||||
- pressing `■` will _toggle_play_ on the current_detour
|
||||
- pressing `->` will _toggle_record_ ; this adds the output of _mix-shader_ into the current_detour
|
||||
- pressing `FN + ->` will _toggle_record_loop_ ; this switches record between increasing the size of current_detour _or_ overwriting an existing frame in it
|
||||
- pressing `0, 1, 2, 3` will switch between different detours. for this demo the total number of frames can not exceed 500
|
||||
- you can select the _mix-shader_ type with `[` and `]` (it reads from recurs `2-input` folder)
|
||||
- `a1` (analog input 1) will mix between the _sampler-input_ and the _current_detour_ (`FN + [` and `FN + ]` are shortcuts for mix=0 and mix=1)
|
||||
- `a2` will set the _velocity_ of the detour if playing or _position_ if paused
|
||||
- `a3` will set the _start_ frame of current detour
|
||||
- `a4` will set the _end_ frame of current detour
|
||||
|
||||
<img src="operating_examples/detour_example.jpg" width="700">
|
||||
|
||||
this program uses the _mix_shader_ to select the input. there is also the option to use a `1-input` shader in this chain - either `before` the mix (only on _sampler-input_) or `after` (nice for feedbacky effects). this shader can be selected and toggled in the usual `SHADER` display.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>glossary of every setting value </summary>
|
||||
|
||||
## video
|
||||
|
||||
- __OUTPUT__ : sets the video output between `hdmi` and `composite` - it is best to siginal hdmi by booting with it plugged in, or composite with it not. this may be removed in future as it seems to cause crashes/ corruption somehow
|
||||
- __SCREEN_MODE__ : __only works for VIDEOPLAYER_BACKEND=omxplayer__ : changes how the player fits video to screen - see omxplayer docs
|
||||
- __BACKGROUND_COLOUR__ : __only works for VIDEOPLAYER_BACKEND=omxplayer__ : the colour around a video in SCREEN_MODE=letterboxd for example
|
||||
- __VIDEOPLAYER_BACKEND__ : sets _how_ recur decides to play video files. v1 only used `omxplayer` and some settings only work in this mode. v2 uses openframeworks. `ofxomxplayer` is recommended over `ofvideoplayer`
|
||||
- __HDMI_MODE__ : this sets the raspberry pi hdmi out - see tvservice - on some 1080 hdmi displays the pi dropped out and setting down the resolution `CEA 4 HDMI` was a fix, but this may be removed in future as it seems to cause crashes/ corruption somehow
|
||||
- __COMPOSITE_PROGRESSIVE__ : sets progressive flag to tvservice / config.txt. this may be removed in future as it seems to cause crashes/ corruption somehow
|
||||
- __COMPOSITE_RATIO__ : sets composite ratio to tvservice / config.txt. this may be removed in future as it seems to cause crashes/ corruption somehow.
|
||||
- __COMPOSITE_TYPE__ : sets composite type `PAL` or `NTSC` to tvservice / config.txt. this may be removed in future as it seems to cause crashes/ corruption somehow. if you find it doesnt work try setting the config.txt yourself.
|
||||
|
||||
## sampler
|
||||
|
||||
- __LOAD_NEXT__ : when in `seamless` playback mode this decides what slot is loaded into the `next` player
|
||||
- __RAND_START_MODE__ : loads the player to a random starting point
|
||||
- __FIXED_LENGTH_MODE__ : loads the player with a end point a fixed lenth from the start
|
||||
- __ACTION_GATED__ : when on the `square` key will trigger on a _press_ and _release_ - use this to only play a video while holding down the key etc
|
||||
- __RESET_PLAYERS__ : stops and unloadsboth video players. useful for running only one player in `parallel` playback mode, or if you want to free some memory shaders / some live camera work
|
||||
- __LOOP_TYPE__ : see the entry in docs above - in short `seamless` will use two players to ensure there is no gap between samples. `parallel` has a small freeze at end of each sample but allows you to use both players in parallel
|
||||
- __FIXED_LENGTH__ : sets the length the sample will play for in `FIXED_LENGTH_MODE` by tempo tapping - i never found this as usual as i imagined, maybe it needs some work...
|
||||
- __FIXED_LENGTH_MULTIPLY__ : multiplies the __FIXED_LENGTH__ above by this value. i thought it would help sync video to music but i dunno now ...
|
||||
- __FUNC_GATED__ : when on the `FN` key will trigger on a _press_ and _release_ - this is the default. switch off if you prefer to press to turn fn on and press again to turn off
|
||||
- __ON_ACTION__ : what should happen when you press the `square` key ? default is play/pause, but maybe you would rather just show/hide the sample ? or both ?
|
||||
- __ON_FINISH__ : what should happen when the current sample finishes ? default is to `SWITCH` to the next player but maybe you want 'one-shots' where the next sample needs to be triggered manually ?
|
||||
- __ON_LOAD__ : what should the opacity of a sample start as when loaded ? default is `shown` but maybe you want to trigger this manually ?
|
||||
- __ON_START__ : how should a sample be set when it starts ? default is `playing` and `shown` but ... you get the idea!
|
||||
|
||||
## user_input
|
||||
|
||||
- __MIDI_INPUT__ : `serial` is for din-midi via the rpi serial gpio pin. `usb` is for midi over usb.
|
||||
- __MIDI_STATUS__ : will give info on whether usb midi is connected. it will always be connected for serial as there is no way to tell here
|
||||
- __CYCLE_MIDI_PORT__ : in the rare case where the usb-midi device creates multiple ports but only receiving data on one of them. if you are trying to use a usb-midi device that is connecting but not working it is worth trying CYCLE_MIDI_PORT a few times and see if that helps ..
|
||||
|
||||
## capture
|
||||
|
||||
|
||||
- __DEVICE__ : enables capture and tries to connect with input
|
||||
- __TYPE__ : `PiCamera` and `piCaptureSd1` both use the raspi csi port but need different settings to be displayed correctly. `usb` tries to read input from usb - i guess it depends on the device and drivers etc - i will find more info about this in future
|
||||
- __PICAPTURE_INPUT__ : if using `piCaptureSd1` you can switch between inputs in the software
|
||||
- __FRAMERATE__ __only works for VIDEOPLAYER_BACKEND=omxplayer__ VIDEOPLAYER_BACKEND=omxplayer uses _piCamera_ whereas v2 uses openframeworks - i havent got ported all features onto of yet. i thought setting the framerate would help with rescanning crt displays. havnt really tried it yet...
|
||||
- __IMAGE_EFFECT__ : __only works for VIDEOPLAYER_BACKEND=omxplayer__ - just some fun - i think it is possible to reimplement in openframeworks...
|
||||
- __RESOLUTION__ : __only works for VIDEOPLAYER_BACKEND=omxplayer__
|
||||
- __SHUTTER__ __only works for VIDEOPLAYER_BACKEND=omxplayer__ i thought setting the shutter would help with rescanning crt displays. havnt really tried it yet...
|
||||
|
||||
## shader
|
||||
|
||||
- __USE_SHADER__ : show SHADER tab display_mode. dunno why you might want t disable it ??
|
||||
- __SHADER_PARAM__ : sets the delta when changing shader param with numpad - `FN + <` `FN + >` are shortcuts for also setting these
|
||||
|
||||
## detour
|
||||
|
||||
- __TRY_DEMO__ : shows the FRAMES tab in display_mode. if you are not using it you might want it off ?
|
||||
- __SHADER_POSITION__ : this determines _how_ the __effect_shader__ you can choose in SHADER tab interacts with the _detour_ program - `input` is how you might expect - processing the source _before_ it is passed to input of detour. `output` instead processes the result of __mix_shader__ inside the detour loop - this can create some wild feedback effects - see detour block diagram above
|
||||
|
||||
## system
|
||||
|
||||
- __UPDATE_CODE__ : tries to do a `git pull` on all the repos involved - if c++ code changes it will try to compile it. this probably isnt working so well - it wont work if any files are changed - it is quite hard to test !
|
||||
- __CLEAR_MESSAGE_BAR__ : sometimes messages get stuck - a bug i guess - this removes them
|
||||
- __DEV_MODE_RESET__ : this resets the pi with the display and a video window on the main hdmi output. useful for developing since the lcd is too small. also if you want to use the pi for other things ...
|
||||
- __RESTART_PROGRAM__ : closes recur and opens it again. useful if something broke and fast to try before a full power reset
|
||||
- __QUIT__ : stops the recur program and its dependencies
|
||||
- __SHUTDOWN_PI__ : for peace of mind - saving you from yanking the power cable. `FN + 9` is shortcut - will ask to confirm shutdown
|
||||
- __RESTART_OPENFRAMEWORKS__ : sometimes openframeworks just crashes - especially with detour - this will quickly start it again
|
||||
|
||||
</details>
|
||||
|
||||
[json file]: ../json_objects/keypad_action_mapping.json
|
||||
[midi-map]: ../json_objects/midi_action_mapping.json
|
||||
[build guide]: incur_circuit_docs.md
|
||||
[3.5mm trrs]: https://www.adafruit.com/product/2881
|
||||
[display_image]: operating_examples/display_parts.jpg
|
||||
[player_example]: operating_examples/player_example.jpg
|
||||
[browser_example]: operating_examples/browser_example.jpg
|
||||
[sampler_example]: operating_examples/sampler_example.jpg
|
||||
[settings_example]: operating_examples/settings_example.jpg
|
||||
[keys]: ./vectorfront_keys.png
|
||||
[message_example]: operating_examples/message_example.jpg
|
||||
[capture_example]: operating_examples/capture_example.jpg
|
||||
[midi_example]: operating_examples/midi_example.jpg
|
||||
[parallel_example]: operating_examples/parallel_example.jpg
|
||||
[detour_example]: operating_examples/detour_example.jpg
|
||||
[cheap ezycap]: https://www.aliexpress.com/item/32885712014.html
|
||||
[The Book of Shaders]: https://thebookofshaders.com/
|
||||
[detour_block]: operating_examples/DETOUR-block.png
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 99 KiB |
@@ -1,72 +0,0 @@
|
||||
|
||||
# signal culture + future plans
|
||||
|
||||
this is an update on the progress and new ideas as a direct result of my residency at signal culture (sept-oct 2018) and an outline of some of my future plans with this project
|
||||
|
||||
the initial hack that became recur was in response to a specific hole in my video-hardware workflow (~dec2017). the encouragement and enthusiasm for the idea on VideoCircuits was enough to motivate me to tidy and share recur_v1 on github/fb (may2018). a dozen or so people building this and talking about it was satisfying but i had no immediate plans to continue developing for it, besides maintenance, bugfixes, simple user requests etc...
|
||||
|
||||
however after being invited to a 3-week toolmaker residency in Owego NY i felt encouraged and enabled to explore some bigger new ideas for the instrument.
|
||||
|
||||
the name __r_e_c_u_r__ refers to the video sampling/looping feature at the core of this device. as the scope of what it can do is expanded, naming and organizing the (optional) extensions helps define their use.
|
||||
|
||||
## c_a_p_t_u_r
|
||||
|
||||
_an optional extension for live sampling through the pi camera input_
|
||||
|
||||
this was partially included in v1 although limited to inputs from the rpi-camera. while at SC i had the chance to try it with a piCaptureSd1 hat which allows sd video input from composite, component and svideo. some settings have been added to improve the captur image.
|
||||
|
||||
- TODO : experiment with capture from usb-webcam and cheep usb capure cards. with prob be lowfi and or laggy but also still fun.
|
||||
|
||||
## c_o_n_j_u_r
|
||||
|
||||
_an alternative openframeworks backend for extended video control and glsl-shader integration_
|
||||
|
||||
this is the largest addition from the v1 release. although omxplayer is a gpu-accelerated videoplayer that is stable and forgiving it is designed as a mediaplayer for watching films etc, not as a platform for creative coding. r_e_c_u_r can sequence omxplayer to playback samples exactly how they are (and seek etc for sublooping) .
|
||||
|
||||
openframeworks is more suited for video manipulation and opens a lot of possibilities to how the samples can be played.
|
||||
|
||||
### shaders
|
||||
|
||||
a few other projects have been based around using a raspberry pi as a visual instrument in another way - instead of focusing on video-clip playback, these play glsl-shaders, fragments of code that run directly on the gpu, allowing the creation of interesting digital visual generation.
|
||||
|
||||
although generated in real time, shader-playback is similar to video playback in that you can select a prepared source (video-file or shader-code) and perform with it - trigger when to start and stop, interact with parameters live (video start/stop/alpha/position or user defined shader parameters).
|
||||
|
||||
recur already has the ui to browse folders and files, select and map them, to display the relevant infomation, and openframeworks has the ability to load and play shaders much like you would load and play videos. this seemed like a logical and powerful extension to the sampler core.
|
||||
|
||||
## i_n_c_u_r
|
||||
|
||||
_become subject to (something unwelcome or unpleasant) as a result of one's own behavior or actions_
|
||||
|
||||
this is related to extending recurs sequencing/performability by exposing its controls to external manipulation.
|
||||
|
||||
usb-midi control over recur actions was in the v1 release including the first example of continuos inputs via midi-cc. this gives control over parameters which otherwise are difficult to interact with on a numpad alone (video/preview alpha). as the amount of control increases so does the need for continuous inputs.
|
||||
|
||||
at SC i created a circuit that allows 8 analog inputs (4 pots, 4 0-5v cv) and serial(din)-midi into recur.
|
||||
|
||||
## modulation
|
||||
|
||||
having defined these different areas of the __r_e_c_u_r__ video instrument, we also have created some powerful combinations (some are trivial/obvious like _i_n_c_u_r_ + _r_e_c_u_r_ for external sequencing of video samples, or _c_a_p_t_u_r_ + _r_e_c_u_r_ for recording live input directly followed by sampling it) others include:
|
||||
|
||||
- _i_n_c_u_r_ + _c_o_n_j_u_r_ : shaders can be written to respond in real time based on user input. usually this is in the form of the mouse-x&y position. for recur i have defined normalized parameter inputs that can be used to manipulate any portion of the glsl code. having knobs or cv control over these parameters greatly increases the playablity of the shaders.
|
||||
|
||||
- _r_e_c_u_r_ + _c_o_n_j_u_r_ : at first i was thinking of video-files and glsl-shaders as separate sources for creating video. however then i discovered how you can also _use_ a glsl-shader to process a video-file (shaders can take textures as input, one of which can be a video), leading me to make the distinction in recur between _0-input shaders_ and _1-input shaders_ .
|
||||
|
||||
- c_a_p_t_u_r_ + _c_o_n_j_u_r_ : not only can _1-input shaders_ accept video as a texture-input, they can also take texture from a live input (a camera or capture card for example). this means recur can also be used to process live video input in (almost) real time.
|
||||
|
||||
## direction
|
||||
|
||||
what started as a simple solution for seamless prerecorded video playback is starting to look something closer to the video equivalent to audios groovebox - where a (good) groovebox may include sampling, sequencing, synth-presets, audio-effects and live-input/effect-through , this new __r_e_c_u_r__ + _i_n_c_u_r_ + _c_o_n_j_u_r_ + _c_a_p_t_u_r_ may come close to a fully open, customizable and diy digital video groovebox.
|
||||
|
||||
## future plans
|
||||
|
||||
much of what is outlined above is in varying stages of development. proofs of concepts have been completed, but lots of the new (esp openframework) code is buggy and needs tidying and testing. for example my incur circuit is thrown together on perf-board and soldered straight to the pi...
|
||||
|
||||
here are some things im thinking about doing/trying from here:
|
||||
|
||||
- get this messy web of features polished enough that its worth creating a new sd img so others can flash and try these software updates out (im including a switch between omxplayer backend to retain existing functionality, and the option to try and test the more experimental openframeworks backend )
|
||||
- investigate sending external control (midi + analog readings) straight to openframeworks rather than python. this probably involves sacrificing some of the customizablity of mapping any input to any action for a performance increase (as it is i doubt my python code is fast enough to respond to eurorack without noticeable stepping...)
|
||||
- create another video demo to show these new aspects
|
||||
- create a new physical version : this time using a raspi compute board on a custom pcb for eurorack standard with cv/trigger in circuits , faceplate and using the numpad detached via wifi (probably 20hp)
|
||||
- hopefully have the software running stable enough and a buildpipe thats slightly more optimized than 'wait 9 hours for the case to print' so that small assembled runs become feasible for getting these to non-diy-ers
|
||||
- investigate the feasibility of creating even more accessible stripped version (composite only?) on the raspi0 (probably not feasible but iv been constantly surprized at what gpu accelerated sbc's can do!)
|
||||
- collaborate on creating some workshops for: _intro to video hardware instruments : some hacky open diy projects_ ...
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 74 KiB |
|
Before Width: | Height: | Size: 966 KiB After Width: | Height: | Size: 966 KiB |
|
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 46 KiB |
BIN
enclosure/vectorfront.png
Normal file
BIN
enclosure/vectorfront.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
|
Before Width: | Height: | Size: 111 KiB After Width: | Height: | Size: 111 KiB |
|
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
|
Before Width: | Height: | Size: 97 KiB After Width: | Height: | Size: 97 KiB |
|
Before Width: | Height: | Size: 71 KiB After Width: | Height: | Size: 71 KiB |
|
Before Width: | Height: | Size: 96 KiB After Width: | Height: | Size: 96 KiB |
Reference in New Issue
Block a user