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:
- 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.
Improvements:
Hypno now correctly displays on my TV in correct full-screen 16:9 resolution 
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 
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.
2 Likes
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 
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 
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.