Hi, it's no longer possible to use current develop with VSTGUIEditor from vst3_public_sdk.
I believe the enum class modification broke it at commit 1490ad5.

The location of the error in VST3:
https://github.com/steinbergmedia/vst3_public_sdk/blob/a395ed998bfee1969d623c15a5825160de7fd32c/source/vst/vstguieditor.h#L69

These seem like they're the wrong way around:

The algo template has parameters:

template <int32_t redPos, int32_t greenPos, int32_t bluePos, int32_t alphaPos>
	void algo (...

However kARGB/kABGR, it uses algo<0, 1, 2, 3>, and for kRGBA/kBGRA it uses algo<1, 2, 3, 0>. These don't match up.

I investigated this because the blur filter was behaving oddly for me (on Mac) - it was leaving the blue channel un-blurred.

When I swapped the pixel-orders around above, my blur works correctly for the RGB channels.

However, if the above is fixed, I expect that CShadowViewContainer will stop working. This is because the blur-filter implementation isn't designed to touch the alpha-channel at all - however, CShadowViewContainer sets the RGB to black, and then uses the blur-filter which accidentally blurs the alpha channel instead of one of the RGB channels.

A proper fix for this would require changing the blur algorithm so that it accounts for the alpha-channel as well. I think the appropriate way to implement alpha-aware blur is to premultiply the RGB, blur the RGBA in a straightforward manner, and then divide RGB by A to get the un-multiplied version.

Example: On Windows, "OCR A Extended" is an included font. If you create a font definition in the XML that uses "OCR A Extended" and assign that font to a CTextEdit, the result is that it doesn't work when displaying the CTextEdit and the default font is used instead, but when editing in the CTextEdit, the control suddenly switches to the correct OCR font. In the reverse situation, shortening it to just "OCR A" results in the intended font being used when displaying, but not when editing.

There's evidently a conflicting difference between how the Win32TextEdit and the CParamDisplay identify fonts by name.

I get a segmentation fault in cairo_scaled_font_status when I try to load the 'DejaVu Sans' font.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7074860 in cairo_scaled_font_status () from /usr/lib/libcairo.so.2

The problem seems to be that the 'DejaVu Sans' font doesn't have a 'Regular' style so the font is not created and 'impl->font' is a nullptr(see the debug printout below).
There is no null pointer guard around the call to cairo_scaled_font_status at line 269 so it is called with a null pointer and we get a segmentation fault.

backtrace:

(gdb) bt
#0  0x00007ffff7074860 in cairo_scaled_font_status () at /usr/lib/libcairo.so.2
#1  0x00007ffff30f92f0 in VSTGUI::Cairo::Font::Font(char const*, double const&, int const&)
    (this=0x5555556fd950, name=0x5555556757d0 "DejaVu Sans", size=@0x5555556757e8: 10, style=@0x5555556757f0: 0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at /home/aner/filur/gitlab/vst3sdk/vstgui4/vstgui/lib/platform/linux/cairofont.cpp:269
#2  0x00007ffff30f9ab3 in VSTGUI::IPlatformFont::create(VSTGUI::UTF8String const&, double const&, int const&) (name=..., size=@0x5555556757e8: 10, style=@0x5555556757f0: 0)
    at /home/aner/filur/gitlab/vst3sdk/vstgui4/vstgui/lib/platform/linux/cairofont.cpp:365
#3  0x00007ffff30652c3 in VSTGUI::CFontDesc::getPlatformFont() const (this=0x5555556757b0) at /home/aner/filur/gitlab/vst3sdk/vstgui4/vstgui/lib/cfont.cpp:100
#4  0x00007ffff3065351 in VSTGUI::CFontDesc::getFontPainter() const (this=0x5555556757b0) at /home/aner/filur/gitlab/vst3sdk/vstgui4/vstgui/lib/cfont.cpp:107
#5  0x00007ffff305d84c in VSTGUI::CDrawContext::drawString(VSTGUI::IPlatformString*, VSTGUI::CRect const&, VSTGUI::CHoriTxtAlign, bool) (this=0x5555556f99c0, string=0x5555556fdef0, _rect=..., hAlign=VSTGUI::kCenterText, antialias=true)
    at /home/aner/filur/gitlab/vst3sdk/vstgui4/vstgui/lib/cdrawcontext.cpp:237
#6  0x00007ffff305dc7a in VSTGUI::CDrawContext::drawString(char const*, VSTGUI::CRect const&, VSTGUI::CHoriTxtAlign, bool) (this=0x5555556f99c0, string=0x555555641528 "time", rect=..., hAlign=VSTGUI::kCenterText, antialias=true)
    at /home/aner/filur/gitlab/vst3sdk/vstgui4/vstgui/lib/cdrawcontext.cpp:290

Going up one level in the backtrace and print impl->font

(gdb) up
#1  0x00007ffff30f92f0 in VSTGUI::Cairo::Font::Font (this=0x5555556fd950, name=0x5555556757d0 "DejaVu Sans", size=@0x5555556757e8: 10, style=@0x5555556757f0: 0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at /home/aner/filur/gitlab/vst3sdk/vstgui4/vstgui/lib/platform/linux/cairofont.cpp:269
269			auto status = cairo_scaled_font_status (impl->font);
(gdb) p this->impl->font
$1 = {handle = 0x0}

Print the FontList iterator.

(gdb) p *it
$4 = {first = "DejaVu Sans", second = {styles = std::unordered_map with 9 elements = {["Book"] = {ftFace = {face = 0x0}, face = {handle = 0x0}, path = "/usr/share/fonts/TTF/DejaVuSans.ttf"}, ["Condensed Bold"] = {ftFace = {face = 0x0}, 
        face = {handle = 0x0}, path = "/usr/share/fonts/TTF/DejaVuSansCondensed-Bold.ttf"}, ["Bold Oblique"] = {ftFace = {face = 0x0}, face = {handle = 0x0}, path = "/usr/share/fonts/TTF/DejaVuSans-BoldOblique.ttf"}, ["Bold"] = {
        ftFace = {face = 0x0}, face = {handle = 0x0}, path = "/usr/share/fonts/TTF/DejaVuSans-Bold.ttf"}, ["Condensed"] = {ftFace = {face = 0x0}, face = {handle = 0x0}, path = "/usr/share/fonts/TTF/DejaVuSansCondensed.ttf"}, 
      ["ExtraLight"] = {ftFace = {face = 0x0}, face = {handle = 0x0}, path = "/usr/share/fonts/TTF/DejaVuSans-ExtraLight.ttf"}, ["Condensed Oblique"] = {ftFace = {face = 0x0}, face = {handle = 0x0}, 
        path = "/usr/share/fonts/TTF/DejaVuSansCondensed-Oblique.ttf"}, ["Condensed Bold Oblique"] = {ftFace = {face = 0x0}, face = {handle = 0x0}, path = "/usr/share/fonts/TTF/DejaVuSansCondensed-BoldOblique.ttf"}, ["Oblique"] = {
        ftFace = {face = 0x0}, face = {handle = 0x0}, path = "/usr/share/fonts/TTF/DejaVuSans-Oblique.ttf"}}}}

Print the style iterator.

(gdb) p styleIt
$5 = {<std::__detail::_Node_iterator_base<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, VSTGUI::Cairo::(anonymous namespace)::CairoFontFace>, true>> = {_M_cur = 0x0}, <No data fields>}

Hi again

Over in surge land we were seeing a strange behavior. We have a few gestures where we rebuild our entire UI (it is faster than finding the large number of components which would be invalidated). When that happens VSTGUI re-sends my component under a mouse an onMouseEntered event. Cool - that's what we want.

But in this situations we were noticing "phantom" hovers occurring when we set our zoom to something other than 100%. If we triggered a rebuild using a component at 100,100, and were zoomed to 150%, we got the mouseEnter at the 100,100 component (so got the hover) but also got it at 150,150. This had a variety of bad impacts.

Turns out the reason for this is that CFrame::checkMouseViews and CFrame::clearMouseViews don't convert the screen location using the transform, whereas the platform and all other mouse event handlers do.

To fix this I simply untransform the local coordinate with a getTransform().inverse(). Here's my patch.

Hope this helps!

Paul

diff --git a/vstgui/lib/cframe.cpp b/vstgui/lib/cframe.cpp
index 1448f527..f10204a0 100644
--- a/vstgui/lib/cframe.cpp
+++ b/vstgui/lib/cframe.cpp
@@ -351,7 +351,6 @@ void CFrame::clearMouseViews (const CPoint& where, const CButtonState& buttons,
                {
                        lp = where;
                        (*it)->frameToLocal (lp);
-         getTransform().inverse().transform(lp);
                        (*it)->onMouseExited (lp, buttons);
                #if DEBUG_MOUSE_VIEWS
                        DebugPrint ("mouseExited : %p\n", (*it));
@@ -422,7 +421,6 @@ void CFrame::checkMouseViews (const CPoint& where, const CButtonState& buttons)
        {
                lp = where;
                currentMouseView->frameToLocal (lp);
-      getTransform().inverse().transform(lp);
                currentMouseView->onMouseExited (lp, buttons);
                callMouseObserverMouseExited (currentMouseView);
        #if DEBUG_MOUSE_VIEWS
@@ -441,7 +439,6 @@ void CFrame::checkMouseViews (const CPoint& where, const CButtonState& buttons)
                {
                        lp = where;
                        vc->frameToLocal (lp);
-         getTransform().inverse().transform(lp);
                        vc->onMouseExited (lp, buttons);
                        callMouseObserverMouseExited (vc);
                #if DEBUG_MOUSE_VIEWS
@@ -472,7 +469,6 @@ void CFrame::checkMouseViews (const CPoint& where, const CButtonState& buttons)
                {
                        lp = where;
                        (*it2)->frameToLocal (lp);
-         getTransform().inverse().transform(lp);
                        (*it2)->onMouseEntered (lp, buttons);
                        callMouseObserverMouseEntered ((*it2));
                #if DEBUG_MOUSE_VIEWS
@@ -498,7 +494,6 @@ void CFrame::checkMouseViews (const CPoint& where, const CButtonState& buttons)
                {
                        lp = where;
                        (*it2)->frameToLocal (lp);
-         getTransform().inverse().transform(lp);
                        (*it2)->onMouseEntered (lp, buttons);
                        callMouseObserverMouseEntered ((*it2));
                #if DEBUG_MOUSE_VIEWS

Hi

Over in our surge use of vstgui (where we are forked to fix various bugs) we had a persistent bug with our zoomable UI. I do not think this is fixed on your branch (I usually check before I dive in to patch).

The bug was some of our controls would leave little edge shadows of a pixel or less around their edges when we were at non-100% zoom levels. For instance

I found the problem today. The problem is CFrame::invalidRect does a transform on the rect and then a makeIntegral but makeIntegral does floor( left + 0.5 ) and so on so if your transformed widget goes from left position of 192.7 then that gets pushed up to 193 when integralized.

I fixed it by

1: adding a method to CRect called makeIntegralOnlyExpanding
2: calling that, rather than makeIntegral from CFrame::invalidRect

I hope this helps you as you continue to develop and support the main branch of vstgui.

Best

diff --git a/vstgui/lib/cframe.cpp b/vstgui/lib/cframe.cpp
index 1448f527..faf8d37a 100644
--- a/vstgui/lib/cframe.cpp
+++ b/vstgui/lib/cframe.cpp
@@ -1410,7 +1410,7 @@ void CFrame::invalidRect (const CRect& rect)
 
        CRect _rect (rect);
        getTransform ().transform (_rect);
-       _rect.makeIntegral ();
+       _rect.makeIntegralOnlyExpanding ();
        if (pImpl->collectInvalidRects)
                pImpl->collectInvalidRects->addRect (_rect);
        else
diff --git a/vstgui/lib/crect.h b/vstgui/lib/crect.h
index 333751eb..33568aee 100644
--- a/vstgui/lib/crect.h
+++ b/vstgui/lib/crect.h
@@ -68,6 +68,7 @@ struct CRect
        /** moves this rect to the center of r */
        inline CRect& centerInside (const CRect& r);
        inline CRect& makeIntegral ();
+   inline CRect& makeIntegralOnlyExpanding ();
 
        CCoord left {0.};
        CCoord top {0.};
@@ -272,6 +273,17 @@ inline CRect& CRect::makeIntegral ()
        return *this;
 }
 
+// this will give you a rectangle which is integral, but also is outside the given input
+inline CRect& CRect::makeIntegralOnlyExpanding()
+{
+       left = std::floor (left);
+       right = std::ceil (right);
+       top = std::floor (top);
+       bottom = std::ceil (bottom);
+       return *this;
+}
+
+
 //-----------------------------------------------------------------------------
 inline constexpr bool CRect::pointInside (const CPoint& where) const
 {

Hi!

I was getting draw performance reports on linux from users who were interacting with the surge gui, where we use a (modified fork of) vstgui.

The problem was, basically, that I had a mouse handler calling invalidate (that's fine) but when I had a high zoom rate and fast mouse actions invalidate was called every 5us or so.

That's also fine. You run invalidation on a timer, but it's not quite fine. in x11frame.cpp your invalidate basically does a dirtyRects.emplaceBack( rect ) and then your timer handler does foreach( r : dirtyrects ) repaint.

So you can see the problem right? If you have a very high frequency mouse event all on the same object, you get a large number of redundant dirtyrects, so you paint each rect multiple times. In my testing I was getting single rects repainting 15-20 times on each invalidation because the mouse events came so quickly.

To fix that, I uniqified the rectangles before I painted. This has greatly improved the performance of every part of my UI, it seems, in my tests (and with one of our other testers). I thought the patch I applied to our branch may be useful to you also.

Best

diff --git a/vstgui/lib/platform/linux/x11frame.cpp b/vstgui/lib/platform/linux/x11frame.cpp
index 4f66d5aa..018e18a0 100644
--- a/vstgui/lib/platform/linux/x11frame.cpp
+++ b/vstgui/lib/platform/linux/x11frame.cpp
@@ -22,6 +22,7 @@
 #include <cassert>
 #include <iostream>
 #include <unordered_map>
+#include <unordered_set>
 #include <X11/Xlib.h>
 #include <xcb/xcb.h>
 #include <xcb/xcb_util.h>
@@ -311,10 +312,32 @@ struct Frame::Impl : IFrameEventHandler
                xcb_flush (xcb);
        }
 
+   struct rectHash {
+      size_t operator() (const CRect &r) const
+         {
+            // these wierd values are "about the size of a screen" and are "random enough to make non-colliding hashes probably"
+            // no further thought was given to them
+            return ((( r.top * 1873 ) + r.left) * 2721 + r.bottom) * 3143 + r.right;
+         }
+   };
        //------------------------------------------------------------------------
        void redraw ()
        {
-               drawHandler.draw (dirtyRects, [&](CDrawContext* context, const CRect& rect) {
+      // We want to uniqify the drawRects before we paint
+      std::unordered_set<CRect,rectHash> uniqs;
+      //std::vector<CRect> uniqs;
+      std::vector<CRect> newDR;
+      for( auto r : dirtyRects )
+      {
+         //if( std::find( uniqs.begin(), uniqs.end(), r ) == uniqs.end() )
+         if( uniqs.find( r ) == uniqs.end() )
+         {
+            newDR.push_back( r );
+            uniqs.insert( r );
+         }
+      }
+
+               drawHandler.draw (newDR, [&](CDrawContext* context, const CRect& rect) {
                        frame->platformDrawRect (context, rect);
                });
                dirtyRects.clear ();

Hi there,

I was getting a compilation error in vstgui4\vstgui\lib\platform\win32\wintimer.cpp because of the std::map typedef, which I fixed by including map at the top of the file. Just wanted to let you know. This was in VS2015 update 1.

I have some knobs and when I double click on them the mouse becomes sticky to them. So if I hover a knob without prior clicking on it, the knob still turns.

It seems as if the double (or even tripple) click event in GtkFrame::on_button_press_event (x11frame.cpp) is not handled correctly.

The documentation lists the sequence of events:
https://developer.gnome.org/gdk3/stable/gdk3-Event-Structures.html#GdkEventButton

I have a CViewContainer that contains another CViewContainer, which contains some view. Those views are not getting mouseDown events.

I'm pretty sure line 889 of CViewContainer.cpp has a bug:

if (result != kMouseEventNotHandled && result != kMouseEventNotImplemented)

It should probably be:
if (result != kMouseEventHandled && result != kMouseEventNotImplemented)

Hi!

In cview.cpp you have

bool CView::onWheel (const CPoint& where, const CMouseWheelAxis& axis, const float& distance, const CButtonState& buttons)
{
        if (axis == kMouseWheelAxisX)
        {
                #if MAC // mac os x 10.4.x swaps the axis if the shift modifier is down
                if (!(buttons & kShift))
                #endif
                return onWheel (where, distance*-1, buttons);
        }
        return onWheel (where, distance, buttons);
}

but that adjustment in modern macOS (I'm on 10.14) means shift-two-finger-drag goes the wrong way.

We can adjust for this in our code no problem but I think you probably want to remove that adjustment so figured I'd share!

Thanks so much

Paul

I'm trying to use the latest vstgui 4.5 release, but can't get the mac Xcode tutorial to compile. I was able to get around some of the issues:

• vstsdk2.4 was missing, so I added that
• I set some compiler flags for C++11 support in the Build Settings
  But even after that I started encountering code issues in the tutorial - class names and constructor parameters have changed. At this point I decided to give up and ask if someone in the know could please update the tutorial code so that it works :-) I'm very new to vstgui so I need some working example code to help me use it... ^_^

Hello. To further the mingw compatibility effort I have tried to get the standalone target to compile. I have found two blocking elements absent in mingw, the dpi-related functions, and the PPL concurrency library.

MinGW currently has 2 missing APIs, GetDpiForMonitor and SetProcessDpiAwareness, regardless of the value _WIN32_WINNT. So I have a question here: for these functions MSDN claims support only since Windows 8.1, so wouldn't it be wiser to dynamically resolve these functions, and use conditionally?

I'm thinking of this as the approach for mingw, but it may also be relevant to VSTGUI globally since the readme page indicates support of Windows 7. Any opinion on this?

Running the Clang Static Analyzer results in the following warning:

In file included from vst3sdk/vstgui4/vstgui/vstgui_mac.mm:21:
vst3sdk/vstgui4/vstgui/lib/platform/mac/cocoa/cocoahelpers.mm:18:10: warning: Although the value stored to 'cl' is used in the enclosing expression, the value is never actually read from 'cl'
        while ((cl = objc_lookUpClass ([className UTF8String])) != nil)
                ^    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

proposed fix:

17,18c17
< 	id cl = nil;
< 	while ((cl = objc_lookUpClass ([className UTF8String])) != nil)
---
> 	while (objc_lookUpClass ([className UTF8String]) != nil)

just ran cmake . && make -j 4 on the latest git master branch. Not sure if this is an issue:

UIDescriptionTests
	parseEmpty [OK] -> 227 µs
	colors [OK] -> 249 µs
	fonts [OK] -> 6550 µs
*** Bitmap 'b1.png' not found.
*** Bitmap 'b1#2.0x.png' not found.
*** Bitmap 'path to bitmap' not found.
*** Bitmap 'added bitmap node' not found.
	bitmaps [OK] -> 295 µs
	tags [OK] -> 231 µs
	lookupTagsCalculateTag [OK] -> 114 µs
	gradient [OK] -> 194 µs
	variables [OK] -> 167 µs
Wrong Expression: 7
Tag not found :tag.unknown
Variable not found :var.unknown
Substitution failed :unknown
	calculations [OK] -> 170 µs
*** Bitmap 'b1.png' not found.
*** Bitmap 'b1#2.0x.png' not found.
*** Bitmap 'dataBitmap.png' not found.

UIViewFactoryTests
	registerViewCreator [OK] -> 35 µs
	collectFilteredViewNames [OK] -> 28 µs
	collectRegisteredViewAndDisplayNames [OK] -> 24 µs
	createView [OK] -> 12 µs
UIViewFactory::createView(..): Could not find view of class: Unknown

XMLParserTest
	validParse [OK] -> 12 µs
	validParseWithJunkAtEnd [OK] -> 7 µs
XML Parser Error on line: 5
mismatched tag
</tag2>
  ^
	invalidParse [OK] -> 25 µs
XML Parser Error on line: 2
parsing aborted
CHARDATA
^
	stopParse [OK] -> 24 µs

Done running 484 tests in 1172ms. [0 Failed]

[100%] Built target unittests

The editoruidesc.h header file is not created when building on Alpine Linux.

[ 89%] Building CXX object _deps/vstsdk-build/vstgui4/vstgui/uidescription/CMakeFiles/vstgui_uidescription.dir/editing/uieditmenucontroller.cpp.o
/build/_deps/vstsdk-src/vstgui4/vstgui/uidescription/editing/uieditcontroller.cpp:50:10: fatal error: editoruidesc.h: No such file or directory
 #include "editoruidesc.h"
          ^~~~~~~~~~~~~~~~
compilation terminated.

The execute_process in vstgui4/vstgui/uidescription/CMakeLists.txt fails with RESULT_VARIABLE='Exec format error' because of a bug in the createuidescdata.sh script.
The first line in createuidescdata.sh should be #!/bin/bash not # /bin/bash.

Option menus with multiple check style behave differently on Windows and Mac. On Mac it behaves as expected, but on Windows the current index is always checked. This behaviour is expected for the standard check style, but not for multiple check style. I have fixed this issue in win32optionmenu.cpp in the function Win32OptionMenu::createMenu().

Instead of writing
if (_menu->getStyle () & kCheckStyle && inc == _menu->getCurrentIndex ()) flags |= MF_CHECKED;
it should be
if (_menu->getStyle () & kCheckStyle && inc == _menu->getCurrentIndex () && !(multipleCheck && !item->isChecked ())) flags |= MF_CHECKED;

This looks strange, but it becomes clear when you look at the definition of the flag kMultipleCheckStyle, which is defined as the number 1025, which is 10000000001. This is a strange definition for a bit flag.

Another way to fix this is to redefine the flag kMultipleCheckStyle, such that it is a power of 2.

After installing a couple of LilyPond GUI editors (Denemo and Frescobaldi) I found that some elements on my plugin UIs were seriously messed up, especially in the UI editor.

Further investigation revealed that the results from GrtMetric were very odd indeed.

In turns out that the problem was here

	if (fontCollection)
	{
		IDWriteFontFamily* fontFamily = 0;
		fontCollection->GetFontFamily (0, &fontFamily);

This code assumes that the first fontfamily in the collection is the one we want. This is not necessarily the case. Now normally we don't notice, because fonts have vaguely similar metrics, but one of the apps I had installed installed the feta26 font, which is not a text font but a set of musical notation synbols, and has very unusual metrics, so that difference was very visible.

The solutiom is to first find the correct font family, the following appears to work

	if (fontCollection)
	{
		UINT32 fontFamilyIndex;
		BOOL fontFamilyExists;
		fontCollection->FindFamilyName(nameStr, &fontFamilyIndex, &fontFamilyExists);
		IDWriteFontFamily* fontFamily = 0;
		fontCollection->GetFontFamily (fontFamilyIndex, &fontFamily);

I'm using GitHub Actions to build VST3 for macOS. Recently GitHub upgraded macOS virtual environment to Catalina (10.15) and vstgui starts failing to build.

CMake error:

[ 23%] Building CXX object vstgui4/vstgui/lib/CMakeFiles/vstgui.dir/platform/mac/caviewlayer.mm.o
/Users/runner/vst3sdk/vstgui4/vstgui/lib/platform/mac/caviewlayer.mm:83:9: error: no matching function for call to 'objc_msgSendSuper'
        self = objc_msgSendSuper (SUPER, @selector(init));
               ^~~~~~~~~~~~~~~~~
/Applications/Xcode_11.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/objc/message.h:67:1: note: candidate function not viable: requires 0 arguments, but 2 were provided
objc_msgSendSuper(void /* struct objc_super *super, SEL op, ... */ )
^
1 error generated.
make[2]: *** [vstgui4/vstgui/lib/CMakeFiles/vstgui.dir/platform/mac/caviewlayer.mm.o] Error 1

GitHub Actions setting:

• https://github.com/ryukau/VSTPlugins/blob/master/.github/workflows/build.yml

Build command:

• https://github.com/ryukau/VSTPlugins/blob/master/ci/ci_macos.sh

Environment:

• https://help.github.com/en/actions/automating-your-workflow-with-github-actions/software-installed-on-github-hosted-runners#macos-1015

Hello !

I was wondering why the SDK repository don't contains the VST3PluginTestHost.

Maybe I just understood how to build / find it, could you help me please ?

Best regards,
Matthieu Moinvaziri

Please check the following link for further details https://sdk.steinberg.net/viewtopic.php?f=5&t=625

CMultiLineTextLabel::recalculateHeight() is not called upon attachment regardless of whether CMultiLineTextLabel::getAutoHeight() returns true. Nor is it called upon CMultiLineTextLabel::setAutoHeight(true) if the view is not attached.

Currently in win32frame.cpp mouse capture is set after all mouse clicks. If the click caused a popup menu to occur and process, then there is no reason to setcapture. One possible solution is below. Do not set capture if the mouse button is up. win32frame.cpp line 866:

    {//only set capture on mousedown if not left button or left button is still down. It is not after calling trackpopup menu
         if ((buttons & kLButton) == 0 || GetAsyncKeyState (VK_LBUTTON) < 0)
             SetCapture (getPlatformWindow ());
    }

Hi. I'm currently trying to make VSTGUI works on Linux and found several issues in cairocontext.cpp.

Modified cairocontext.cpp that worked in my environment is available on the link below.

• https://gist.github.com/ryukau/b32adb55ce6dd118387683c2bc8530b6

1. No degree to radian conversion in drawArc

CDrawContext::drawArc takes angles in degree. However, drawArc in cairocontext.cpp directly passes degrees to cairo_arc without converting them to radian.

cairo_arc (cr, 0, 0, 1, startAngle1, endAngle2); // line 354

Multiplying 2.0 * M_PI / 360.0 fixed this issue.

cairo_arc (cr, 0, 0, 1, startAngle1 * M_PI / 180.0, endAngle2 * M_PI / 180.0);

• VSTGUI: CDrawContext Class Reference
• Paths: Cairo: A Vector Graphics Library

2. Scaling factors in drawArc and drawEllipse are incorrect

In current code, numerator and denominator of scaling factor are flipped. Code below is from drawEllipse but it's same in drawArc.

CPoint center = rect.getCenter (); // line 364
cairo_translate (cr, center.x, center.y);
cairo_scale (cr, 2.0 / rect.getWidth (), 2.0 / rect.getHeight ());
cairo_arc (cr, 0, 0, 1, 0, 2 * M_PI);
draw (drawStyle);

Only flipping numerator and denominator didn't solve this issue. I also added cairo_save and cairo_restore to make transform to be local. Also this should make line width to be uniform, according to Ellipses With Uniform Stroke Width from cairo documentation.

cairo_save (cr);
CPoint center = rect.getCenter ();
cairo_translate (cr, center.x, center.y);
cairo_scale (cr, rect.getWidth () / 2.0, rect.getHeight () / 2.0);
cairo_arc (cr, 0, 0, 1, 0, 2 * M_PI);
cairo_restore (cr);
draw (drawStyle);

3. drawPolygon closes line

Here, "close" means it connects last point to first point. Unlike D2DDrawContext::drawPolygon, drawPolygon in cairocontext.cpp closes polygon.

auto& last = polygonPointList.back (); // line 318
cairo_move_to (cr, last.x, last.y);
for (auto& it : polygonPointList)
	cairo_line_to (cr, it.x, it.y);

To make drawPolygon in cairocontext.cpp to behave as same as D2DDrawContext::drawPolygon, I changed above code to the following.

auto& first = polygonPointList.front ();
cairo_move_to (cr, first.x, first.y);
for (auto it = polygonPointList.begin () + 1; it != polygonPointList.end (); ++it)
	cairo_line_to (cr, (*it).x, (*it).y);

4. Translation with ± 0.5

There are some + 0.5 and - 0.5 to slightly translate coordinate. They are causing inconsistency between Windows and Linux.

Following methods are affedted.

• drawLine
• drawLines
• drawRect
• drawPoint

For example in drawLine:

cairo_move_to (cr, start.x + 0.5, start.y + 0.5); // line 266
cairo_line_to (cr, end.x + 0.5, end.y + 0.5);

These + 0.5 make location of paths to be slightly off. When I removed them, cairo put paths to correct location.

cairo_move_to (cr, start.x, start.y);
cairo_line_to (cr, end.x, end.y);

I have tried the recently released 4.5 update of VSTGUI. Everything seems to work fine so far except for bitmap drawing on Mac OS when running on a Retina display and the CFrame::setZoom() is set to anything != 1.0 (see image below). The example contains a CAnimKnob and the CFrame zoom is set to a value <1.The black border sometimes appears on the left, sometimes on the top or bottom or on both edges of the bounding box. The control itself is positioned on integral coordinates and has integral and even dimensions when created. The described behaviour can be reproduced in 10.11 and 10.12, but probably also affects older versions of Mac OS.

I was diff'ing lib/platform/mac/cgdrawcontext.cpp against the 4.3 revision and had the impression that it might have to do something with line 621 in CGDrawContext::drawBitmap() where the integralOffset argument for beginCGContext() was changed to true. But alas that didn't help.

It also doesn't make any difference whether the bitmap sits in a layered or non layered view container, except for the erroneousthe border being drawn in white instead of black when layered.

Subscribing to sdk.steinberg.net does not work (no one seems to care activating accounts since a week?)

The documentation has little hints about working with VSTGUI4 / VST3, Most acticles are about 2.4 and dont work this way in VST3, most classes in VSTGUI4 dont even have a single sentence describing what they are used for.

For example:

• how do I setup a listener for a button in VST3/GUI4 when the button comes from XML?
• how can I get a CControl* from a tag inside my controller?

In file included from vstgui/vstgui/vstgui_mac.mm:17:
vstgui/vstgui/lib/platform/mac/macclipboard.mm:65:21: warning: moving a temporary object prevents copy elision [-Wpessimizing-move]
                        entries[index] = std::move (makeEntry (pb.pasteboardItems[index]));
                                         ^
vstgui/vstgui/lib/platform/mac/macclipboard.mm:65:21: note: remove std::move call here
                        entries[index] = std::move (makeEntry (pb.pasteboardItems[index]));
                                         ^~~~~~~~~~~                                     ~

Just remove the std::move call, it is unnecessary and detrimental to performance.

On Mac the bitmap drawing methods in CGDrawContext.cpp always use integral mode:

Every other invocation of beginContext() in that file uses the integral mode as the second argument, looking like this:

I found this out because I was drawing a rotating dial. The rotation works fine (including interpolation), but the offset is rounded to the nearest integral position, causing my dial to jump around within a pixel (screencap video). When I changed the above two lines to match the others, the rotation became smooth.

(I haven't checked this on Windows (only just starting out), so I don't know whether gdiplusdrawcontext.cpp does the same thing.)

When the plugin is focused and no onKeyDown event is handled, the whole thing crashes. I'm using FL Studio as the host, and I don't know if this bug is specific to it. It's an "access violation reading location 0xFFFFFFFFFFFFFFFF" exception and occurs at line 985 of win32frame.cpp. It happens when the keydown event makes FL Studio close the editor to open an options tab in the wrapper, when the frame is about to call pFrame->platformOnActivate(false). This crash even happens with the VST SDK example projects, so it doesn't have anything to do with my specific implementation. I don't want people to lose their project just because they pressed a key :^(

Hi!

You seem target Windows and bundle Expat 2.2.1.
Please update your bundle to Expat 2.2.3 to fix vulnerability CVE-2017-11742.

Thanks!

CSplashScreens that are embedded into CLayeredViewContainers don't show on splash() when running on Mac Cocoa.

Hey,

I stress-tested the AGain.vst3 editor on Linux with Reaper and Bitwig Studio and quickly ran into a crash after closing and re-opening the editor several times. The crash happens on calling cairo_xcb_surface_create (click here).

Before the crash I get an output:
reaper: ../../../../src/cairo-xcb-screen.c:219: _get_screen_index: Assertion `!"reached"' failed.

I searched that on google and found a post by @abique here:
https://lists.cairographics.org/archives/cairo/2017-December/028496.html

So I did what was suggested and extended the ctor of DrawHandler by

(device is a member of DrawHandler)
device = cairo_device_reference(cairo_surface_get_device(surface));

and created a dtor ~DrawHandler with

cairo_device_finish(device);
cairo_device_destroy(device);

Afterwards the crash is gone. Maybe @abique can share his experience. Is this still used in u-he plug-ins?

(I also found this which is doing something very similar: https://chromium.googlesource.com/chromiumos/third_party/cairo/+/f9344911250ea347fb0eb54d7ab1f97c8f685a20/boilerplate/cairo-boilerplate-xcb.c)

Any more ideas?

René

Is VSTGUI hardware (gpu) accelerated on macOS?

On mac this apparently works fine but under windows no checkmark appears. I suggest the following change to fix this. win32optionmenu.cpp starting at line 171:
if (item->getSubmenu ())
{
HMENU submenu = createMenu (item->getSubmenu (), offsetIdx);
if (submenu)
{
if (multipleCheck && item->isChecked ())
flags |= MF_CHECKED;
AppendMenu (menu, flags|MF_POPUP|MF_ENABLED, (UINT_PTR)submenu, (const TCHAR*)entryText);
}
}

I'm trying to fix VST2 and VST3 for macOS and Linux in recently open sourced Surge VST but this one undefined symbol causing me gray hairs: https://github.com/kurasu/surge/issues/38. Can you help guide me a bit with this. Thank you.

On mac and windows, vstgui onMouseMove events correctly have keyboard modifiers like shift or right button. On linux they do not.

The reason is:

does not include a translateModifiers call.

diff --git a/vstgui/lib/platform/linux/x11frame.cpp b/vstgui/lib/platform/linux/x11frame.cpp
index 1cf86770..564ba4ba 100644
--- a/vstgui/lib/platform/linux/x11frame.cpp
+++ b/vstgui/lib/platform/linux/x11frame.cpp
@@ -490,6 +490,7 @@ struct Frame::Impl : IFrameEventHandler
        {
                CPoint where (event.event_x, event.event_y);
                auto buttons = translateMouseButtons (event.state);
+               buttons |= translateModifiers (event.state);
                doubleClickDetector.onMouseMove (where, buttons, event.time);
                frame->platformOnMouseMoved (where, buttons);
                // make sure we get more motion events

is the correct addition which we have applied to our fork.

Thanks to @xard-dev for finding this after this lack made surge behave incorrectly on linux over in surge-synthesizer/surge#2457

CTextEdit has a redundant text input processing loop when you have both a ValueToStringFunction and a StringToValueFunction specified.

Upon entering new text input, CTextEdit::updateText will invoke CTextEdit::setText will invoke the StringToValueFunction, setValue, and then invoke the ValueToStringFunction presumably to conform the text to the newly parsed value.

CTextEdit::updateText will then call CTextEdit::valueChanged, and then with a StringToValueFunction present, CTextLabel::valueChanged, which will invoke the ValueToStringFunction yet again, followed by yet another setText call (virtualized back to CTextEdit for that), bringing us back to the previous paragraph's sequence of events.

The problem with this looping is that it can be data lossy. For example, perhaps your ValueToStringFunction function prints one decimal place of precision. The user may want to use text entry to enter a more precise value, e.g. 1.23. But after the second ValueToStringFunction invocation, the string produced is "1.2", and then call to setText is made using that, you now have truncated the value that the user entered.

The following patch is a proposed fix for the bug:

--- a/vstgui/lib/controls/ctextedit.cpp
+++ b/vstgui/lib/controls/ctextedit.cpp
@@ -395,7 +395,7 @@ void CTextEdit::updateText (IPlatformTextEdit* pte)
 
        setText (newText);
 
-       valueChanged ();
+     CParamDisplay::valueChanged ();
 
        endEdit ();
    }

On macOS 10.15.x, aliased text renders doubled, with one of the renders offset 1 pixel to the right, creating thick/smeared text. I isolated the change that introduced the bug and it was when NSViewFrame::NSViewFrame added the call nsView.layer.drawsAsynchronously = YES;. This bug does not occur in earlier versions of macOS nor in current betas of macOS 11, so my proposed fix is simply to avoid drawsAsynchronously on macOS 10.15.

diff --git a/vstgui/lib/platform/mac/cocoa/nsviewframe.mm b/vstgui/lib/platform/mac/cocoa/nsviewframe.mm
index c5face85..42ca6ea6 100644
--- a/vstgui/lib/platform/mac/cocoa/nsviewframe.mm
+++ b/vstgui/lib/platform/mac/cocoa/nsviewframe.mm
@@ -843,7 +843,7 @@ static id VSTGUI_NSView_makeTouchbar (id self)
 		if (systemVersion.majorVersion > 10 || (systemVersion.majorVersion >= 10 && systemVersion.minorVersion > 10))
 		{
 			[nsView setWantsLayer:YES];
-			if (systemVersion.majorVersion > 10 || (systemVersion.majorVersion >= 10 && systemVersion.minorVersion >= 13))
+			if (systemVersion.majorVersion > 10 || (systemVersion.majorVersion >= 10 && systemVersion.minorVersion >= 13 && systemVersion.minorVersion != 15))
 				nsView.layer.drawsAsynchronously = YES;
 		}
 	}

After updating to version 4.9, my iOS standalone no longer compiles. I looked at the example for iOS and that hasn't been updated in 3 years, so I imagine it wouldn't compile either.

Looks like I'm wrong...

CFrame onKeyDown/Up etc only get a small subset of keys, ie the ones listed in vstkeycode.h struct VstVirtualKey, ie shift, ctrl, space, F1-F12, arrows etc.
But no letters or digits.

In fact it looks like the VstKeyCode .character member is always 0 on windows.

If I read Mac code in /platform/mac/ cocoahelpers.mm right, this is not the case on Mac;
there the .character member is populated with ASCII value.

I can ofc hack the win32frame.cpp translateWinVirtualKey function, or use KeyboardHook,
but just wanted to note this seems an omission.

Or is there some logic to this behaviour?

Thanks,
/re

Linux Project (Surge) using vstgui segfaults on line 1072 of cframe.cpp:

void CFrame::onViewRemoved (CView* pView)
{
	removeFromMouseViews (pView);

	if (pImpl->activeFocusView == pView)
		pImpl->activeFocusView = nullptr;
	if (pImpl->focusView == pView)
	{
		if (pImpl->active)
			setFocusView (nullptr);
		else
			pImpl->focusView = nullptr;
	}
	if (auto container = pView->asViewContainer ())
	{
		if (container->isChild (pImpl->focusView, true))
			setFocusView (nullptr);
	}
	if (getViewAddedRemovedObserver ())
		getViewAddedRemovedObserver ()->onViewRemoved (this, pView);
	if (pImpl->animator)
		pImpl->animator->removeAnimations (pView);
HERE--> if (pView->wantsWindowActiveStateChangeNotification ())
		pImpl->windowActiveStateChangeViews.remove (pView);
}

The CView object pointed to by pView gets destroyed when the Animations are removed in Animator::removeAnimations (CView* view) in animator.cpp, triggering the segfault above.

The segfault occurs in the VST2 code when more than a few menu items exist in COptionMenu (created using either new CCommandMenuItem() or addCallbackMenu()).

It seems like a timing issue with the reference counter to the CView object?

Commenting out lines 274 and 275 of /vstgui/lib/platform/common/genericoptionmenu.cpp prevents the segfault from happening.

There is a problem of static initialization order in X11 VSTGUI.
Depending on it, the resource path may or may not be set correctly at startup, and Cairo will be able or not to load image files.

Several users of Debian buster have reported this problem.

Some more detailed discussion has occurred here on this topic.
sfztools/sfizz-ui#84

The following patch has been reported to work as a fix for this problem.
sfztools/sfizz-ui#84

EDIT forgot to add, this was vstgui4 from the vst-sdk_3.6.14_build-24_2019-11-29 package

Hi,
I may have found a bug in CViewContainer::removeAll:

bool CViewContainer::removeAll (bool withForget)
{
	if (pImpl->mouseDownView)
		pImpl->mouseDownView = nullptr;
	pImpl->currentDragView = nullptr;
	
	ViewList::iterator it = pImpl->children.begin ();
	while (it != pImpl->children.end ())
	{
		CView* view = *it;
		if (isAttached ())
			view->removed (this);
		pImpl->children.erase (it);
		view->setSubviewState (false);
		pImpl->viewContainerListeners.forEach ([&] (IViewContainerListener* listener) {
			listener->viewContainerViewRemoved (this, view);
		});
		if (withForget)
			view->forget ();
		it = pImpl->children.begin ();
	}
	return true;
}

The children member is actually of type ViewList, which is defined as std::list<SharedPointer>.
If all SharedPointer's to a CView have been destroyed already, except for a single one left in CViewContainer's children member, the line
pImpl->children.erase (it);
will call the CView's destructor and the object will be destroyed.
However, a pointer to this object is still in the view variable and used later on, e.g. view->setSubviewState (false);. As far as I can see, this is an illegal access to a destroyed object.
It may probably be solved by moving pImpl->children.erase (it); further down in the while loop.

I can create a pull request of this change, but I'd like to hear an expert's option before doing so.

DebugPrint will overflow the 300 character buffer used because there is no check.

We hit this by building the SDK from a deep path and reusing the prebuilt libraries on other development machines. uidesceditor.uidesc was not found, causing a greater than 300 character error message,

This should be possible in any situation that sends a long message to DebugPrint.

On macOS, if you left-click on a view and then press the control modifier key, any subsequent drag movement of the left mouse click will be translated into right-click mouse move events without the control key modifier enabled. It is typical Mac behavior to map control + left-click to right-click, but this mapping should not occur to movements after an initial left-click that occurred without the control key pressed. This eliminates the possibility of using the control key during mouse dragging on a view as a modifier for the behavior. Below is a proposed patch to fix this:

diff --git a/vstgui/lib/platform/mac/cocoa/cocoahelpers.h b/vstgui/lib/platform/mac/cocoa/cocoahelpers.h
index acae67e4..b8428d68 100644
--- a/vstgui/lib/platform/mac/cocoa/cocoahelpers.h
+++ b/vstgui/lib/platform/mac/cocoa/cocoahelpers.h
@@ -64,6 +64,7 @@ extern HIDDEN Class generateUniqueClass (NSMutableString* className, Class baseC
 extern HIDDEN VstKeyCode CreateVstKeyCodeFromNSEvent (NSEvent* theEvent);
 extern HIDDEN NSString* GetVirtualKeyCodeString (int32_t virtualKeyCode);
 extern HIDDEN int32_t eventButton (NSEvent* theEvent);
+extern HIDDEN int32_t eventButtonForMouseDown (NSEvent* theEvent);
 extern HIDDEN void convertPointToGlobal (NSView* view, NSPoint& p);
 
 //------------------------------------------------------------------------------------
diff --git a/vstgui/lib/platform/mac/cocoa/cocoahelpers.mm b/vstgui/lib/platform/mac/cocoa/cocoahelpers.mm
index 610e91d0..a49e2846 100644
--- a/vstgui/lib/platform/mac/cocoa/cocoahelpers.mm
+++ b/vstgui/lib/platform/mac/cocoa/cocoahelpers.mm
@@ -201,7 +201,7 @@ HIDDEN int32_t eventButton (NSEvent* theEvent)
 	int32_t buttons = 0;
 	switch ([theEvent buttonNumber])
 	{
-		case 0: buttons = ([theEvent modifierFlags] & MacEventModifier::ControlKeyMask) ? kRButton : kLButton; break;
+		case 0: buttons = kLButton; break;
 		case 1: buttons = kRButton; break;
 		case 2: buttons = kMButton; break;
 		case 3: buttons = kButton4; break;
@@ -210,6 +210,17 @@ HIDDEN int32_t eventButton (NSEvent* theEvent)
 	return buttons;
 }
 
+//------------------------------------------------------------------------------------
+HIDDEN int32_t eventButtonForMouseDown (NSEvent* theEvent)
+{
+	const auto buttons = eventButton (theEvent);
+	if (([theEvent modifierFlags] & MacEventModifier::ControlKeyMask) && (buttons == kLButton))
+	{
+		return kRButton;
+	}
+	return buttons;
+}
+
 //-----------------------------------------------------------------------------
 HIDDEN void convertPointToGlobal (NSView* view, NSPoint& p)
 {
diff --git a/vstgui/lib/platform/mac/cocoa/nsviewframe.mm b/vstgui/lib/platform/mac/cocoa/nsviewframe.mm
index c5face85..0ef2b325 100644
--- a/vstgui/lib/platform/mac/cocoa/nsviewframe.mm
+++ b/vstgui/lib/platform/mac/cocoa/nsviewframe.mm
@@ -237,7 +237,7 @@ static BOOL VSTGUI_NSView_onMouseDown (id self, SEL _cmd, NSEvent* theEvent)
 	if (!_vstguiframe)
 		return NO;
 
-	CButtonState buttons = eventButton (theEvent);
+	CButtonState buttons = eventButtonForMouseDown (theEvent);
 	[[self window] makeFirstResponder:self];
 	NSUInteger modifiers = [theEvent modifierFlags];
 	NSPoint nsPoint = [theEvent locationInWindow];
@@ -977,15 +977,7 @@ static id VSTGUI_NSView_makeTouchbar (id self)
 
 	NSUInteger mouseButtons = [NSEvent pressedMouseButtons];
 	if (mouseButtons & (1 << 0))
-	{
-		if (mouseButtons == (1 << 0) && modifiers & MacEventModifier::ControlKeyMask)
-		{
-			buttons = kRButton;
-			return true;
-		}
-		else
-			buttons |= kLButton;
-	}
+		buttons |= kLButton;
 	if (mouseButtons & (1 << 1))
 		buttons |= kRButton;
 	if (mouseButtons & (1 << 2))

When the right mouse goes up the left button is added to the state by mistake.
The code below is from win32frame.cpp.
"message & MK_LBUTTON" in the first if statement should be "wParam & MK_LBUTTON" like in the rest of the if statements.

Hello. Thanks for bringing this to linux!
Have finally checked some parts with a static analysis tool. Here are some points I've found

1. The 'inputBitmap' pointer was utilized before it was verified against nullptr.
   

   vstgui/vstgui/lib/cbitmapfilter.cpp

   Lines 412 to 413 in f6b70f7

   	uint32_t radius = static_cast<uint32_t>(static_cast<double>(getProperty (Property::kRadius).getInteger ()) * inputBitmap->getPlatformBitmap ()->getScaleFactor ());
   	if (inputBitmap == nullptr || radius == UINT_MAX)

2. Expression is always true
   

   vstgui/vstgui/lib/cframe.cpp

   Line 323 in f6b70f7

   if (pContext)

3. Typo?
   

   vstgui/vstgui/lib/controls/ctextlabel.cpp

   Lines 326 to 328 in f6b70f7

   	if (lineLayout != LineLayout::clip ||
   	(lineLayout == LineLayout::clip &&
   	viewSize.getHeight () != normRect.getHeight ()))

4. Why?
   https://github.com/steinbergmedia/vstgui/blob/master/vstgui/uidescription/uiviewcreator.cpp#L1511
   https://github.com/steinbergmedia/vstgui/blob/master/vstgui/uidescription/uiviewcreator.cpp#L1521
5. The same here
   https://github.com/steinbergmedia/vstgui/blob/master/vstgui/uidescription/uiviewcreator.cpp#L1506
   https://github.com/steinbergmedia/vstgui/blob/master/vstgui/uidescription/uiviewcreator.cpp#L1516
6. One pair of parentheses is unnecessary or misprint is present.
   https://github.com/steinbergmedia/vstgui/blob/master/vstgui/uidescription/uiviewcreator.cpp#L2856
   https://github.com/steinbergmedia/vstgui/blob/master/vstgui/uidescription/uiviewcreator.cpp#L2871
7. Consider inspecting the '?:' operator. A temporary object of the 'SharedPointer' type is being created and subsequently destroyed. Check third operand.
   

   vstgui/vstgui/uidescription/editing/uibitmapscontroller.cpp

   Line 117 in f6b70f7

   IPlatformBitmap* platformBitmap = background ? background->getPlatformBitmap () : nullptr;

Hey there,

I don't know where should I post this issue. I post this in Steinberg forum, but there are no one reply since Dec. Thus I came here to post this issue.

I try to install the tool for UR242 in my MacBook. I following the instruction from the Steinberg website, and tried most of the solutions. I have tried that allow the security stuff from the System Preference, run install from sudo, using chmod give 755 permission, it alway failed to install.

I dumped the log fro installer.

Jan 16 22:11:53 Youke-MacbookPro installd[540]: PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=112 "An error occurred while running scripts from the package “TOOLS for UR242 V1.0.4.pkg”." UserInfo={NSFilePath=./postinstall, NSURL=file://localhost/Users/youke/Desktop/TOOLS_for_UR242_V104_Mac/TOOLS%20for%20UR242%20V1.0.4.pkg#eLicenserControlProxy.pkg, PKInstallPackageIdentifier=com.yamaha.pkg.eLicenserControlProxy, NSLocalizedDescription=An error occurred while running scripts from the package “TOOLS for UR242 V1.0.4.pkg”.} {
	    NSFilePath = "./postinstall";
	    NSLocalizedDescription = "An error occurred while running scripts from the package \U201cTOOLS for UR242 V1.0.4.pkg\U201d.";
	    NSURL = "file://localhost/Users/youke/Desktop/TOOLS_for_UR242_V104_Mac/TOOLS%20for%20UR242%20V1.0.4.pkg#eLicenserControlProxy.pkg";
	    PKInstallPackageIdentifier = "com.yamaha.pkg.eLicenserControlProxy";
	}
Jan 16 22:11:54 Youke-MacbookPro Installer[535]: Install failed: The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.
Jan 16 22:11:54 Youke-MacbookPro Installer[535]: Displaying 'Install Failed' UI.
Jan 16 22:11:54 Youke-MacbookPro Installer[535]: 'Install Failed' UI displayed message:'The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.'.

It seems like com.yamaha.pkg.eLicenserControlProxy fail to install, and I try to manually run the eLicenserControlSetup, after enter the username and password, nothing really happen.

If there are any one can help me install that, that will be appreciate.

###The Machine Info###
MacBook Pro (15-inch, 2017)
2.9 GHz Intel Core i7
16 GB 2133 MHz LPDDR3

If there are anyone can help me on that. it will be cool.

Cross Compiling Windows Binaries from MacOSX terminal

With
clang 6.0.0 installed via brew install llvm, and a copy of the inc/lib dirs from my MSVC2015 installation, I get 1 error compiling vstgui with llvm's clang-cl compiler. This is a cl.exe compiler, and it works really well.

This is the error I get:

vstgui/vstgui/lib/controls/../cstring.h(26,2):  error:
      exception specification of explicitly defaulted default constructor does not match the
      calculated one
        UTF8CodePointIterator () noexcept = default;

This is my compile line:

/usr/local/opt/llvm/bin/clang-cl 
/imsvc"/Users/username/MSVC/Microsoft Visual Studio14.0/VC/include" 
/imsvc"/Users/username/MSVC/Windows Kits/10/Include" 
/imsvc"/Users/username/MSVC/Windows Kits/10/Include/10.0.10150.0/ucrt" 
/imsvc"/Users/username/MSVC/Windows Kits/10/Include/10.0.10240.0/ucrt" 
/imsvc"/Users/username/MSVC/Windows Kits/10/Include/10.0.14393.0/ucrt" 
/imsvc"/Users/username/MSVC/Windows Kits/8.1/Include/um" 
/imsvc"/Users/username/MSVC/Windows Kits/8.1/Include/shared" 
/I"/Users/username/src/MinimalSynthVST2.4/vstgui/vstgui" 
/I"/Users/username/src/MinimalSynthVST2.4/vstgui/vstgui/lib" 
/I"/Users/username/src/MinimalSynthVST2.4/vstsdk2.4" 
/I"/Users/username/src/MinimalSynthVST2.4/vstsdk2.4/public.sdk/source/vst2.x" 
/I"/Users/username/src/MinimalSynthVST2.4/vstsdk2.4/pluginterfaces/vst2.x" 
 -DVERSION=0.0.0.1 -DWIN32 -D_CRT_SECURE_NO_WARNINGS -D_WINDOWS 
 -m64 /MT -fmsc-version=1900-fms-extensions -fms-compatibility -fdelayed-template-parsing 
 -fmsc-version=1900 -fms-extensions -fms-compatibility -fdelayed-template-parsing 
 -fmsc-version=1900 -fms-extensions -fms-compatibility -fdelayed-template-parsing 
 /EHa /EHs -Wno-deprecated-register /std:c++14 /c 
  /Tp/Users/username/src/MinimalSynthVST2.4/vstgui/vstgui/vstgui_win32.cpp 
  /oCMakeFiles/vstgui.dir/vstgui/vstgui/vstgui_win32.cpp.obj

System include paths with /imsvc, and includepaths with /I. I have tried all the c++11/14/17 flavors.

Here is the code fix that gets me running again:

Change this line of code (found in vstgui/vstgui/lib/controls/../cstring.h):

UTF8CodePointIterator () noexcept = default;

To this:

//UTF8CodePointIterator () noexcept = default;          // original, doesnt compile under clang-cl

//UTF8CodePointIterator () /*noexcept*/ = default;      // this resulted in error under clang-cl

UTF8CodePointIterator () noexcept /*=default*/: it() {} // removed default, replace with {}

Obviously the comments can be cleaned up, but I left them for communication, so you can see my thoughts...

If you'd like to play with it, you can see it here:
https://github.com/subatomicglue/MinimalSynthVST2.4

Hi!

This repository bundles an outdated vulnerable copy of Expat 2.1.1. Please update your copy to version 2.2.1 with the latest security fixes. A change log with details is available at https://github.com/libexpat/libexpat/blob/master/expat/Changes . Thank you!

Best

 
Sebastian