Hypno 2.4-Release

Looks like the update for pi3 has been deleted from dropbox.

I’ve successfully updated my CM4 Hypno.

Is this the right thread for possible bug reports for 2.4? I can remove and/or repost elsewhere if preferred.

So far I haven’t tested much but I have found:

  1. Help mode (which has always been very hard to activate on my device) now seems to throw a small “stain” of black and white pixels across part of the output. These remain in place even when changing patches. This occurs even when Help text display doesn’t successfully activate, so it seems to know I’ve done “something” but it has only actually loaded Help Text once out of sustained repeat attempts.

2)“A Color Offset” (cc 10) and “B Color Offset” (cc 18) changes are not saved with the patch (or at least the values aren’t re-loaded when re-loading the patch). There seems to be a workaround: after changing these values, also make a change to “Color” (cc 2) and then change it back to show the preferred colors before saving.

Edit: looking back I can see that this second bug was present before. I haven’t checked the related bugs with other parameters yet, but I don’t see a reference to fixes in the Patch Notes for this release, other than diplay issues and MIDI bugfixes. Perhaps they just haven’t been addressed yet for this release.


Hypno now correctly displays on my TV in correct full-screen 16:9 resolution :slightly_smiling_face:

I initially thought it didn’t, but if I have the correct input source selected on my TV before powering up the connected Hypno, it does appear to work correctly. I know there was an ongoing issue with this, so (at least for me and my TV) this is now resolved, and I can make patches in the comfort of my living room rather than just in the studio with the projector!

1 Like

I’m installing this now. How does one enable the graphics scaling option?

Further test on the patches not saving correctly bug:

Fractal mod seems to be exhibiting the same behaviour:

  • Made a patch where fractal mod for oscillator A is the only source of movement.
  • Saved patch
  • Reload patch and it is completely static. Have to change the control on the Hypno or via MIDI again to generate the movement.

I think this is a related bug to previous “patches not saving/loading properly” reports, and looks like this hasn’t been addressed.

I’m going to continue to post bug reports as and when I find them. I’d put off getting back into Hypno as I thought the issues with parameters not saving had been identified and were being addressed, and perhaps it’s my fault for assuming this firmware would fix these bugs :confused:

Extra bug report, also previously mentioned on this forum:

  • Changing feedback type also seems to zero out the Fractal Mod value

I’d rather have the basics sorted out when it comes to patch creation, saving, and loading. There’s not a lot of point having “tighter integration with Mezzz” and what’s the use of the extra patch slots if the dang thing doesn’t actually behave as it should or save them as they appear when you create them.

1 Like

I’m also curious about this. I’m pretty sure my CM4 model is still providing a 480 signal to my TV, albeit at a 16:9 ratio. Need to test more but I’m going to leave it until after the weekend I think.

I found how to activate it in the manual


I haven’t tried it yet because I am having a little trouble installing the image. Slow process to troubleshoot too.

1 Like

I’ve been unable to install the new firmware on my CM3 Hypno so far. It gets to 99% complete, then adds another 25 minutes to the estimated completion, and whenever I come back to it the flash is failed. Going to attempt downloading the file fresh again and installing that, but if it doesn’t work I’m not sure what else to do

This flash is going really weird. After 45+ minutes of flashing it reaches 99%, gets stuck for a few seconds, and goes back to 95%. Then it climbs back up in 99% a few minutes later, gets stuck with 5 seconds left on the completion meter, and finally adds another 25 minutes to completion time. If this goes like the other flashes I’ve done it will finish with a failure after that time has elapsed. If this doesn’t work I’ll flash back to 2.3 for the time being.

Flash failed again… think the 2.4 image still needs some work. I’ve successfully downgraded to 2.3

Had a show last night. The hypno has been the main unit for most of my shows but this is the first since the 2.4 release.

Quick breakdown of what the hypno was connected to:
Hypno, usb hub, usb stick of images, vcmc, korg nanokeys studio with a widi pro bluetooth dongle.

Some things I bashed my head against:

Crashes. I crashed 6 times last night. The main thing I noticed with most of the crashes is that it happened while changing the shape on oscillator B, may also happen on A. It seemed that once it looped back to loading a image from the usb stick it would crash. This wasn’t consistent.

Midi control messing with the physical controls in a way that didn’t happen in 2.3: Random parameter changes on gain, which would throw it usually to extreme either clockwise or counter clockwise. The manual control would not change this or only would for a quick blip, then back to white. Vcmc had the parameter values limited so I dunno how this happened. It wasn’t from any controls being used as far as I could tell.

I’ve noticed that when the hypno is getting continuous messages from the vcmc it -really- wants to fight me making manual changes, or it will ignore a midi cc until I set it manually to whatever the “base” value of the cc was. I find this hard to articulate. I mainly noticed it with the gain. Also, it would ignore a lot of manual changes on the gain when getting CC, in a way that I never had issues with when using 2.3

I’ll likely degrade the firmware back to 2.3, but will also double check all my other settings with the vcmc. Something is wrong but I can’t put my finger on it and it’s made the hypno an infuriating experience.

I have a few theories to test and wonder if the usb hub is to blame. It’s unpowered (no way to externally power it) and Is a simple 4 port unit, and the only things it would have powered is the usb stick and the widi pro.

