Moving to HH6

[sm_jamieson]

HH6 has been around for a while now - it has some cool stuff including VST3 support.
I've had a look at it, but I am still using HH5 for live use.

The reason I have not moved is that I have 2 outstanding raised support issues - raised last summer.
1. SDK mouse/touch problem - after a long touch, the Pressed value gets stuck at value 1 - totally breaking my touch keyboard
2. When I close HH6, Kontakt crashes (did not on HH5) - which might not be Usine's fault - but it totally hangs up Usine needing task manager to kill it.

I have tested with the latest version 6.0.251117 and the issues are still there.

Anyone else staying off HH6 for now ?

[oli_lab]

can you send your user module code so I can have a look ?
thanx
Olivar

[sm_jamieson]

I will when I get time. The user module is compiled with the pre-hh6 sdk. But for now here is the touch/mouse bug details.

Below is some trace I have added to the Mouse multi events.

The following events are now ignored by my SDK code and not shown here:
events with shift including ssTouch
events where the button is not the Left button

[0] simonj DOWN multi 0: x=0.622748, y=0.835196, pressed=1.000000, shift=0x0, button=0x0
[2] simonj MOVE multi 0: x=0.621622, y=0.835196, pressed=1.000000, shift=0x0
[4] simonj UP multi 0: x=1.000000, y=1.000000, pressed=0.000000, shift=0x0, button=0x0
[6] simonj MOVE multi 0: x=0.622748, y=0.840782, pressed=1.000000, shift=0x0
[8] simonj MOVE multi 0: x=0.621622, y=0.840782, pressed=1.000000, shift=0x0
[10] simonj MOVE multi 0: x=0.620495, y=0.840782, pressed=1.000000, shift=0x0
[12] simonj MOVE multi 0: x=0.619369, y=0.843575, pressed=1.000000, shift=0x0
[14] simonj MOVE multi 0: x=0.618243, y=0.849162, pressed=1.000000, shift=0x0
[16] simonj MOVE multi 0: x=0.617117, y=0.849162, pressed=1.000000, shift=0x0
[18] simonj MOVE multi 0: x=0.615991, y=0.849162, pressed=1.000000, shift=0x0
[20] simonj MOVE multi 0: x=0.615991, y=0.851955, pressed=1.000000, shift=0x0
[22] simonj MOVE multi 0: x=0.576577, y=0.885475, pressed=1.000000, shift=0x0
[24] simonj MOVE multi 0: x=0.507883, y=0.974860, pressed=1.000000, shift=0x0

The above is a finger being placed on the touchscreen, held long enough to trigger the
"long touch right button" (windows-generated square appears on the screen),
then being removed (generating a couple of moves after UP due to finger slide),
and then a mouse moved over the area without any buttons pressed.

After a long press and all fingers lifted, the Pressed value gets stuck at 1,
and moving a mouse with no buttons pressed shows Pressed = 1 which cannot be valid.
The error does not happen if the initial touch is not long enough to trigger the
"long touch right button."

It seems to me that there is a bug such that after a "Long touch right button" the Pressed
value does not get correctly reset (perhaps some bad logic related to "right button was not lifted" etc.).

I had a look at the Delphi changes related to this and the idea was that you could always filter out the
ssTouch related events as if they were not reported at all.
I think the events where the Pressed is 1 and no finger or buttons down, should also
have the shift including ssTouch but it obviously does not.

The reason the MOVE Pressed is important is that is some cases secondary touchpoints never get
a DOWN, they just start getting MOVES so the Pressed then implies that the mouse has gone down.

I think in HH5 the ssTouch related events were not used at all, thus no problems like this in HH5.
Its not a option/solution to turn off windows feature (tough gestures etc.) to get around this problem.
It needs to work properly.

Thanks for your help,
Simon.

[sm_jamieson]

See
https://docwiki.embarcadero.com/Librari ... ate?v=22.1

[sm_jamieson]

