Patch saving bugs

Hey Everyone,

Recently I purchased a hypno. Crm4 prebuilt. Absolutely loving it.
Using a digitakt to midi control it and using some other gear for cv.

Now… I have noticed several bugs so far and have crashed many times. Usually the crashes have something to do with an incompatible file type so that’s not my worry.

My main worry is… preset saving. Lots of my patches don’t save exactly as they were when I saved them. This is especially the case for any patches that are using video or images from a flash drive.

Y offset and scrolling NEVER save. They are always reset upon loading a patch containing a image or video. This has become intensely frustrating, as I need those parameters saved for successfully loading up the patches as intended.
Ontop of that, individual shape hues also seem to not save to presets, and sometimes a preset will load with the rotate SLIGHTLY adjusted and then snap back to base level after 3 seconds. Bizarre, as I am saving the patches with those parameters at starting position anyways.

Something else I have noticed which frustrates me: When a usb stick is plugged in I tend to get a frame rate drop. Even if I am using the internal shapes (and even if it is only one oscillator) I see a chunky reduction in frame rate. If I unplug the usb stick, my frame rate jumps back up.
Also, it seems… random on if a video will have a smooth or jumpy frame rate. What I mean by that is sometimes the frame rate slows even for a video where the framerate was smooth moments before, and with the same parameters. It seems inconsistent in how well it wants to run, and the only thing that seems to reset this (and randomly roll the dice on performance) seems to be taking the usb stick out and putting it back in.

All of this is odd, and admittedly I’d love to find a solution to it. I really want to be able to use videos and pictures to really get the most out of the unit, however with how unreliable it has been in both patch saving and performance… I can’t see myself doing so.

Also: Are the pots and faders really such a low resolution? If I adjust a knob slowly, often I will get NO change unless I give it a little jerk. I know that a parameter “latches” until the knob gets to the last value that the parameter was set to, but often I am turning with little to no effect or getting large jumps when it does recognize some changes.

This makes fine tuning any of the parameters a chore of jumping back and forth until I hopefully land in a sweet spot that’s appropriate. It almost seems like parameter values will jump for no rhyme or reason. The value changes seem to be inconsistent and sluggish.

This also makes file navigation a nightmare. I am consistently skipping past videos and have found that I need to limit my file organization to 6 to 8 folders of 6 to 8 files so that I can even navigate it in any precise manner.

Any solutions or suggestions would be amazing. Thank you.

Thanks for your feedback ive made some notes on the above to look into this stuff. Gonna assume youre running 2.3 here. FYI in the future its best to post feedback on the patch thread so its all in one place for me when I look it back over when working on patches also that way I can track the stuff per version more easily.

Yes incompatible files may cause crashes.

Yes the angles snap to 45s so sometimes it will load slightly offset bc theres actually a window that will snap to 45 multiples to help align things wore easily.

Videos can be saved in a preset for more precise recall, the thing is that Hypno wasn’t designed to be a video sampler originally so some of this sort of workflow more of an add on rather than the focus of the UI ground up. (20/20 hindsight amirite lol)

The initial nudge is what allows the shift functions to work, a small window is necessary for the pages not to all jump when a page gets opened, such is the nature of this sort of multifunction UI w analog pots. After the bump the knobs should work in full res. This is actually why I switched to encoders on Mezzz, these are more reliable for shifting around pages. And yes there is some slew applied to all the controls to make them less jumpy, it just kinda covers u in the show otherwise things get even jumpier.

The USB stick frame rate drop even when not displaying it is a bug ive got on my list to investigate I think the video is continued to be decoded in the background when not visible which is incorrect.

As for other frame rate inconsistency please make sure youre running the full 2.5A or more on the 5v rail and ofc running in hotter ambient temps you will get worse performance.

Challenge of Hypno hardware overall is squeezing all these params into the analog pot UI (and the very limited performance of the CPU/GPU) w power supply differences theres a number of things that have to go on under the hood to overcompensate a bit for the potential of noisy supply, this issue is doubly troublesome with CV inputs.

Thanks for the response Ron!

I am using the crm4 with 2.3 firmware.

“Videos can be saved in a preset for more precise recall, the thing is that Hypno wasn’t designed to be a video sampler originally so some of this sort of workflow more of an add on rather than the focus of the UI ground up. (20/20 hindsight amirite lol)”

I am definitely saving videos to a preset. It’s the fact that the y axis panning (both in modulation and static) doesn’t save at all. Is that a bug that is recognized or is that unusual for the current firmware?

Is there a way to increase or decrease the amount of internal slew via editting a config file or something?

“As for other frame rate inconsistency please make sure youre running the full 2.5A or more on the 5v rail and ofc running in hotter ambient temps you will get worse performance.”

Here’s an oddity. My hypno won’t work with usb c to usb c cables / power adapters, even though they’re 5v 3amp. Oddly enough, it -will- work perfectly fine with usb-a to usb-c. I think I’m going to order a dedicated supply for it however.

Looking forward to the next firmware update whenever that is!

Yeah USB-C is a messy thing, for the schem I copied the basic setup that is the same as the PI4 to keep things consistent which is annoyingly not working with C to C cables apparently. I can recommend the official RasPi PSU or running of a USB-A port on a charged battery bank, that will definitely give you the current you need.

I will check on the Y axis pan stuff, this is actually a newer feature so its possible there may be bugs, certainly supposed to be saving.

2.4 is in the works I just havent had the time to finalize it since I’m looking for a “not working” screen setup to debug some important EDID negotiation issues with the output. Also I’m launching Mezzz rn and thats been taking most of my time lately.

No config to adjust the slew or really plans to have it adjustable, its meant to have the lowest slew possible while keeping things from jumping around and you can always add more slew externally. If you like the MIDI can jump a parameter instantly, which causes jumpiness with things like the VCMC just like it does w onboard controls with any less slew. Its a drawback of having this device be a part of eurorack/CV ecosystem while not enforcing stricter/more expensive PSU specs like LZX stuff.

I use this power supply with a usb c2c cable to power Hypno (small with lot’s of outlets).

If anyone was trying to chase down my help mode bug, forget it. I don’t believe it was happening from something on your end. The new Pi 4B has my Hypno running flawlessly now.

I got to the bottom of the Y things not setting that was definitely a sneaky bug,

also on the usb-c end I noticed that PI4’s port works with more USB-C cables apparently so a work around to using certain PSU could be using the side port instead of the top port, not sure why…

seems to be a shortcoming of the schematic but its too late to change it now :confused:

Ah, I have the crm4 version so it doesn’t have the side port!
However I got a dedicated power supply, so I know the unit is getting proper power now!

With that Y axis bug (i assume you solved both the y axis and the y axis modulation?), I assume the solution will be inplemented in the next firmware update? :slight_smile:

Really looking forward to that one being fixed!