Ok looks like I still have some work to do on this patch so I will be working on a revision this week. Thanks for your detailed reports they are very helpful.

@TrashSurgery I’m curious how youre expecting on board controls to preform when they’re under heavy modulation? The CCs control the parameters directly so anything you send will override whatever youre controlling manually by design, otherwise the MIDI would be an offset value and not direct control. Also yes gain is made to have a value pickup with the onboard knob as it always has.

Looks like there is a crash that associated with the new Multi Device MIDI implementation. I forgot to use my mutex in one of the sending functions causing crashes on fast shape switch or anytime it is getting more than one shape/feedback switch request at a time. I will get this fixed and uploaded asap.

@NoNazPete I will look into those preset saving bugs, those definitely need to be fixed, I worked on some other fixes which recalling patches with sampling was resetting parameters but looks like there are a few more.


That sounds about right. I am definitely struggling with articulating what seems so different with this update. I have to do some testing to see if I can replicate the issue.

I think before it was the manual control overriding the external modulation (at least while I handled it) but now it seems the opposite. It’s odd. If I can narrow it down or find a better way of wording it I’ll let you know.

Is the midi echo only active with the mezzz?

Part of me wonders if I prefer to have external midi -be- an offset value instead. Any chance of making that an option?

Another bug I have yet to fully test for but I think I saw was one that I have meant to describe from 2.3:

If you load up a patch or start the unit with a patch cable into the gain, it will permanently offset the gain until the device is restarted. This will cause the 12oclock middle point to be shifted to about 10oclock instead. This throws anything going up into farther extremes than expected and going down into shallower amounts. May have been fixed in 2.4 but I think I ran into it again.

Only solution I had with 2.3 was to never turn the unit on with a patch cable in gain and never load a patch where the gain/hue parameter was set to gain.
Maybe did the same thing to hue but was a lot harder to notice than gain being stuck higher.

Hey Ron, glad to know you plan to look into these :slight_smile:

On the MIDI override issue raised by TrashSurgery:

I have a strong feeling that some sort of “soft takeover” was in play when I was testing with a MIDI contoller the other day. I’ll have to re-test to confirm, but it wouldn’t have jumped out at me as odd at the time as I’m used to “soft takeover” (or “MIDI latching” or “MIDI pickup” - terminology varies). Basically I think that in general I had to move a MIDI controller dial past the current value of the parameter before Hypno responded, which I think is what you are describing. Although I am used to this happening with some other devices it would definitely impede attempts to sequence Hypno parameters via MIDI, especially when jumping between patches. MIDI latching on/off option would be great for users to select between for different use cases, as sequencers often don’t care about the MIDI feedback data. Otherwise it would be a case of ensuring that you first send the same MIDI cc value that is saved in the patch that has just loaded for whatever parameter you want to sequence, before being able to send a new value (like switching the direction of modulation from clockwise to anti-clockwise). Not sure how much work it would be to have both options available though. My first thought is that if MIDI feedback of parameter values is now a feature, the MIDI latching (soft takeover) is much less important than before, vs the ability to sequence MIDI cc changes effectively.

The midi echoes are always active not sure if thats not desirable I can definitely add an option to turn it off in the text file.

Offsets aren’t planned that can be done externally otherwise the internal Hypno states would effect midi response which I think is not desirable for precise recall. I think its the same issue with the “MIDI pickup” where the MIDI should just be an override. Or at least i think i should have it working this way reliably to start.

So yeah I agree with the “MIDI pickup” stuff but I’m gonna focus on the other issues first, i agree that it should probably apply to midi changes only but the way its coded right now is not very easy to change this.

I did try recreate the startup cv issue you mentioned @TrashSurgery but I havent been able to figure out why this is happening yet.

Another bug, experienced only once:

  • I had removed a USB memory stick while hypno was running (a patch using internal oscillators only). Hypno continued running fine.
  • I powered down the Hypno, waited, reinserted the USB memory stick, then booted it back up.
  • Hypno loaded my first patch as usual, except… It was offset by a few degrees. Maybe 10 degrees or so anti-clockwise. I can’t remember which oscillator or if it was both.
  • I flipped between my various saved patches, many of which featured straight lines or boxes parallel with the sides of the screen.
  • Every single patch loaded the same way, rotated noticeably by the same amount in the same direction.

I reboot Hypno again and everything was fine :man_shrugging:

Was there “smoothing” done to the midi? I’m playing with the hypno right now without anything else plugged in or controlling it. Maybe it’s just me but it seems “smoother” than I recall, which makes me wonder that if there was any smoothing (maybe that’s what midi rescanning means in the patch notes?), perhaps that is why I seem to be fighting with it when it’s receiving continuous midi and I make a manual change.

Just theories. No idea if you made a change in that which could effect what I’m talking about. I still have to try and get a video, but I am swamped with work

Another bug found, maybe already mentioned.

Oscillator A loses it’s color hue parameter whenever the shape is changed, either on osc a or b. This does not happen with oscillator B.

Oscillator A loses it’s color hue parameter whenever the shape is changed, either on osc a or b. This does not happen with oscillator B.

I cant seem to recreate this one, perhaps Ive already patched it out in my dev version…

Theres also a not yet reported bug where midi input is paused for some reason when toggling shapes/modes, I will definitely be trying to get to the bottom of this also.