OK the relevant bits of SDK code are below.
The code is compiled with the older SDK (pre-HH6) and the bug is when it is used in HH6. No bug with same module in HH5.
It is possible this would work OK if compiled in the HH6 SDK - I have other problems with that to solve, so I don't know.

To be honest, I am concerned that Usine support is dropping off - to do with the Adamson association or not I don't know.
I am a programmer myself and this should be simple to investigate - I reported this last summer !!
The recent query to to support on this issue I have got no response.
As it is I want VST3 support which needs HH6 and I cannot use it due to these problems.

The usual first stage to investigate a bug is for someone else to reproduce the problem - I don't know it you can do that.

Code: Select all

//-----------------------------------------------------------------------------
// mouse and multi touch
//-----------------------------------------------------------------------------

//-----------------------------------------------------------------------------
// MouseMove callback

void MidiKeyboard::onMouseMoveMulti(TShiftState Shift, UsineEventPtr X, UsineEventPtr Y, UsineEventPtr Pressed)
{
	int xsize = sdkGetEvtSize(X);
	int ysize = sdkGetEvtSize(Y);
	int psize = sdkGetEvtSize(Pressed);
	int size = min(min(xsize, ysize), psize);

	int i;
	char tmpstr[128];

	// return; // comment out routine for testing
	if (Shift >= ssTouch) return; // not handling higher level "touch" etc. events

	long pressnum = 9;
	for (i = 0; i < psize; i++) {
		TPrecision pval = sdkGetEvtArrayData(Pressed, i);
		pressnum = pressnum * 10 + (int)pval;
		prev_mouseDown[i] = ((pval > 0.00001));
	}

	for (i = 0; i < size; i++) {
		TPrecision xval = sdkGetEvtArrayData(X, i);
		TPrecision yval = sdkGetEvtArrayData(Y, i);
		TPrecision pval = sdkGetEvtArrayData(Pressed, i);
		
		if ((prev_mouseX[i] != xval) || (prev_mouseY[i] != yval)) {
			prev_mouseX[i] = xval;
			prev_mouseY[i] = yval;
			hadMouseCallback = TRUE;
			sdkCopyEvt(X, parEvStore[PNUM_OWNMOUSE_X]);
			sdkCopyEvt(Y, parEvStore[PNUM_OWNMOUSE_Y]);
			sdkCopyEvt(Pressed, parEvStore[PNUM_OWNMOUSE_DOWN]);
			sprintf_s(tmpstr, 128, "simonj MOVE multi %d: x=%f, y=%f, pressed=%f, mask=%d, shift=0x%x", i, xval, yval, pval, pressnum, Shift);
			sdkTraceChar(tmpstr,true);
 		}
	}
	//prev_mouseSize = size;
	//mousecount++;

}

