Hey there,
So I absolutely love my Hypno. However the video input mode, weather it’s usb hdmi or the composite in usb adapter or the webcam usb input or even the USB video files all have lower frame rate quality compared to the same adapters being plugged into anything else. Say an hdmi monitor, or a CRT or even using the usb in on a computer. Is the lower quality just a requirement of the RPI input being a little lower rez frame than the internal synth engine.
Basically I would love to have my LZX rack or live camera rig feed into the Hypno and use the Hypno as the final mixing etc. but the internal Hypno synth is much faster reaction time than the USB input and thus my LZX rig looks kinda funky when it’s input to the Hypno. Latency is not really a problem cause that’s just an acceptable fate.
Is there any solution for this?? I.e. configuring the RPI or Hypno program to read the USB input at say 30p instead of rhe current slower kinda stuttery 18-24 frames.
Anyways, not really a big deal, the Hypno is currently my fave tool. Just hoping to maximize what I can with it.
Thanks so much
-davey
Unfortunately I have only been able to squeeze framerates ~20fps off the UVC input and file sampling so far. It will likely improve as I keep working on the engine but for now yeah this is what it is. I also plan to try locking input/sampling frame rates at in the future (shooting to try to get a smooth 24fps) to try to keep things looking more fluid.
Keep in mind we are also sampling this texture into the shader pipeline and all the lumakey/colorizing etc. so it is not just playing back that video as is so its a bit more of a challenge than simply mixing video.
Yeh resolution is gonna be 480p since I doubt the pi will go much higher than that.
But also we are limited here by the bandwidth of the single USB2.0 PHY in the PI 3/CM3 but i’m not sure if this situation is improved on the pi4’s new PCIe connection (which leads tot he USB hub chip on pi4) since I have yet to thoroughly re test capture cards on there, especially usb 3.0 cards.
1 Like
Right on, thanks so much for the reply! yeah that makes sense. It seems like even just in RPI stock OS a lot of people experience the webcam UVC being at a lower frame rate, so i think its just a struggle with the RPI architecture to begin with. I will mention that I am currently using the RPI 4b and every test I have mentioned where I plug in the USB/hdmi/analog/files, I always do it through the USB 3.0/blue plug.
So with no modifications to Hypno 2.2.3 code it does not seem to improve the frame-rate at all with the USB 3.0 VS USB 2.0 and RPI 4.
I found this coder who seems to propose that there is a solution to this. What are your thoughts on this??
Would this be possible?
Does this seem like something that may help you in your coding?? Or perhaps, some of us DIY’ers could test out??
not sure, but I figured I would post it here anyways.
Regardless, I really love the hypno as it is, and I really love incorporating the UVC input and feeding that input back and also feeding from the 2nd oscillator. It’s magical. And any future updates on this frame-rate would be legendary!
Thanks so much for your time and hard work Ron, we all really appreciate your efforts! and hopefully soon, I’ll be buying my second hypno.
1 Like
quick side question
is there a way to enter the RPI Desktop GUI from Hypno’s Flashed IMG software??
just curious if i could plug in a keyboard and mouse and have the terminal pulled up to try these UVC hacks.
thanks so much!!
1 Like
Ah ok good to know about the USB3 stuff thanks.
There isn’t a way to boot in to desktop, nor is it installed on the image, for this I would suggest you just keep a different SD card, I would prefer people keep their firmware images as supplied to simplify support. A future device will be more focused on user side coding n stuff, Hypno is meant to be a more plug-n-play affair.
Honestly Hypno wasn’t even meant to sample or process video originally, I later realized it could do it so we just included it anyway.
Thanks for the suggestion above but the code already does read the camera in a separate thread. Theres some pretty complex threading going on in the engine and yeah it can always be improved further as it can be a challenge to untangle that stuff and also keep it stable without accidentally introducing race conditions n things. However so far I had trouble to get the capture thread running faster than ~20fps so I will have to keep working on that.
I’m planning to eventually code direct calls to ffmpeg instead of using libraries as it does now so I’m hoping that will greatly improve things, however thats quite the undertaking (ffmpeg C api docs are very minimal) so no timeline on that yet.
Glad ur enjoying the Hypno 
1 Like
will these sorts of updates be firmware things, or only in future hardware?
framerate locking is a software feature
1 Like
I have a similar question about the framerate when using the hdmi output. I’ve tried running that into a blackmagic ultrastudio recorder and can only get it to work at 60fps integer. Thats fine with me as I assume it just thinks its connected to a monitor at 60hz refresh rate but I’ve noticed that the recorded file seems to repeat frames within that 60fps container. I forget if there is a specific cadence to it or if its random. I only noticed because i decided to reinterpret that 60fps recorded file as 23.976 in premiere pro to see what would happen. Unfortunately the frame repetition broke the slow motion effect i was looking to achieve. Any ideas about this phenomenon? Is it just a side effect of the foundational signal from hypno being NTSC getting converted for its 1080p output over hdmi?
This is seemingly a video output framerate question so just a bit different from what was discussed above;
The graphics generation frame rate is variable based on what is happening on screen. Regardless of your recording container most of the time the Hypno engine is only outputting about ~30 fps of unique frames so slowing that down any further would make the video look like a slide show (generally this is not very good). I would recommend you slow down the modulations to get any “slow-motion” effects.
Awesome, good to know that the generated fps can be variable but the output framerate is ~30fps. If possible, I’d love to see a future firmware feature that allows the user to set a base output framerate over hdmi to something like 29.97 or 30 or something other than 60fps integer. Maybe there is a way to give the user control over the display negotiation?
I’m capturing in ProRes 4444 to get a file saved in RGB colorspace instead of YUV 422. Seems like wasted bitrate because it essentially repeats every frame to make it 60fps since it thinks its talking to a monitor. My solution for now has been to borrow a cross converter and turn the hdmi signal into 29.97 before recording. The recorded file goes from 600mbps down to 200mbps which is way more manageable.
If youre looking to lock a specific hdmi mode for a specific capture card the best way to do that is via config.txt found on your firmware image.
Hypno runs on raspberry Pi so see raspberry pi’s documentation on all the available options for hdmi_group , hdmi_mode: Raspberry Pi Documentation - The config.txt file
Try not to mess with the other stuff too much unless you read up on specifically what youre doing since I tune this file specifically for the Hypno to make sure other features are all working correctly and u may accidentally break things.
Oh wow its like a config file for a video game. That’s awesome! Thank you for the information.
1 Like
Hey there, I was curious if there’s been any frame rate advancements since this thread. I love processing sampled video clips through the feedback modes as is, but it’d look much better if I could get a smoother frame rate.