preenfm Forum
PreenFM => preenfm2 and preenfm3 => Topic started by: UltraBlack on May 08, 2023, 04:38:05 PM
-
Hey there,
My PFM3 just arrived today, and I'm really excited to use it more, but there is one issue that prevents me from doing so right now: After using the synth for a few minutes, updating pixels start getting stuck on yellow. Once this starts happening, more and more pixels do the same thing, until text is barely legible. Interestingly, the pixels are only stuck in specific screens, but always around text, or where text could be.
I tried to change the TFT reinit setting to Auto, but whatever that does, it does not change anything.
Is there a way to fix this or at least work around it?
Also are there any plans for a thorough manual or usage video? I'm kinda (very) lost in the menu system.
Thanks!
Edit: The bug must be somewhere around here: https://github.com/Ixox/preenfm3/blob/40caf9b069527f135fbab60e07c481d0f88e5171/lib/Src/TftDisplay.cpp#L910
I sadly can't find out, how and where TFTActions are used, maybe because the github search is trash. I can only assume that there is an issue with the way that the TFTActions are handled. I assume, that there is some kind of cache that tries to reduce the updates, but in this case corrupts pixels in a box around any piece of text. What is even weirder is the fact that it just happens over time. The corruption starts, and more pixels just get added on top of the existing error, as if some buffer was not cleared after use...
Edit 2: I'm on firmware 996, but I also tried 999 (the effects build from that one thread).
Edit 3: I finally found where the tftactions are used: https://github.com/Ixox/preenfm3/blob/40caf9b069527f135fbab60e07c481d0f88e5171/lib/Src/TftDisplay.cpp#L357
How does this work? I can barely understand what's going on... My first guess would be, that the tftmemory is faulty, but only around text? (I did notice some glitching in the env curve editor as well, but I could only notice some at the very top of the box
Edit 4: I think I found something. The only case where "setDirtyArea" is used is whenever a character is written. Could someone build that but with "tftDirtyBits = TFT_PART_ALL_BITS;" instead of setDirtyArea?
Edit 5: Would this even work or would I end up with a screen that then only contains the updated text and nothing else?
-
Moderated : solipsvs/alien_brain is back
-
Hi,
You'll find some help to navigate through menu here:
https://github.com/Ixox/preenfm3/wiki/Quickstart
The documentation is a weak part of the pfm3.
The yellow pixel bug you described is something i've never seen.
It does not seem to be related to the TFT driver. More a hardware problem or a bad memory write somewhere that affects the char map.
Would be great if you can find steps to reproduce. Or maybe it's totaly random and can happen on any page with any sound preset ?
Are all same letters the same with the artifact ? Can you post a picture ?
The pfm3 TFT driver's goal is to update the screen only when it needs to be necessary.
The TFT is divided into several parts and only the one that is modified is sent from the pfm3 to the TFT. That's setDirtyArea() goal. If you set all dirty bits, then ALL TFT memory will be transfer and not only the one that changed.
If you want to make changes compiling the kernel is not very complicated.
Download STM32CubeIde from ST site (version 1.5.1 is garantee to work fine), and import the firmware and lib folder.
Then compiling project should work.
If you don't have a stlink programmer, you can use create_object.sh in https://github.com/Ixox/preenfm3/tree/master/scripts
to create a .bin file, upload it on the SD card and flash if from the pfm3 bootloader.
Sounds a bit complicated at first, but it's not really.
Let me know if you have any question.
-
Hey, thanks for your reply.
I already saw the github documentation, but most of the menus and abbreviations are still down to my own exploration, which is pretty hindering.
The only thing I know about how to reproduce this issue is when editing a value via an encoder in the Instrument editor. I can't quite put my finger on it, but I can only remember this happening in the Envelope editor screen. The value turns yellow, signaling that it had been edited, but after a few minutes of usage (anywhere) editing something in that menu causes pixels to start getting stuck. They start accumulating on a two pixel high bar at the top and bottom of the text area, but at random places. Continuing to edit that value increases the amount of broken pixels and spreads them over the whole text block (weirdly not the text itself). The amount of corruption dictates, how much will be corrupted on other pages.
I will share a video later, this is too hard to explain
Edit: Here is a video, sorry, I had no better camera at hand: https://chonkyrabbit.eu/files/_share/issue.mp4
I want to mention, that this yet again only happened in the ENV menu.
Edit 2: I just managed to create a patch, which pretty much immediately causes this bug to occur when viewing the ENV settings of a specific operator. LMK if you want it.
-
Thanks. That's very usefull.
Looks like drawing the enveloppe go beyound the limits and corrupt the charater map.
I cannot reproduce.
Do you use any "User" Env curve ?
Can you copy the 4 values of
Op2 Env Curve ?
(You have to press the "Env" button to select this second page.)
And also the 4 "Level" values.
-
No user envelopes for me.
Value/Level
Attack: 0.96/0.1
Decay: 3.13/1
Sustain: 2.36/1.8
Release: 1.89/0
All curves are linear
Edit: Display was garbled. Edited the values, sorry.
-
From what i can see on the video. At least Decay and release are EXP.
But anyway, if you don't have user curve, that's the more important info.
What worries me is the level of sustain : 1.8.
It should not be greater than 1.0
Do you really have 1.8 ?
If yes that can be the problem... how did you edit this value ?
Does it come with a particular preset ?
Change the 1.8 to 1.0. Save the preset (save default mixer preset if it's in your default mixer).
Reboot and see if that fix the problem.
-
I really just twisted the knob. I can take literally any of these values and bump them up to seemingly infinity.
I want to mention again, that I am not using the latest release but a build from the current codebase. maybe something changed there
The value stays like that if I save and reload the preset.
I just set the sustain value to 1.0, but I still get the same effect. Are there more values which should have a limit?
Edit: Just tried setting all of them to 1, but no luck.
Edit 2: You know, what, just try it for yourself: https://chonkyrabbit.eu/files/_share/EXPERIMS.BNK
The first "sound" is the kick with the env values freely going, and the second "sound" is that same kick with the env values limited to 1. All the weird envelopes are in OP2
Edit 3: It must be related to the values somehow. Maybe 1 is just too much as well, and only 0.99 works. No idea, I've been avoiding high numbers and had no issues so far, but maybe that is just a fluke
-
Thanks for the bank. That's helpfull.
I have no idea how you could set such value.
But i can reproduce with op2 of the first sound.
Did you write this bank ? or did you find it on the web ?
Remark :
. The second sound has also 1.8 as sustain level. The problem is the level, not time.
Env Levels cannot go above 1.
As soon as i modify the 1.8 value it goes back to 1.
. With level at 1. The problem disapear (after a reboot).
I'll fix that.
The fix will simply be to verify the level when loading a preset. Level > 1 will be set to 1.
How you get this value is still a mistery ;)
-
Yes that bank is my own.
"The fix will simply be to verify the level when loading a preset. Level > 1 will be set to 1."
Could you also make triple sure that the values cannot possibly be set higher than 1? There is a limit in the level menu, but not in the env curve menu.
Edit: Could that limiter escape be related to the encoder resolution that you can set in the options? Did you maybe use something like "if (value != max) do something", instead of <=
-
"The fix will simply be to verify the level when loading a preset. Level > 1 will be set to 1."
Could you also make triple sure that the values cannot possibly be set higher than 1? There is a limit in the level menu, but not in the env curve menu.
Edit: Could that limiter escape be related to the encoder resolution that you can set in the options? Did you maybe use something like "if (value != max) do something", instead of <=
https://github.com/Ixox/preenfm3/blob/delay_xav/firmware/Src/hardware/FMDisplayEditor.cpp#L3827
That's for float type.
I don't understand when you write : " but not in the env curve menu.".
The limits are working fine for me. 1 for level, and "Usr4" is the last value available for Env Curve.
-
With en curve I meant the way the envelope is shaped, as in the number values that you can set, not the curve type
Edit: Was gonna look and try to find a place where you might have forgotten to simply set the maximum value, but I'm having a really hard time finding what I'm searching for in your codebase. I think what you need is a unified GUI class that allows you to easily create and modify instances of various different guis (to also get rid of UI bugs with much simpler fixes, like switching the edited operator not always rendering the new waveform or, editing grayed-out values being possible). Currently, most things seem half-hardcoded in a somewhat hard to understand layout, so I can't help you with that. I would give this a try, if this whole TFT rendering wasn't so damn complicated. I have to give you credit for understanding that.
-
I don't follow you at all.
And i don't understand that :
With en curve I meant the way the envelope is shaped, as in the number values that you can set, not the curve type
Where and how do you have a max value than can be exceeded ?
The only thing i understand is that you had for some reason a 1.8 env level.
Except that i don't know how you could have that.
I must miss something obvious.
Can you create a new patch and make a quick video how you can get value higher than their maximum ?
-
Well there is already a video. I literally went into the operator edit menu, and for each one, I can just set the width and height value (center two menus of the oper/env menu) as high as I want. There is no trickery or magic anything, just twisting a knob
-
Well there is already a video. I literally went into the operator edit menu, and for each one, I can just set the width and height value (center two menus of the oper/env menu) as high as I want. There is no trickery or magic anything, just twisting a knob
In the video you modify "OP 2 Env Time" which is limited between 0.0s and 16.0s. So i don't see any problem here.
I saw in the bank that the problem come from the "OP2 Env LEVEL" (Oper - Level) (Sustain = 1.8 and should be <=1).
The 1.0 limit works for me.
Can you always go above 1.0 for the levels ? Sounds impossible to me unless i miss something.
-
yes I can always go over 1.
One thing I just noticed, is that these extreme values actually come with the bank! I created a bank specifically for my stuff and I was already weirded out by the annoying config and env setup of the default "empty" presets. The level/sustain value is actually 1.8 by default.
Edit: Interestingly, the level controls actually have an encoder limit, which works like it should
-
One thing I just noticed, is that these extreme values actually come with the bank! I created a bank specifically for my stuff and I was already weirded out by the annoying config and env setup of the default "empty" presets. The level/sustain value is actually 1.8 by default.
OK I understand :)
ALL Limits from the encoders work correctly.
The bank/preset creation has a bug and put a 1.8 in the sustain level of OP2.
Thanks, i'll fix that.
And test this value at loading to limit it to 1.0
-
Moderated : solipsvs/alien_brain is back
-
I don't know, if what you said changed his reaction in any way. If it was that bad here, I would be a little sad.
It could just very well be that what you thought to be a simple feature was in fact pretty hard to implement, and you are grumpy about it.
I can't verify any of your claims currently. Your seven posts certainly don't speak for your credibility
-
Fix in the attached 0.999a.
-
Which branch is this based on? I like the features from the delay_xav branch
Also one issue I've noticed: I can't get the PFM3 to pick up the midi clock signal from my Keystep Pro... Is there a reason for that?
-
Which branch is this based on? I like the features from the delay_xav branch
Yes, delay_xav.
That's the future master branch.
Also one issue I've noticed: I can't get the PFM3 to pick up the midi clock signal from my Keystep Pro... Is there a reason for that?
For the sequencer ? User "Ext" bottom left
For the arpeggiator ? Set Clock = Ext
For the LFO ? Set Sync = Ext
-
Thought that the firmware update would take longer... (The PFM3 bootloader takes ages to mount the sd card on my machine, for some reason) - The fix correctly limits the value max where it should be when loading the patch. I can still increase the values beyond the limit though.
I have actually set the sequencer clock to EXT, but it just does not play. If I set it to internal, it works as expected...
-
Thought that the firmware update would take longer... (The PFM3 bootloader takes ages to mount the sd card on my machine, for some reason) -
Yes mounting the SD card from the preenfm on a computer through the bootloader is slow.
I can still increase the values beyond the limit though.
You may be missing something here.
Limits are : 16.0 for the time
and 1.0 for the level.
They work as expected.
I have actually set the sequencer clock to EXT, but it just does not play. If I set it to internal, it works as expected...
Double check (maybe with a midi monitor on a computer) that you're actually sending a midi clock to the pfm3.
You should see a small '*' blinking in the top right corner of the preen display.
-
"They work as expected."
Oh I see now. That explains a lot. I was always under the impression, that the env length should also be limited to 1.
The midi clock thing is just a little weird. It does not send the midi clock until you run the sequencer, for whatever reason.
-
as I said before, the level limits work as expected. I was just under the impression that the env time could go to infinity, but admittedly never tried that out all the way