void MidiKeyboard::onMouseDownMulti(TMouseButton MouseButton, TShiftState Shift, UsineEventPtr X, UsineEventPtr Y, UsineEventPtr Pressed)
{
	int xsize = sdkGetEvtSize(X);
	int ysize = sdkGetEvtSize(Y);
	int psize = sdkGetEvtSize(Pressed);
	int size = min(min(xsize, ysize),psize);
	int i;
	char tmpstr[128];

	// Only want left mouse button. On a long touch, windows produces a right click
	// when the touch is removed.
	//if (MouseButton != mbLeft) {
	//	return; // only want left button
	//}

	if (Shift >= ssTouch) return; // not handling higher level "touch" etc. events
	if (MouseButton != mbLeft) return; // only want left button

	long pressnum = 9;
	for (i = 0; i < psize; i++) {
		TPrecision pval = sdkGetEvtArrayData(Pressed, i);
		pressnum = pressnum * 10 + (int)pval;
		prev_mouseDown[i] = ((pval > 0.00001));
	}

	for (i = 0; i < size; i++) {
		TPrecision xval = sdkGetEvtArrayData(X, i);
		TPrecision yval = sdkGetEvtArrayData(Y, i);
		TPrecision pval = sdkGetEvtArrayData(Pressed, i);
		
		if (MouseButton != mbLeft) {
			sprintf_s(tmpstr, 128, "simonj IGNORED DOWN multi %d: x=%f, y=%f, pressed=%f, mask=%d, shift=0x%x, button=0x%x",
				i, xval, yval, pval, pressnum, Shift, MouseButton);
			sdkTraceChar(tmpstr, true);
		}
		else {
			sprintf_s(tmpstr, 128, "simonj DOWN multi %d: x=%f, y=%f, pressed=%f, mask=%d, shift=0x%x, button=0x%x",
				i, xval, yval, pval, pressnum, Shift, MouseButton);
			sdkTraceChar(tmpstr, true);

			//if ((prev_mouseX[i] != xval) || (prev_mouseY[i] != yval) || (! prev_mouseDown[i])) {
			prev_mouseX[i] = xval;
			prev_mouseY[i] = yval;
			hadMouseCallback = TRUE;
			sdkCopyEvt(X, parEvStore[PNUM_OWNMOUSE_X]);
			sdkCopyEvt(Y, parEvStore[PNUM_OWNMOUSE_Y]);
			sdkCopyEvt(Pressed, parEvStore[PNUM_OWNMOUSE_DOWN]);
			//}
		}
	}

	//prev_mouseSize = size;
}

void MidiKeyboard::onMouseUpMulti(TMouseButton MouseButton, TShiftState Shift, UsineEventPtr X, UsineEventPtr Y, UsineEventPtr Pressed)
{
	int xsize = sdkGetEvtSize(X);
	int ysize = sdkGetEvtSize(Y);
	int psize = sdkGetEvtSize(Pressed);

	int size = min(min(xsize, ysize), psize);
	int i;
	char tmpstr[128];

	// Only want left mouse button. On a long touch, windows produces a right click
	// when the touch is removed.

	// we seem to lose vital mouse ups so comment out checks for now
	//if (MouseButton != mbLeft) return; // only want left button
	if (Shift >= ssTouch) return; // not handling higher level "touch" etc. events

	long pressnum = 9;
	for (i = 0; i < psize; i++) {
		TPrecision pval = sdkGetEvtArrayData(Pressed, i);
		pressnum = pressnum * 10 + (int)pval;

		if (prev_mouseDown[i] && pval < 0.00001) {
			//sprintf_s(tmpstr, 128, "simonj ++++ MOUSE UP on touchpoint %d", i);
			//sdkTraceChar(tmpstr,true);
		}

		prev_mouseDown[i] = ((pval > 0.00001));
	}

	for (i = 0; i < size; i++) {
		TPrecision xval = sdkGetEvtArrayData(X, i);
		TPrecision yval = sdkGetEvtArrayData(Y, i);
		TPrecision pval = sdkGetEvtArrayData(Pressed, i);
		
		sprintf_s(tmpstr, 128, "simonj UP multi %d: x=%f, y=%f, pressed=%f, mask=%d, shift=0x%x, button=0x%x", 
			i, xval, yval, pval, pressnum, Shift, MouseButton);
		sdkTraceChar(tmpstr,true);

		//if ((prev_mouseX[i] != xval) || (prev_mouseY[i] != yval) || (prev_mouseDown[i])) {
			prev_mouseX[i] = xval;
			prev_mouseY[i] = yval;
			hadMouseCallback = TRUE;
			sdkCopyEvt(X, parEvStore[PNUM_OWNMOUSE_X]);
			sdkCopyEvt(Y, parEvStore[PNUM_OWNMOUSE_Y]);
			//sdkSetEvtArrayData(Pressed, i, 0.0f); // in hh6 sometimes extra touchpoints have pressed set to 1 on mouseup
			sdkCopyEvt(Pressed, parEvStore[PNUM_OWNMOUSE_DOWN]);
		//}
	}
	//prev_mouseSize = size;

	//updateKeyHits(parEvStore[PNUM_OWNMOUSE_X], parEvStore[PNUM_OWNMOUSE_Y], parEvStore[PNUM_OWNMOUSE_DOWN]);

}

