mirror of
https://github.com/cyberboy666/r_e_c_u_r.git
synced 2025-12-11 19:00:04 +01:00
Merge branch 'master' into signalculture
This commit is contained in:
langolierz
23
README.md
23
README.md
@@ -3,16 +3,20 @@
|
||||
|
||||
![vectorfront][vectorfront]
|
||||
|
||||
__r_e_c_u_r__ is an embedded python application on _raspberry pi3_ that uses `input` from a _keypad_ to control omxplayer's `video out` while displaying a simple text ui on a _rpi lcd screen_
|
||||
__r_e_c_u_r__ is an embedded python application on _raspberry pi3_ that uses `input` from the _keypad_ to control omxplayer's `video out` while displaying a simple text user interface on the _rpi lcd screen_
|
||||
|
||||
## in-depth video demo
|
||||
|
||||
[![video-walkthrough][video-thumbnail]](http://www.youtube.com/watch?v=FKKDr7pLpp0)
|
||||
|
||||
## features
|
||||
|
||||
- seamlessly loop video through rpi's HDMI or composite out
|
||||
- intuitively _browse_ video files on an external usb or internally and map them into __r_e_c_u_r__
|
||||
- intuitively _browse_ video files from external and internal disk and map them into __r_e_c_u_r__
|
||||
- load and trigger video samples from numbered slots in the _sampler_ bank
|
||||
- dynamically set and clear the start/end points of each sample as it plays
|
||||
- control and sequence all inputs and more with midi-usb
|
||||
- optional extention for live sampling through the pi camera input
|
||||
- c_a_p_t_u_r : optional extension for live sampling through the pi camera input
|
||||
- many sampler modes for varied playback including: repeat, one-shot, gated, random, fixed-length, random-start and more
|
||||
- exhaustive and extendable _settings_ menu to suit your use
|
||||
|
||||
@@ -24,7 +28,7 @@ i started a [board] of some features i would like to explore
|
||||
|
||||
- *Affordable* : reducing the entry cost to performing with video
|
||||
- *Extendable* : laying the foundations (of a user interface and code style) that can be easily iterated on by the community
|
||||
- *Simple* : easy to operate (abstracted completely from ‘driving’ a raspi ) , easy to build (no technical computer install-y or circuit-y knowledge required to diy) , easy to develop (human readable code, inviting amatuer/first time coders to contribute)
|
||||
- *Simple* : easy to operate (abstracted completely from ‘driving’ a raspi ) , easy to build (no technical computer install-y or circuit-y knowledge required to diy) , easy to develop (human readable code, inviting amateur/first time coders to contribute)
|
||||
|
||||
## documentation:
|
||||
|
||||
@@ -34,17 +38,20 @@ i started a [board] of some features i would like to explore
|
||||
|
||||
## status
|
||||
|
||||
The nature of this project is to be open-ended and community driven. my r_e_c_u_r already solves the problems i intially built it for. what happens next depends on how it is used and recieved by you. if you like the idea please consider getting involved.
|
||||
The nature of this project is to be open-ended and community driven. my r_e_c_u_r already solves the problems i initially built it for. what happens next depends on how it is used and received by you. if you like the idea please let me know / get involved !
|
||||
|
||||
- the only _hardware_ option currently avaliable is the `diy enclosure`; this is designed be low cost, hackable and accessable. you can modify and 3d print/laser cut your own case, the recommended keypad and lcd parts are the cheapest i could find (with some compromises), basically aiming to get these in the hands of as many other diy-er as interested. if there is any interest i have plans to offer a limited `boutique enclosure` option at some point - professional custom cut aluminum cover , hand wired mechanical keys , real vinyl printed stickers, no compromises! (another future idea : a eurorack version based on raspi3 compute)
|
||||
- the only _hardware_ option currently available is the `diy enclosure`; this is designed be low cost, hackable and accessible. you can modify and 3d print/laser cut your own case, the recommended keypad and lcd parts are the cheapest i could find (with some compromises), basically aiming to get these in the hands of as many other diy-er as interested. if there is any interest i have plans to offer a limited `boutique enclosure` option at some point - professional custom cut aluminum cover , hand wired mechanical keys , real vinyl printed stickers, no compromises! (another future idea : a eurorack version based on raspi3 compute)
|
||||
|
||||
## contact and donation
|
||||
## contact, donation and thanks
|
||||
|
||||
langolierz@gmail.com
|
||||
|
||||
all feedback is apreciated. if you want to donate to this project you can do so with the above email via paypal : everything i receive will go into making __r_e_c_u_r__ better.
|
||||
also facebook user group : https://www.facebook.com/groups/114465402691215/
|
||||
|
||||
all feedback is appreciated. if you want to donate to this project you can do so with the above email via paypal : everything i receive will go into improving __r_e_c_u_r__. cheers to Leo Browning for the 3d modelling and vector art and to Ben Caldwell for heaps of help with the code!
|
||||
|
||||
[vectorfront]: ./documentation/vectorfront_keys.png
|
||||
[video-thumbnail]: ./documentation/video-thumbnail.jpg
|
||||
[board]: https://trello.com/b/mmJJFyrp/feature-ideas
|
||||
[operating]: documentation/operate_docs.md
|
||||
[building]: documentation/build_docs.md
|
||||
|
||||
@@ -4,6 +4,8 @@ disclaimer - this is a cheap and diy approach to getting a r_e_c_u_r video sampl
|
||||
|
||||
## 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:
|
||||
@@ -24,6 +26,8 @@ other bits and pieces:
|
||||
|
||||
- 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 ...)
|
||||
@@ -32,15 +36,15 @@ other bits and pieces:
|
||||
|
||||
## put it together
|
||||
|
||||
- using [etcher] (or otherwise) flash the micro sd with my [modified image] of rasbian (or follow these [instructions to install] from scratch.)
|
||||
- using [etcher] (or otherwise) flash the micro sd with my [modified image] of raspbian (or follow these [instructions to install] from scratch.)
|
||||
|
||||
- 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 ontop of the pi. (some little spacers could be used to support the top corners of the screen)
|
||||
- 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.
|
||||
- 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
|
||||
|
||||
@@ -58,6 +62,8 @@ you are done ! wasnt that easy ?
|
||||
[bottom]: ./baseplate.stl
|
||||
[key stickers]: ./keystickers.svg
|
||||
[etcher]: https://etcher.io
|
||||
[modified image]: https://drive.google.com/file/d/1nUR2u-75oxgvVScTUb_DrJdZZpJJqyKc/view?usp=sharing
|
||||
[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
|
||||
@@ -1,10 +1,10 @@
|
||||
# hdmi drop out bug
|
||||
|
||||
some time between when i did compatablitiy testing , and now - high res videos now often (and conistently cause hdmi drop outs. all 1080 do , and some 720 also) - on my hdmi-to-vga computer display.
|
||||
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 (possiblely related) when trying it on full hdmi projector, it drops out playing all video no matter the resolution ! whats going on ?
|
||||
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 sugests that not enough power can cause this problem.
|
||||
some research suggests that not enough power can cause this problem.
|
||||
possible fixes / things to rule out include :
|
||||
|
||||
- trying signal-boost in config
|
||||
@@ -29,8 +29,14 @@ some research sugests that not enough power can cause this problem.
|
||||
- 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 dependacies , still running old code :
|
||||
- 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...
|
||||
|
||||
# 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.
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
|
||||
# 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** .
|
||||
@@ -19,8 +22,8 @@ clip | expectation | results
|
||||
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 reconise codec
|
||||
1080-mkv-h264-60mbps.mkv | dont expect this to work | suprizingly 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-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
|
||||
|
||||
@@ -38,5 +41,5 @@ UPDATE: turns out the 1080 files couldnt load because the pi hadnt been assigned
|
||||
|
||||
# summary of findings :
|
||||
|
||||
- .mp4 containers witht 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.
|
||||
- .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...
|
||||
|
||||
@@ -6,9 +6,63 @@ i believe it is possible to read midi in from an i/o pin (that can read serial)
|
||||
|
||||
### 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 refferencing 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 comunicates with the pi in a similar way and that i could figure out a way to connect these extentions if desired.
|
||||
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
|
||||
[mcp3008]: https://learn.adafruit.com/raspberry-pi-analog-to-digital-converters/mcp3008
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
## firmware bug
|
||||
|
||||
at some point i must have updated the raspi firmware. this caused the recur application to present a bug that makes it basicly unusable:
|
||||
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
|
||||
|
||||
@@ -12,7 +12,7 @@ the video freezes / lags often , usually at the same spot : 10s in, 2minutes in
|
||||
|
||||
- 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 vesrion (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 !
|
||||
- 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)
|
||||
|
||||
@@ -28,6 +28,6 @@ now `uname -a` reads `.. 4.9.60-v7+ #1048 .. Fri Nov 3` and the player still wor
|
||||
|
||||
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 lastest firmware version and by adding `audio_pwm_mode=0` to the config it now plays as before . phew what a relief !
|
||||
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.
|
||||
|
||||
@@ -2,23 +2,23 @@
|
||||
|
||||
### 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 - usally to be played back again imedantly as part of a performance.
|
||||
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 possiblity of this with recur. some ways to record video into recur include:
|
||||
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 protical
|
||||
- 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 plausable, and hopefully will be interchangable 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 addation) and i can start experimenting now with a cheep cam before investing in the expensive piCapture.
|
||||
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 plausable it would be to add live sampling to my current recur stack (gpio lcd screen, omxplayer video backend).
|
||||
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:
|
||||
|
||||
@@ -35,7 +35,7 @@ some things i want know are:
|
||||
|
||||
### research
|
||||
|
||||
[cheep cameras] for raspi can be bought from china with 5 mega pixals / 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.
|
||||
[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.
|
||||
|
||||
@@ -48,14 +48,14 @@ $ 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 - atleast 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)" )
|
||||
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 advantange of the pi's hardware accelaration. it comes as a 'hat' that also uses ic2 (or serial)
|
||||
to comunicate. there is a python package to access these addational options.
|
||||
[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 :
|
||||
|
||||
@@ -82,7 +82,7 @@ besides that the preview / different parameters and effects work as expected. ne
|
||||
|
||||
i have installed `sudo apt-get install gpac` and am using `subprocess.Popen` to run the `MP4Box` command from inside python. this way i can poll back into it and map the video only when its finished converting to stop blocking in the meantime. i also updated the display to show when the camera is previewing and recording. this all worked smoother than i expected.
|
||||
|
||||
i also made a (suprizingly small) change to the browser to show the pi's videos folder next to the external devices. this will be useful for using the recordings saved and for copying files onto recurs disk. (the copying feature has been depriotised since it can be done manually with mouse/keyboard and could be risky / might want a confermation window ...)
|
||||
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.
|
||||
|
||||
@@ -18,9 +18,6 @@ something seems wrong with the dongle. it also seems like these cheep dongles ar
|
||||
|
||||
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.
|
||||
|
||||
### 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...)
|
||||
|
||||
### usb midi
|
||||
|
||||
@@ -37,17 +34,17 @@ besides the obvious triggering of clips and controlling parameters, it has also
|
||||
i install mido and rtmidi for backend : `pip3 install mido python-rtmidi`,
|
||||
i called `mido.get_input_names()` and searched the results for the first containing the substring `20:0` (this is the port my devices came up as - will need to investigate further why this is and if it will be the case for all external usb midi devices)
|
||||
|
||||
from here i called a polling meathod that reads the next message coming from that port and if there is one will call into the mapping function (from json file)
|
||||
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 corrosonding action on recur. even when pressing keys with the sequencer running (lots of clock messages being sent) it still responds quickly and consistantly. however when triggering the same notes from the sequencer, it seems to drop lots on the notes : usaully only picking up either note_on or note_off , sometimes both and sometimes neither.
|
||||
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.
|
||||
|
||||
### futher clock debugging
|
||||
### 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
|
||||
|
||||
@@ -55,9 +52,9 @@ other things to try is learning how to use abelton as a midi controller and see
|
||||
|
||||
besides figuring out whats up with the incoming clock signal , another thing to experiment with is using a cc knob to control parameters in recur. there is nothing pressing i want for this but could try it with : fades , speed? , length of seeks , seeking?
|
||||
|
||||
i ended up trying cc with some camera paramters. there are plenty more interesting examples of continuous control there. it works well , but it seems like running the methods on every change when they are sequenced / coming in consistantly is a bit much for recur to respond in real time.
|
||||
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 revist when other features are under cv control etc.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -7,29 +7,29 @@ a collection of thoughts / research / attempts at porting r_e_c_u_r
|
||||
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 dependancies outlined in the [preparing image] notes and maybe some fiddling with the lcd-screen drivers...
|
||||
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 preinstalled 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 dependacies, 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)
|
||||
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 dependancies are avaliable 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:
|
||||
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] decribes 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
|
||||
[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 accelaration of these alternative boards
|
||||
- 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
|
||||
liencing things etc might come into it
|
||||
- configuring different hdmi and composite video settings. (pi seems to do this partitulary well)
|
||||
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 flexiblity.
|
||||
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 :
|
||||
|
||||
@@ -37,12 +37,12 @@ r_e_c_u_r is an embedded solution and the choice of hardware (raspi3) is tied to
|
||||
- omxplayer w acceleration
|
||||
- (future features using pi camera / capture devices)
|
||||
|
||||
right now rpi3 still seems like the best tool for the job and the benfits of running cross-boards are
|
||||
not enough to distract from improving this implementaion. (perhaps a future recur independant of omxplayer might benifit more from running on main debian / armian)
|
||||
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 hopefull 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.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
65
documentation/faq.md
Normal file
65
documentation/faq.md
Normal file
@@ -0,0 +1,65 @@
|
||||
|
||||
# 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.
|
||||
|
||||
## 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 experence 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_files/keypad_action_mapping.json
|
||||
[develop page]: /documentation/develop_docs.md
|
||||
[build]: /documentation/build_docs.md
|
||||
|
||||
@@ -5,10 +5,10 @@
|
||||
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 particluar). i wish to respect the sentiment of these developers, even if not required legally.
|
||||
- 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 infomation.
|
||||
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
|
||||
|
||||
@@ -22,7 +22,7 @@ rasbian | the os on pi | based on debian , made up of different licensed program
|
||||
python | lanuage | open-source , gpl-compatible
|
||||
omxplayer | the media player | GPL-2.0
|
||||
omx python wrapper | for controlling omxplayer | LGPL
|
||||
dbus-python | dependacy for omx wrapper | permissive, non-copyleft
|
||||
dbus-python | dependency for omx wrapper | permissive, non-copyleft
|
||||
tkinter | the ui display | BSD
|
||||
picamera | interface with capture | BSD
|
||||
mido | interface with midi | MIT
|
||||
@@ -32,15 +32,13 @@ git | used to install and update | GPL-2.0
|
||||
|
||||
## some research / thoughts about how licences work and interact.
|
||||
|
||||
it will be best to replace the mscorefonts with something open...
|
||||
|
||||
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 compatable license.
|
||||
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 dependancy ,
|
||||
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 datastructures etc - just an input -> output usage 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
|
||||
|
||||
|
||||
BIN
documentation/video-thumbnail.jpg
Normal file
BIN
documentation/video-thumbnail.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
Reference in New Issue
Block a user