Friksel

That's another great illustration of the problem.

Sorry, although I understand where you're coming from, I have a different opinion like described above. When mixing colors I want to see the result of the COLOR output. Not the opacity, nor the noice. Because we are not mixing opacity and neither are we mixing noice. And it could also never show you a preview of a blending mode, because it the color is not always bound to a single object. Which could also have a high effect on the result.
Also your suggested color behaviour previews are not as supposed to be; when you have half-transparent/half-opacity red, it's not pink. Only in your preview it becoms pink, because of the white background that's affecting it. But the underlying layer could as well have a much different color, like green. And than you don't mix pink with green, but still red with green. Again; opacity has nothing to do with the color channels (at least it shouldn't!!).
If we would like to see transparency we should have a better opacity slider in the UI, as discussed in the other thread. If we would like to preview both opacity and noice than add a new preview view somewhere in the interface, but please don't change the colormix output preview to something else than what it's supposed to do: preview the mixed COLOR. Opacity has nothing at all to do with the color channels. At least it shouldn't.

When we set our colors to, like, full red in the color panel, the color preview displays full red as expected.
But when we than change the opacity, the color in the preview-circle gets lighter.
That's not what we might expect and it's actually wrong, because this color preview doesn't (and can't!!) take in account what lies underneath this color (and in what blend mode an object using this color uses is in), which would affect the mix of colors.
The color-preview circle should always display the color as a direct result of the sliders. The opacity slider should never affect this preview!
In fact, nothing else apart from the color sliders/wheel/boxes should ever change this preview, because this preview should show the result of the COLOR channels we picked!
 
No opacity:

With opacity;

Sorry, that's not what I want. I want complete paint-control over the grayscale Alpha channel.
I see now that the alpha channel is working completely different than in Photoshop. Affinity Photo doesn't let us paint directly into a channel, but let us paint in a LAYER and let us turn off channels to paint on. So we always seem to be painting on the RGB channels and the alpha channel got created automatically, instead of letting us paint on the alpha channel.
So we can indeed use the eraser to erase pixels from the RGB channels, which automatically erases the same pixels in the alpha channel, but I need semi transparent painting of pixels directly into the alpha channel and that's not possible this way. Beats me why Affinity created this totally different workflow compared to Photoshop.
BTW it seems like the info in the help doc isn't completely right either; it tells us FOR EACH CHANNEL we can fill the CHANNEL information. But that doesn't seem to be true?!
Guess painting into the alpha channel is just impossible in Affinity. Which makes me a little sad.
Will try the workaround as mentioned by @Lisbon now. Thanks @Lisbon.
Just found this thread on the forum with more people having complaints about it:
 