[oli_lab]

Hi !
What I know is that HH6 checks more errors than HH5 use to do, so something that seemed to work OK with HH5 is detected as erratic in HH6.
the best guess would be to compile with the HH6 SDK and C++17, you'll get some errors that will help you.
cheers
Olivar

[sm_jamieson]

OK, I compiled a user module with HH6 SDK and C++17, based on the DrawBox example but with mouse multi
callbacks that output trace and draw the box if Pressed has been set in the callbacks for visual feedback.
I can post the User Module tomorrow if required.
However, there is little point. I have found the bug - not sure if its in Delphi, VCL, on in HH6.

HH5 - Trace for the end of any touch:
[836] MOVE multi 0: x=0.436029, y=0.541552, pressed=1.000000, mask=91, shift=0x0
[838] MOVE multi 0: x=0.436029, y=0.541552, pressed=1.000000, mask=91, shift=0x0
[840] MOVE multi 0: x=0.436029, y=0.541552, pressed=1.000000, mask=91, shift=0x0
[842] UP multi 0: x=1.000000, y=1.000000, pressed=0.000000, mask=90, shift=0x0, button=0x0
[844] MOVE multi 0: x=0.436029, y=0.503342, pressed=0.000000, mask=90, shift=0x0

HH6 - Trace for the end of a short tap:
[20] MOVE multi 0: x=0.470149, y=0.396552, pressed=1.000000, mask=91, shift=0x0
[22] MOVE multi 0: x=0.470149, y=0.396552, pressed=1.000000, mask=91, shift=0x0
[24] MOVE multi 0: x=0.470149, y=0.396552, pressed=1.000000, mask=91, shift=0x0
[26] UP multi 0: x=1.000000, y=1.000000, pressed=0.000000, mask=90, shift=0x0, button=0x0
[28] MOVE multi 0: x=0.470149, y=0.396552, pressed=0.000000, mask=90, shift=0x80 [ssTouch]
[30] MOVE multi 0: x=0.470149, y=0.396552, pressed=0.000000, mask=90, shift=0x0

HH6 - Trace for the end of a medium length touch:
[86] MOVE multi 0: x=0.470149, y=0.405172, pressed=1.000000, mask=91, shift=0x0
[88] MOVE multi 0: x=0.470149, y=0.405172, pressed=1.000000, mask=91, shift=0x0
[90] UP multi 0: x=1.000000, y=1.000000, pressed=0.000000, mask=90, shift=0x0, button=0x0
[92] MOVE multi 0: x=0.470149, y=0.387931, pressed=0.000000, mask=90, shift=0x80 [ssTouch]
[94] DOWN multi 0: x=0.470149, y=0.387931, pressed=1.000000, mask=91, shift=0x88, button=0x0 [ssTouch + ssLeft]
[96] MOVE multi 0: x=0.470149, y=0.387931, pressed=1.000000, mask=91, shift=0x0

HH6 - Trace for the end of a long touch:
[336] MOVE multi 0: x=0.477612, y=0.413793, pressed=1.000000, mask=91, shift=0x0
[338] MOVE multi 0: x=0.477612, y=0.413793, pressed=1.000000, mask=91, shift=0x0
[340] UP multi 0: x=1.000000, y=1.000000, pressed=0.000000, mask=90, shift=0x0, button=0x0
[342] MOVE multi 0: x=0.470149, y=0.405172, pressed=0.000000, mask=90, shift=0x80 [ssTouch]
[344] DOWN multi 0: x=0.470149, y=0.405172, pressed=1.000000, mask=91, shift=0x90, button=0x1 [ssTouch + ssRight]
[346] MOVE multi 0: x=0.470149, y=0.405172, pressed=1.000000, mask=91, shift=0x0

In Delphi - must be between HH5 and HH6, new gestures are reported in the mouse multi callbacks in addition to the normal Down, Move and Up.
The list of values is as follows (HH6 SDK does not include the new ones - ssTouch onwards - I have added them)
static constexpr UINT32 ssShift = 0x1; ///< Shift keyboard state
static constexpr UINT32 ssAlt = 0x2; ///< Alt keyboard state
static constexpr UINT32 ssCtrl = 0x4; ///< Ctrl keyboard state
static constexpr UINT32 ssLeft = 0x8; ///< Left mouse button state
static constexpr UINT32 ssRight = 0x10; ///< Right mouse button state
static constexpr UINT32 ssMiddle = 0x20; ///< Middle mouse button state
static constexpr UINT32 ssDouble = 0x40; ///< Mouse Double click state
static constexpr UINT32 ssTouch = 0x80; ///< Mouse touch screen click state
static constexpr UINT32 ssPen = 0x100; ///< Mouse pen click state
static constexpr UINT32 ssCommand = 0x200; ///< Mouse Command state
static constexpr UINT32 ssHorizontal = 0x400; ///< Mouse Horizontal state

The new gestures are reported in the onMouseDownMutli callback with the Shift flags including the ssTouch flag.
This seems to me to be a bad idea since its not a "DOWN" event - but its not unusual in UI libraries to do this.

The gestures are a whole "Click" event, reported in the onMouseDownMulti callback AFTER the finger is removed.
Therefore the "Pressed" values should never be set for these - when the gesture is reported the mouse or finger is back UP.
Once the gesture has been reported with Pressed set, the Pressed value is "stuck" and all moves including moving an
actual mouse with no buttons pressed, results in Move callbacks with Pressed set.
The stuck Pressed value is only cleared by a mouse click or a short touch.

THIS IS A BUG AND MUST BE FIXED.
My recent support email replies to Senso were ignored so I'm not sure what is going on.
This is a simple bug and any competent programmer could have figured it out.
Of course the bug could be in Delphi or in VCL rather than in Usine - I don't know since I don't have the source code.

A workaround is possible, since the problem only occurs on the primary or "0" touchpoint - and the primary touchpoint
has reliable mouse DOWN and UP callbacks - so for the primary touchpoint you could rely and these and ignore the
Pressed value in the Move callback.
Secondary touchpoints do not have reliable DOWN and UP callbacks so the Move Pressed value has to be relied on.

However, the Pressed value 1 is being passed to the mouse callbacks when no finger or button is down,
which is clearly a bug,

I can post the User Module if you are interested,

[sm_jamieson]

Ok I expect Usine will be using FireMonkey aka FMX for its UI and mouse/touch handling since it's cross platform.

To summarise the 2 bugs I have found.

1. A mouse down event with ssTouch flag is resulting in the Pressed state being set when it should not, since ssTouch events are a complete "Click" and there will be no following Mouse up event. This does not happen on HH5 since it does not include ssTouch events.

2. Secondary touch points have mouse down and move events, but no mouse up event when the finger is lifted, so the only way to know of the end of the touchpoint is by a final move event with Pressed set to zero (this seems to be reliable but not very complete). This behaviour is the same on HH5 and HH6.

I would be happy to have a look at any relevant source code to debug this if it was made available to me.

[oli_lab]

If it's a bug, the best is to talk directly with Senso.

[sm_jamieson]

I have sent the info to support@brainmodular.com as I did before. I'm not getting any response.
I do wonder if the support is dropping off. I would have thought it would improve with the association with Adamson.
A bit concerning.

[oli_lab]

I guess Senso is quite busy working on the new 7 version.
Most probably your bug will be fixed in HH7, I reckon.

[sm_jamieson]

Do you know about dates for HH7 ?
It would be funny if I completely missed out HH6.

[oli_lab]

no idea, but the beta version is quite promising, with some new interesting concepts.