When 'Force pixel alignment' is turned on all drawing from that moment is snapping to whole pixels. But when you start moving those just drawn curves (all created on whole pixels) around you see they are still resulting in half pixels some times.
So I did some switching in snapping options and found out that Force Pixel Alignment isn't on top of it all (highest priority). There are certain other snapping options that still cause Designer to chose off pixels. Like 'include margin midpoints', but also other important snapping options, like 'snap to grid'. Look at this:
(for the record: ''Move by whole pixels' is turned off)

double-snapping.mp4 In my opinion this is confusing, misleading and error prone and the unexpected endresult remains hidden to designers while designing, because we (well at least I do) assume all graphics will be snapped to pixels when 'Force pixel alignment' is set to true. I place this under bugs, because I really believe designers should be able to trust that 'Force pixel alignment' will indeed force pixel alignment, and right now it's not and most of the time we don't even know it until problems occur (like blurry images as an end result we see when we finished the design and 'render' to png for example).
In the video you can see clearly the node is bing placed on a half pixel because it's prefering the margin snapping over pixel forcing. But you can only see that now while looking very closely on a zoomed-in grid of 100x100 and even a visible pixel-grid turned on. Normaly we don't work like that and need to trust Designer to always pick/snap to whole pixels if we set 'Force pixel alignment' to true. Why else would we turn that setting on and the setting is a prominent button on the UI that's different to other snapping options.
So it seems like this is causing the half-pixel issues I was having for drawing graphics. I found out that Designer has a 'pixel work' preset in snapping options that turns off all other snapping options making sure forcing to pixels works. So yes, that preset (all other snapping turned off) will probably always work with pixel work and always chose whole pixels. But if we need to turn off all snapping options just to work on whole pixels that seems a little too black and white / one or the other to me. I want to use both and consider that to be a very standard expected workflow more designers like to use; I use snapping options a lot, but I only want to enable force pixel alignment next to that as a top priority(-correction) at the end.

In my opinion force pixel alignment should always be priority over all other snapping options, so in practise I would expect Designer to fire it's snapping algorithms first and then correct the end position of those snappings to the nearest pixel when Force pixel alignment is turned on.

I don't agree with this being moved to feature requests, but that should be obvious by my post.
Next to this you explain how things are working now, but I know how things are working now. Thing is in my opinion it shouldn't work like this.
Snapping to pixels is not something we like for layouts, but to be able to have our fills on exact pixels as far as horizontal and vertical goes. That should never be influenced by other snapping tools, that are used for layout purposes. Because when they do, like Designer is working rightnow, you simple cannot rely on 'Force Pixel Alignment' as a designer, because in way too many scenarios it's just not snapping to pixels and as a designer you don't even know that it isn't working when designing, because you only see it when zoomed in or happen to know this problem.
I'm starting to wonder if people realy understand the purpose of this switch.

We can talk about all kinds of scenarios with all kind of snapping functions turned on or off, but that doesn't hit the point here. Thing is that snapToPixel should snap to pixel. Nothing more and nothing less. And right now in most snapping-configurations it is not snapping to pixels. Which I call an issue.
It doesn't matter how snapping functions are set, in the end in Force Pixel Alignment (snaptopixel) should always be applied in the end. And if a designer decided to turn on snap to the center of a curve or whatever else snapping function and that happens to result to half a pixel, then the same applies as when a user has his cursor on a half pixel: round it to a whole pixel. It doesn't matter if Designer choses the left or right one if it's exactly in the middle of 2 pixels. The only thing that matters is that it's always calculating in the same way. To either exact half pixels all chose the right side, or they always chose the left side. That way we can finally work on whole pixels as designer and use snapping options too. That is just impossible right now.
 

Not sure what you mean by 'pointing' tho. The way Wacom probably recognizes which application is currently active to switch settings to seems to be looking at the active window and find what executable filename started it. It doesn't seem to even know the path or at least doesn't seem to do anything with it. 
If it did than I wouldn't have this issue, because than it would see that designer.exe from program files (version 1) is a different designer.exe than the version 2 which is somewhere else. But it can't make a distinction between the two while the executable filenames are having the exact same names.
That's why I just renamed the filename of the version 1 designer.exe to designer1.exe. Now it sees both executables (designer1.exe and designer.exe) as two different programs and I can set different Wacom setting for both versions.
This will be a problem tho when there wille be a version 3 and Serif doesn't change away from the current v2 installer type and/or we're not able to change this filename and/or Serif is also calling the v3 executable designer.exe. Than we'll have to do something else to make this work.
So if Serif is reading along; this would be easily fixed for all Wacom users by just adding only the mayor software version in the executable filename.
So like designer-v1.exe, designer-v2.exe (not designer-v2.1.3, because than that would be Wacom configuration hell as that would be a wacom configuration per sub-version or it won't even have an application specific configuration!)
Hope this makes sense!

How are you even pointing to the Designer 2 executable? You (and other programs) should not be able to access the directory where it lives, with the current MSIX-based executable.

Bump!

@Old Bruce BTW in these type of cases it's so briliant that we can just switch to Designer, edit the same file, and go back to Photo again 😀 Real timesaver!

In Photo no, in Designer and Publisher go to View > View Mode > Clip to Canvas and uncheck it.

Your right.
I suggested merging the mask to replicate the workflow related to your question as closely as possible.
 
(To preview the mask you can press Alt + Mouse click on the mask thumbnail)

@LisbonIt can be done even easier:
Just add a mask layer to the layer and paint inside that mask layer (select the layer and hit the 'mask layer' button)! No need to merge layers. And semi transparancy is working fine too! 😀
On second thought that's perhaps even nicer to use than drawing on the alpha channel! (although being able to draw directly on the alpha channel is still a great intuitive thing to have, especially when coming from photoshop and perhaps for reasons I'm missing now... [edit] ah, I found one: when you want to work directly into the channel and don't want the hastle to create a mask from an existing channel wich already has alpha. So the mask-workaround is not ideal either...) 

 

I would like that too.
Maybe 2.0 will make it possible.
Youre welcome Friksel.

Sorry, that's not what I want. I want complete paint-control over the grayscale Alpha channel.
I see now that the alpha channel is working completely different than in Photoshop. Affinity Photo doesn't let us paint directly into a channel, but let us paint in a LAYER and let us turn off channels to paint on. So we always seem to be painting on the RGB channels and the alpha channel got created automatically, instead of letting us paint on the alpha channel.
So we can indeed use the eraser to erase pixels from the RGB channels, which automatically erases the same pixels in the alpha channel, but I need semi transparent painting of pixels directly into the alpha channel and that's not possible this way. Beats me why Affinity created this totally different workflow compared to Photoshop.
BTW it seems like the info in the help doc isn't completely right either; it tells us FOR EACH CHANNEL we can fill the CHANNEL information. But that doesn't seem to be true?!
Guess painting into the alpha channel is just impossible in Affinity. Which makes me a little sad.
Will try the workaround as mentioned by @Lisbon now. Thanks @Lisbon.
Just found this thread on the forum with more people having complaints about it:
 

New to AP,  trying to figure out how to edit the alpha channel of a TIFF file. In the Channels panel, I click Composite Alpha to make the alpha channel editable, but some tools seem to work inconsistently or not at all in the alpha channel. For example, I can select all and Fill the alpha channel with white, but not with black or gray. Same with the Paint Brush tool. And it won't let me paste into the channel, pasting with the alpha channel editable and the other channels set to non-editable, the pasted image does not go into the alpha channel. If I do fill the alpha channel with black (I don't remember how I did it once), the image disappears and and I can no longer see it. Is there a way to edit the alpha channel as with a normal layer - using fill, brush, paste, etc.? Is there a way to edit the alpha channel and still see the entire image? Better yet, is there a setting to always see the entire image, regardless of the alpha channel (Transparent Background doesn't do it)?

You can "paint" with the Erase Brush Tool ... if this is what you are looking for?

Hi Friksel
See if this workaround works for you.
Rasterise to mask a white pixel layer Add a mask and drag it to the top. Paint on the mask.

If you want to see only the alpha channel, turn off the visibility of the RGB channels.

At the end you can merge the mask (Ctrl+E) (destructive)

For some fonts problems arise in Designer in the font style dropdown. As you can see in the images below Windows shows the several types of the Bahnschrift-font the correct way, but in Designer there's only a list full of 'Regular's for this font. The font is included in the attachments.


Bahnschrift Bold Condensed.otf

@David in Яuislip
When doing this it indeed helps! The color dialog is back when changing to 200, 200 and restarting Designer.
Something was off tho, as the previous location should also've worked fine as I'm on a HD monitor (1920x1080) and it should fit perfectly within (somewhere in the bottom right). And even if it wouldn't it would've moved to the second monitor, which it didn't. So it was some weird glitch I've never seen before in all these years.
But it's working now again. And great to know these setting files now (never looked for them). And if it happens again I just reset these values again.
Thanks for your helpful response!

On Windows the windows positions are stored in Window.xml which is here for Photo
%Appdata%\Affinity\Photo\1.0\Settings
My settings show
<ColourChooser>
<X>914</X>
<Y>439</Y>
<Width>586</Width>
<Height>447</Height>
<Display>0</Display>
</ColourChooser>
you could check that the X Y positions haven't gone daft, if so reset to say
<X>200</X>
<Y>200</Y>

That's a question I usually ask in such cases too. Also that GIF only supports 256 maximum colours is a point that should be in mind. But as it seems the GIF-animation still has its fans.

… or nest them vice versa and apply a layer fx to blur the masking shape (non-destructively):

@Dan C Cool! That works! 😀
Thanks a lot for your quick and clear response Dan, even with video, wow! Very much appreciated. And I'm very happy now I don't need to rasterize these masks now! 

Hi @Friksel,
I would do the following -
Unclip the Pixel layer from the Curve layer Select the Curve Layer, then navigate to Layer > New Live Filter Layer > Blur > Gaussian Blur
This should clip the filter inside the curve layer. Adjust the Blur until you're happy with the amount Drag and drop the Curve over the thumbnail of the Pixel layer, to add this as a vector clipping mask
The filter will no longer be editable, but the image should remain unblurred. 2022-07-06 10-26-43.mp4
I hope this helps