DAW crashes if saved with a VST restricted instance of a panel

[dervur]

Hello everybody!

I don't know if this is known issue and I'm reposting but I wouldn't find anything about it. Basically if I saw a project in a DAW (currently used only Cubase Elements 12 on Windows), when opening it shows these two messages:

Sometimes only the first one appears without the crash dump at which the project does not open.

When I then save it again, this is what appears:

Does anybody have any idea on how to solve this issue? It seems to be a problem with the last saved MIDI setting when it is restored since the message is about the MIDI out... I don't know if I have to initialize something when opening the panel.
To be clear this appears before the actual project is open, so it seems to be triggered when Cubase is trying to open the last settings of the VST.

[damiensellier]

I don't have those problems on my panels. Can you export the exact same plugin but without the part where it handles the last midi message that could crash cubase? Let's start from there to see if your cubase project is closing properly.
And after we'll check together what's wrong with the part of the script that leads to the crash.

Damien

[damiensellier]

Also, if you use your midi in/outs of the Volca you should disable them in your cubase midi settings if your card is single instance on Windows.

It seems that you have a problem about that from the 1st popup:

Or you should use the MidiThru capabilities of Ctrlr to pass the signal to the DAW, it's in the ctrlr midi settings.
I do it with virtual midi ports and a splitter with LoopMIDI and rtpMIDI.

https://www.tobias-erichsen.de/software/loopmidi.html

https://www.tobias-erichsen.de/software/rtpmidi.html

[dervur]

Ok I managed to find the email, he told me this:
“The page you shared [I shared him the same page you linked here] is talking about the new Windows MIDI API for MIDI 2.0, it is still under development and no music software is implemented it yet. I am one of the executive board member of the MIDI Association, so do the Peter Brown from Microsoft. We had meeting together in every two weeks frequently. Once Microsoft releases this new API to all developers officially and they implement it in their new software version, you can enjoy it.”

He talks about software version not OS only, that’s why I made the conclusion that Juce should update to support it too, as does Steinberg, Ableton and so on… hopefully he just expressed himself wrong and meant OS version only, or driver, but not software too. Or retro compatibility will be impossible.

I did try to use those MIDI software they create a hell of a MIDI loop… I believe as of now for Windows the best solution remains to set up the panel for “midi output to host” and then use the DAW itself to set the correct MIDI out, as within the DAW parallel MIDI is possible. Will have to properly test it, might do it this week, but I did some tests from within the CtrlrX VST and it seemed to work smoothly.

[dobo365]

Didn't see your reply... I just contacted Pete as he is on Gearspace like me and I remembered he mentioned he was working on that at MS.
I'll let you know.

[dobo365]

This is about the Ctrlr Midi Thru capabilities :

#542

Plugin host -> Output device When the Panel is a VST this allows MIDI Notes from a DAW MIDI Track to pass THRU the Panel whilst still allowing the Panel function simultaneously as an Editor, sending SysEx or whatever. Very useful for a Synth Editor!

Input Device -> Output Device and Input Device Channel set to All Channels This will allow a MIDI Keyboard setup as a Controller Device to pass MIDI Note On/Off on any MIDI Channel straight THRU to the MIDI Output Device. Useful for passing all Note ON/OFF on any Channel to a MultiTimbral Synth!

IN Device -> OUT Device : "All messages that are received on the MIDI Input device of CTRLR will be copied to the selected output MIDI Device of CTRLR"

CTRL Device -> OUT Device : "All messages that are received on the MIDI Controller device of CTRLR will be copied to the selected output MIDI Device of CTRLR"

HOST -> OUT Device : "All messages received by CTRLR from the plugin HOST, will be copied to the MIDI Output device of CTRLR"

HOST -> HOST : "All messages received by CTRLR from the plugin HOST, will be copied back to the plugin HOST"

HOST -> OUT Device as far as I understand, can be helpful if you are on Windows and don't have a multi instance MIDI soundcard, it would prevents duplicating the message with using a midi loopback software and a MIDI splitter program to avoid those "cannot open", "midi device not available" or "midi device already in use" (something like that). Ctrlr doesn't act as a second app but a parrallel one. It can be great for listening and displaying/analysing the incoming midi messages from a Host MIDI track for exemple.

You create a midi track in the host, select the MIDI input device from there, enable the channel MIDI IN, the Midi track messages will go to the CTRLR plugin. When CTRLR plugin will receive the midi messages from the host midi track, it will route those messages to the device output and channel of your choice you can set in the CTRLR midi menu.

Thx for this great definitions.
And do you know what "the comparator" is (also in the Midi menu)?

[dobo365]

Hi again, here is the answer I got from Pete:

Multi-client MIDI requires the new Windows MIDI Services to be installed on the PC, which is currently in developer preview and which will be in Windows early next year.

The work we're currently testing and refining right now takes the old WinMM API and repoints it to the new Windows Service. That's why the old API will get multi-client support.

We're currently testing the backwards compatibility support before the next developer preview. All applications using the old or new 64 bit MIDI API in Windows will get multi-client capability without having to make any changes. It's one of a few features which will be universally available to any 64 bit app on 64 bit Windows., regardless whether they use WinMM or the new API.

32 bit applications (for example, MIDI-OX, which uses a 32 bit MIDI library) will not see any MIDI devices if Windows MIDI Services is installed. We're not planning any 32 bit support, but we're evaluating the impact.

NOTE: Pete told me afterwards that finally they found a solution for Midi-OX so it will also work fine!

Apps using the deprecated DirectMusic will also not see MIDI devices. We're not planning any support for DirectMusic APIs, but will look to see who it impacts and how.

We'll support the last version of Windows 10, plus currently supported versions of Windows 11. The current Windows 11 support will roll out first, with older Windows 11 and the latest Windows 10 shortly afterwards. This will come through Windows update. The support apps (MIDI Settings and MIDI Console) will initially come from Github, but will be in the Microsoft Store on Windows shortly after.

I need to update the documentation with the latest backwards compatibility info, but you can learn more here: https://aka.ms/midi

Just cool :-)

[dervur]

That sounds promising, I guess we need to sit and wait (especially as I have win 11 22H2 and not the latest version). But at least the plan sounds promising... I would also add finally Windows is implementing it after decades of MIDI being a thing

[dobo365]

FYI, I have a user with the same issue in Win11 + Cubase 13 (with a panel made with Ctrlr 5.3.201).
Are you saying that this multi-client is not yet deployed?
I will verify with the guy responsible of the implementation at MS if I find him back (he is on Gearspace and open to share).

For Win10, if one disables the main ports and open them in the panel, how do you do to record a track from the device?
I think we need to propose some solution for all Win10 users. We need to be able to record from a device, play it back and use a Ctrlr editor at the same time in complete transparent way.
Will try with soundigy patchbay (proposed by Damien) and my S6 desktop next w-e then, if OK, I will write some instruction.

[damiensellier]

I really need to dig into this too. I'm procrastinating about it but we need to write a precise tuto about that particular problem. Everybody is facing it so it has to be done.
On my side I had it working perfectly on win10, midiLoop and rtpMIDI for a panel I'm working on to convert midi controllers to Mackie MCU devices inside the DAW. It has 2 plugin, one for the input translation and a second one for the MCU to midi out to the controller (Leds) and a monitor to show what the MCU should display on its led screens. So the midi routing is quite complex on Windows but working. But I had to disable/hide the input/output of this particular midi controller in Cubase since there's no need to record midi on a track.
I don't really know how it should work if recording midi from the device was necessary. Maybe with the midi Thru Host -> OUT, idk, I need to test it.

[dervur]

I think for now on Windows the best solution is (instructions for Cubase, I don't know how other DAWs work but I'm sure there is a solution for them too along the lines of what I'm writing below):

• allow output to host on your panel
• create instrument track and set midi in and out to none
• create a midi track, set the midi out of the instrument as the input of the midi track and set the output of the midi track to the hardware output

I did not try with restricted instances but it worked within Ctrlr. I never worked with instruments that have a midi in so I am not sure if I can help there. I guess the solution is to use the midi in of the instrument track (but this limits the controllers), or set up a midi track with the midi in to the hardware midi port and the output to the instrument. In this way you have a specific midi in, only going to the instrument track. You can then select the controller you are using as midi in of the instrument track.
For sysex messages I believe in cubase there is a filter to uncheck so they can go through, but I do not work with sysex so I'm not sure how this setup would behave.

[unityconstruct]

For those running DAW THRU CTRLR to MIDI OUT

item	in-port	out-port
Ctrlr Devices	INDEVICE	OUTDEVICE
FLStudio Devices	x	x
FLStudio Ctrlr VSTi internal ports	4	4
MidiOut track	x	4

• MidiOut Track routes fine to Ctrlr but need the Ctrlr Midi Global Delay set to 40ms so device can handle sysex correctly.
• This delay is also applied to Midi Notes so the sequencer also gets delayed. I couldn't find dedicated option for 'SysexDelay'.
• FL pukes horrendously when things are reversed and Ctrlr routes comms through the DAW - it drops the stream of sysex after about 4-5 msgs when fetching large #'s of params. It might be a combination of sysex in/out that's tripping up the DAW.
• The MIDI THRU opts in Ctrlr didn't seem to circumvent the Midi Global Delay.

Not sure if I'm overlooking an option

[dervur]

Ok, the crash dump is generated regardless of the MIDI device selection (I set them to none, saved, closed, crash dump was there, even in a new project)... But it is not generated if the panel is open within the Ctrlr VST instance... so there is something wrong with the restricted instance I think, at least in Windows... A user experienced the crash in Ableton and Reaper.

[dervur]

Hi Damien, thank you for your reply and for trying to help. The MIDI port was set to “none” albeit I modified your code to introduce a “none” option in a combobox, I’ll copy paste that tomorrow here. Might be part of the issue (albeit it crashes even with the previous version that didn’t have this).

But for that dummy VST that doesn’t crash I did set a MIDI in, it gives me a CTRLR error when I open cubase, but no crash, so I doubt MIDI is involved in the crash.
I even tried to just create the channel with the VST, do not touch the settings, save, close, re-open, and then crash.

Might the issue be the program ID since this is the one line before the access violation? I will take a look tomorrow at the Juce lines for assertion failure

[damiensellier]

There's also Lookandfeel from juce involved in the report.
Did you compile the vst with the modified version of juce modules/juce_gui_basics/lookandfeel/juce_lookandfeel_v4.cpp version included in the repo?

Line 108

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getJetBlackColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xff0b0b0b, 0xff151515, 0xff111111,
             0xff666666, 0xffffffff, 0xffd8d8d8,
             0xffffffff, 0xff606060, 0xffffffff };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getYamDxColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xff0b0b0b, 0xff0f0f0f, 0xff111111,
             0xff666666, 0xfffffbed, 0xff29cfc1,
             0xffffffff, 0xff8584bc, 0xfffffdf2 };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getAkApcColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xff101112, 0xff222326, 0xff101112,
             0xff666666, 0xffffffff, 0xffb3b3b3,
             0xffffffff, 0xffd01634, 0xffffffff };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getAkMpcColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xffefefef, 0xffffffff, 0xffffffff,
             0xffdddddd, 0xff000000, 0xffacacbf,
             0xffffffff, 0xffd01634, 0xff000000 };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getLexiBlueColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xff0d0f0d, 0xff1a1a1a, 0xff111111,
             0xff666666, 0xffffffff, 0xff515459,
             0xffffffff, 0xff5794c7, 0xffffffff };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getKurzGreenColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xff16171a, 0xff111214, 0xff111214,
             0xff666666, 0xffffffff, 0xffd9d1ad,
             0xffffffff, 0xff00a66e, 0xffffffff };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getKorGreyColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xffdddddd, 0xffc1c3c7, 0xffdddddd,
             0xff666666, 0xff0e0e0f, 0xff8c785e,
             0xffe4e4e4, 0xff4a4a4a, 0xff0e0e0f };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getKorGoldColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xff16171f, 0xff0e0f12, 0xff1b1b21,
             0xffdddddd, 0xffffffff, 0xff736745,
             0xffffffff, 0xffa28f57, 0xffffffff };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getArturOrangeColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xff161a1f, 0xff0e1012, 0xff0e1012,
             0xff666666, 0xffffffff, 0xff46494d,
             0xffffffff, 0xffe24a21, 0xffffffff };
}

LookAndFeel_V4::ColourScheme LookAndFeel_V4::getAiraGreenColourScheme() // Added for CtrlrX v5.6.30
{
    return { 0xff191919, 0xff111111, 0xff212121,
             0xff666666, 0xffffffff, 0xffffffff,
             0xffffffff, 0xff00955a, 0xffffffff };
}

juce modules/juce_gui_basics/lookandfeel/juce_lookandfeel_v4.h

Line 107

    static ColourScheme getJetBlackColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getYamDxColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getAkApcColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getAkMpcColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getLexiBlueColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getKurzGreenColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getKorGreyColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getKorGoldColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getArturOrangeColourScheme(); // Added for CtrlrX v5.6.30
    static ColourScheme getAiraGreenColourScheme(); // Added for CtrlrX v5.6.30 

[damiensellier]

I tried to find the problem.
Forget about the juce lookandfeel thing, it must come from the midi single instance problem with windows.
It says explicitly : instance is not multi
Just free your midi ports on the plugin save and recall to see, it should be ok.

Open OK: [MIDIOUT3 (U6MIDI Pro)]
Open FAILED: [None]
CtrlrPanel::setProgram
CtrlrManager::restoreState instance is not multi, exit restoreInstanceState
CtrlrProcessor::getProgramName id:0
(15e40.7c7c): Access violation - code c0000005 (first/second chance not available)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.

[dervur]

So, I use the Juce updated files, I tried to change the look and feel of the dummy plugin, it still opens fine.

Also the dummy plugin opens without crashing even when I set the same MIDI out, that’s why I doubt it is the MIDI. The error also persists if I create a vst track with plugin do not touch the midi settings (so by default are set to none), at opening it still crashes… it is very weird. Anyway, I will try to export a version of the plugin with the menu bar so I can set it to none from there and will report on the findings.

Have you tried opening the plugin on MacOS?

A user managed a crash log on Reaper that says which address was tried to be accessed that triggered the access violation, I will try to look into that tomorrow albeit idk how much use it will be.

edit: might it be coming from a legacy parameter that the restore state is trying to access but is not there? This is the only idea I have left at the moment. The dummy plugin that doesn’t crash has some legacy parameters but maybe mine use others that are problematic? I will have a look on how they differ in that regard…

edit2: the other very weird behavior is that a user told me that both in reaper and ableton it crashes and close the app, as you would expect from a normal crash… to me in Cubase it crashes but then proceeds to open the project and working just fine, it is just very bizzarre. Tomorrow I’ll also upload the panel file so you can open it yourself, sorry I didn’t do this earlier.

[dervur]

Hi Damien, do you know if it is possible to delete from a panel a legacy component so the panel does not use it? The only difference at panel level between the dummy panel, my panels and the Novation X panels is the use of "uiPanelModulatorListViewTree", the dummy panel that doesn't make the VST crash does not have this legacy value, my panels and the Novation X does. I tried by deleting it from the utility sidebar (the one showing the XML), but it did not help. Not even opening the panel in notepad and deleting it from there (it makes Ctrlr itself crash opening the panel).

I'm thinking might be the common denominator of the issue. The dummy panel that doesn't crash when exported, has two other legacy values shared with mine and the Novation X: uiPanelHeight, uiPanelWidth. But these would not be problematic as the dummy plugin opens without crashing.
I then went to Visual Studio and uiPanelHeight and uiPanelWidth only appear in CtrlIDs.h, nowhere else.
On the other hand uiPanelModulatorListViewTree appears in CtrlIDs.h, but also it is used in some functions in CtrlrPanelModulatorList.cpp... Now, I don't know what this value is but maybe its presence in the C++ file might be problematic since it is treated as legacy? Otherwise I don't understand why all the other legacy values only appear in the header, and do not create any issue to the restricted instance... I don't know eh, this is just an idea.
If it is possible to remove somehow from the panel the use of this value we could try and export it and see if it crashes... I'm attaching the Novation X one here since they have in common this thing with mine and it crashes when exported from the current CtrlrX instance. As you are working on CtrlrX, I'm attaching also the dll I'm using so you can try with that and not maybe a modified version.
Novation X-Station_0_4.zip

[damiensellier]

Hi,
I just downloaded your zip on my pc. I removed all the other ctrlr and ctrlrx plugins to have yours showing up in my vst2 folder.
I opened cubase 11 pro. I created a instrument track with ctrlrx as vst2.
I opened the novation panel.
I exported it on my win desktop.
I shut down cubase
I put the exported instance in my vst2 cubase folder
I created a new cubase project
I created a new instrument track with the novation vst2 plugin
It's working great, I even assigned virtual (multiclient) midi in/out ports to it.
I saved the project as novation plugin test
I closed cubase
I reopened cubase
I opened the project novation plugin test
It's working. No issue whatsoever

I have no idea what's wrong on your side.

Send me the zip of your very plugin for volca I'll test it here in cubase 11 windows 10 if you want.

This is what is showing up when I open the project containing the novation panel as vst2 :

[unityconstruct]

Last note:

• Created 3 panels with one mod: No midi, CC7,SysexMessage.. all three exported fine this time around.
• Also added a mod to XStation (with and without CC) and no issues opening dll/vst3 exports on either
• Noticed, that plugin scanning isn't grouping the Volca exports with the others that are loading fine. Possibly irrelevant/unrelated.
  
  

[unityconstruct]

I believe on of the issues I have with Novation X is that even in Ctrlr it does not show the knobs..

@dervur yeah, saw that, it's b/c the panel references resources... this bpanelz has the slider image res. Shouldn't cause an issue, but might. Use this one. 1st time you open it, I think it will copy the img resources to AppData/Ctrlr/*
Novation X-Station_0_4.zip

[unityconstruct]

@dervur Removed all 3 and exports (+2 group refs to modulator-2) still crashing (dll/vst3)

• there's hardly anything in the panel, so def curious
• scrubbed xml and the only variations mod-to-mod is the ordering of the last 3 attributes
  • but this was present in mods other than Pitch/Bend/Time ( but also still crashing on my end :) )

uiSliderValueOutlineColour="ff575155" uiType="uiImageSlider" componentRectangle="16 176 90 90" componentLayerUid="4ed360f2d500000090d38204f77f0000 />
uiSliderValueOutlineColour="ff575155" componentLayerUid="4ed360f2d500000090d38204f77f0000" componentRectangle="368 192 90 90" uiType="uiImageSlider"/>

• did notice a rogue non-printable char on compVisName, removed that, but no change

componentVisibleName="ATTACK
"

• all layer uuids matched
  

[dervur]

This is really weird, to me just deleting one solves the issue. So the problem is not there. I think what I need to do is to do one without copy-paste and see what happens

Analyzing the crash log from Cubase it seems the function "VSTPluginMain" seems to be the issue, but that is not very helpful...

[dobo365]

Hi @dervur , tbh, seeing the issue you have here with Ctrlr but also with CtrlrX when changing from "Microsoft GS Wavetable Synth" to None, I'm pretty sure, as Damien, that there is something wrong on your side as we are not experiencing those issues.
I'm also on Windows 10. Damien has also Win10.
If you have Win11, then that could be the culprit.
Do you have a chance to test the same on a Win 10 PC?

[unityconstruct]

RE MOD Copy:

Next week I will create another panel from scratch, and this time instead of copy pasting from the old panel I will create every modulator as well without any copy paste and see what happens then...

• might suggest to set Look N Feel to default to test with.
  • I had issues with V2 LinearHorizontal not rendering on reopen, so there might be other nuances introduced with LnF.
• I avoid groups and adopted the Layer design pattern. For me, groups just complicated things with no discernible gain beyond providing a 'background' without needing another layer for it. I'm sure more savvy Ctrlr Designers might be using them - and likely for good reasons I don't know.

[unityconstruct]

@unityconstruct since you were able to reproduce a crash when I was not, could you try to export an instance of this panel and confirm me if it crashes or not on your end? I think if it also does not crash on your end it is safe to say that we found the issue with my panels, or at least one of the issues... I tried to change the name on the Volca Sample panel as well but it was not solved by this, but maybe there is an additional issue there...
Korg Volca Kick Controller_1_2_keyboard_chsel_2024-09-03_16-21.zip

@dervur Think its restricted, so have no access to the UI menu for export. Panel opens fine otherwise.

[dervur]

Yeah sorry, I exported that without menu, I uploaded another one about half a hour later, it is above this comment of yours, that should have the menu bar.

In any case I exported a third one that does not crash and give me issues and I sent it to a user and they told me that it shows like this

And that reaper asks them to create 64 mono tracks from it

This keeps getting weirder and weirder....

[dervur]

Ok the issue of the resources was solved by making the user delete the folder in App data, the one of the 64 mono tracks I don't know, but I will send them a new exported version to see if it keeps repeating, if it does I'll make another discussion on github.

Overall, it seems that exporting them in .bpanelz works... kind of. I don't understand why but sometimes they work, sometimes they do not, I have not a valid explanation at this point. But it seems that it is consistent in working if you export as compressed binary+resources from the executable version of CtrlrX (sometimes if you do this step from the VST version the end result of the next step will still crush), then open it in the VST version and export as restricted instance.
I'm trying to make my best in make this thing work 100% of the time, and I will write a guide step by step and set that as answer for this thread. One of my the theories I have is that in general the VST is not capable to properly export things when there are resources and external lua script files instead of having them as method. This explains why if the .bpanelz is exported by the exe it seems to be more stable than when it is done by the VST. And then as the .bpanelz is more stable in holding everything together the VST can successfully convert everything. This is of course just an uneducated theory based on what I observed.
Also an important thing is that these successfully exported VSTs that do not crash have no issue on windows to initialize non-multi client MIDI ports. If the port is not there, you just receive the Ctrlr warning at the opening of a project and that's it, no crash.

I did not try with VST3 yet and that will be one of the next steps. I tried with version 5.6.29 and the issue persists, didn't try with any earlier version.

On a side note @damiensellier does anybody that is actively working on CtrlrX have access to Github Copilot in Visual Studio? As a student I would have free access, and while I'm not a programmer (I know the basics, but I'm just an electronic engineer lol), if having this tool might help with the CtrlrX project I would be happy to activate my free student license and collaborate with you. Especially cause it can analyse different solutions, so if a new version has a bug that was not present in an older one, maybe it could help in solving it? It might even help in migrating to newer Juce versions I believe. I think it is much better than asking abstract questions to Copilot/Chat GPT without access to the project itself. But yeah anyway, I just wanted to say that, if you think it can be helpful let me know, I want to try and give back all the help you gave me this past summer :)

[dervur]

FOUND THE ISSUE, THIS TIME FOR REAL!

I'm sure the repeated numbers of VST index

Forget about the export in "binary + resources". The problematic property is "panelIsDirty", it needs to be 1 when you are exporting to VST, if it is 0, it will make the DAW crash. I do not understand the logic or where the error might be in the code, also because looking at the code it seems that this variable is 1 when you made a change and need to save a panel. But this must be it, because I fixed all my other panels by opening them in the notepad and modifying this value to 1...

The reason why most of my .bpanelz export were working is because I would export these BEFORE saving a panel, thence the property was saved as 1 in the exported version. In a normal scenario I work on my panels in the EXE version of CtrlrX, save, open the VST version of Ctrlr, open the panel and export (e.g., "panelIsDirty" = 0). As I said this worked 100% of the time in my panels, therefore I think this must be it. I think it must be a bug because I don't see why an unsaved panel does not crash and a saved one does... It might be an issue on my system or my built CtrlrX, I don't know (I have the last build so I doubt is this, the only thing I modify on the build is the thing about not letting CtrlrX export unassigned parameters in the VST).

@unityconstruct I remember you mentioned you were having a similar issue with some of your panels crashing? Maybe you could try this

But yeah summary is, for anybody with the same issue and for people that might come to this thread for this problem in the future: make sure that the VST index is not repeated across your modulators. Open your panel in the notepad, check for "panelIsDirty", set it to 1, save, open your panel in the VST version of CtrlrX and export your restricted instance without saving your panel.
The reason why I don't say to just modify something before exporting is because apparently if you modify something while in VST mode that part remains to 0.
Also, if you are not exporting a modulator to host, the VST index does not matter, I just tried to export a panel with two buttons that had the vst index to 2050 but were not exported (the ones to save and load presets), and this did not make the VST crash.

[unityconstruct]

hey @dervur, work has me pinned down last few days. Will parse your updates & will definitely investigate my two panels.
THANK YOU for staying on it and posting Q's/Thoughts/ideas/theories as things like this serve present/future users. I've been benefiting from the ctrlr.org forum materials for months.

RE: Missing Resources

I'm not 100% sure on what the workflow SHOULD be, but my observations are:

• *.panel file that references resources... uses the temp dir for the actual files.
• when you open a *.bpanelz file, it extracts resources to the temp dir and subsequent saves will be normal *.panel files.
• compressed panel is only compressing the XML, so will NOT include the resources.
• the ONLY way to send panels to others is via *.bpanelz ( binary panel zipped )
• if a remote user opens a panel file, they'll see the 'missing resources' message b/c they don't have the images in their temp dir... the panel would still work theoretically, but knobs won't have their image.

So if you want to pass around ( or archive ) your panel, make sure to export it to *.bpanelz (or Binary EXE/VST for a standalone version that doesn't require Ctrlr).

Yes I have yet to be able to export a happy VSTi, my symptoms is the VST Host quickly consuming available memory (16G in a few seconds). I have an EMU CommandStation panel with 1000+ mods and tons of code & thought maybe that was it, but my current MC303 panel sees basically the same issue. During testing on new panels with only a few mods, I wasn't seeing the memory issue, but WAS seeing the immediate crash issue. Possible, these are unrelated probs.

Thanks again for this latest update and I'll try to confirm by EOW.

BTW: Git

I think I saw Lua code-behind in your panel, so if you aren't already, I HIGHLY recommend using GIT and use frequent commit/push. If this is new to you, check out YouTube vids. Benefit here is that if something shitz out, you can always get it back and it also allows DIFF of changes so if something stops working, frequently its quick to fix. On the old site, I saw more than one desperate cat after his entire project as whacked after a crash.

[unityconstruct]

@dervur Been wondering about this for a while, but my VSTIndex values are retarded big.. I noticed yours started at 1 a few days ago. So just created a NEW panel and added one mod and its VSTIndex is 333335160, so going to set mine back starting at 1. I suspect when VSTHost is parsing the panel, its mapping these ids and perhaps it has to map from 1-whatever my first index is... 333+ million might explain my memory issue. So it might be that you have led me to solve both my issues 😜

[damiensellier]

Hi @dervur Thanks for investigating about this issue. We updated the "panelisdirty" behaviour in the latest ctrlrx version 5.6.30
before when you did "save as" the panel was still flagged as dirty but I did change the code to have it set to 0 not 1 in this particular case.
I will check everything about the panelisdirty thing to fix everything in the next version. I'm really busy right now but as soon as I find some free time I'll fix the bug you experienced about that, it should be minor with a statement to load the resource only if it's 0 or 1.

I created an issue on the ctrlrx repo : damiensellier#37
if you want to help with that, you can participate to the discussion there ;)

Thanks!
Damien

[unityconstruct]

But yeah summary is for anybody with the same issue, for people that might come to this thread for this problem in the future: make sure that the VST index is not repeated across your modulators. Open your panel in the notepad, check for "panelIsDirty", set it to 1, save, open your panel in the VST version of CtrlrX and export your restricted instance without saving your panel.

@dervur HOLYSHAT!!! Fixed both my problems brother!

• DirtyBit 0>1 fixed opening VSTDLL/VST3 export crashes
• totally whack VSTIndex #'s fixed my 'MemorySink-on-scan' issue. Update4d 400+ mods starting from 1 and VSTHost open/export working. Will be looking at my EMU panel soon.
  Feel like I send you a check 😂

[unityconstruct]

RE: MIDI

• Think recommendation was to have CTRLR go direct to MIDI I/O ports
• These settings allowed bidirectional DAW MIDI comms to device through Ctrlr.
  • Ports assigned to Ctrlr will be unavailable to the DAW (unless it can port-share)
  • FLStudio provides a means to add virtual ports, so one can send MIDI to the device when Ctrlr commandeers such ports.
    • MIDI Thru is where one would facilitate this.
    • If one is only going to interact with the device via Ctrlr the MIDI Thru flags aren't necessary.
      

[dervur]

Yes, I think I'm more confident with MIDI now. I think I prefer to use the DAW rather than the panel in Windows to assign out and input because of port-share issues.

[Psychlist1972]

Hi All.

Thanks to @dobo365 for reaching out.

"PS. Not sure it's available yet, MS is not really open about it."

The Windows MIDI Services project is open source and on Github, with discussions on Discord. I've also presented about it at NAMM, on podcasts, and more. I thought we were being quite transparent, especially for a new Windows API, but maybe I missed the mark. https://aka.ms/midi Given that I do the outreach for this, please LMK how I can/should do better.

Note that the releases available today are developer releases, but once we are ready for customers to test, we'll announce it. We're also working to get this into an upcoming Insider build so advanced customers can try it out. But developers have everything they need today to get started implementing the API / SDK in their apps.

"I would also add finally Windows is implementing it after decades of MIDI being a thing"

IMO, this should be celebrated, not derided.

Once the old WinMM API was created and shipped, no one wanted to touch it again. Multi-client wasn't a requirement in the original spec for USB MIDI and I guess no one thought that would be needed back in 1999-ish. Besides multi-client, I was always disappointed in the need to write drivers to do anything custom with MIDI, and so I wanted to fix all that.

Support for MIDI 2.0 gave us permission to rewrite from the ground up, which has taken a while because it's everything from the driver to the new API, plus all the MIDI 2.0-specifics like protocol negotiation, discovery, etc. and infrastructure for plugins for transports (available in the builds now) and message processing (coming after the initial in-box "1.0" release). Internally, everything in the service works on MIDI 2.0 messages, and translates only when needed. Communication with the new driver (which handles both USB MIDI 1.0 and USB MIDI 2.0 devices, when selected) is much faster and more efficient than the approach the original driver uses.

The latest work we're finishing up is for winmm backwards compatibility. It's partially there in internal builds as you can see by my video here:

https://www.youtube.com/watch?v=Oa6_pVveqPI

That's one piece we have to get 100% correct before we consider v1 complete and shippable. This is non-trivial work because the older winmm API just isn't very friendly for the types of things we're doing here, and we need to try to replicate the same return codes in the same scenarios etc. The old API was written in such a way that the apps communicate almost directly with the kernel driver, which is why multi-client that works across all devices and all third-party drivers was nearly impossible to do without the rewrite we're wrapping up.

Because of the way the winmm works, we created a MIDI driver which forwards the requests to the new service, using the generated backwards-compatible MIDI 1 ports it enumerates, and our translation pipeline. We then had to modify AudioEndpointBuilder (the one part of this which is not open source) to defer MIDI endpoint enumeration to MidiSrv when Windows MIDI Services is present.

"NOTE: Pete told me afterwards that finally they found a solution for Midi-OX so it will also work fine!"

MIDI-OX uses an old 32-bit library for MIDI, which is why it doesn't work with the 64-bit development builds today. We believe we have an approach which will enable it to work once the bits are in Windows, but it needs more testing once we are in Windows Insider builds. Also, the new stack and tools like the MIDI Console and MIDI Settings app natively do a lot of what folks use tools like MIDI-OX for today, so it may be less necessary in the future. I'm curious to know from folks here if there are things they use MIDI-OX for on a regular basis so we can make sure we're covering all the common scenarios.

The best experience/performance will come with adopting the new API/SDK natively (we have developer previews available on the repo), especially as we work to include the upcoming Network MIDI 2.0 standard, and re-implement BLE MIDI 1.0. We have several partners working with us and using the developer builds to do just that. When app developers adopt the new API & SDK, they get things like plug/unplug notifications, endpoint property change notifications, better endpoint naming, the ability to programmatically create loopback endpoints and also virtual devices, efficient communication with the service, and more.

Pete
Microsoft

[unityconstruct]

'm curious to know from folks here if there are things they use MIDI-OX for on a regular basis so we can make sure we're covering all the common scenarios.

@Psychlist1972 Thanks for the info Pete! I'm sure you've endured a fair amount of slings and arrows. While I've had my fair share of WinRoadRage since the days of my first Win98SE SoundBlaster AWE32Pnp box, WinXP was a massive improvement and Win7 (obviously outside the scope of Midi Updates) was so spectacular that its still my main workhorse handling 4 'maxed out' MOTU 828mkII and an ungodly amount of USB devices without a hiccup... to the extent my only real fear is the poor single outlet running half of it.. or where the next piece of 'must have' gear will go... or if the entire affair will simply just collapse into my downstairs living room. I digress...

As for MidiOx (in no particular order of import):

• Midi Monitor (logging) with Filter Options (& save ops)
• Midi Status (grid showing what messages are Rx/Tx)
• Midi Filtering (particularly helpful when dealing with devices like Yamaha EX5 that spew Active Sensing(FEH) and TimingClock(F8H) with curiously no means to disable it)
• Loopback Ports (ie: MidiYoke)
• Virtual Keyboard (namely for setup & triage of issues)
• Sysex Rx/Tx (for dumps)
• Midi Split/Duplication
• Midi Merge (understanding this can cause user-induced mayhem)
• Midi Port Routing
• All Sound Off / All Note Off / Reset All Controllers
• MTC Transport
• Profile Management
  • Midi Config Profiles
  • MidiTools Profiles (if 'MidiOx' tools are aggregated into a single app)
    • save-able Setup profiles are a big help both in eliminating human error involved with repetitively configuring each time a theoretical app is loaded
    • allows for fast, 'error free' config changes when needed
• CLI interface (along the lines of the beloved 'sc.exe' api) would be swell, but unsure of size of audience for that type of thing.
  • scripting things is nice alternative to "hand-config>save to profile" and allows for portability & git archive (along the lines of Azure pipeline yml, although that's declarative)

Other:

• Adhoc Sysex/CC/RPN/NRPN Send
• EthernetMIDI would be HUGE
• OneNote Search/Replace 😎

Thanks again sir!

[Psychlist1972]

'm curious to know from folks here if there are things they use MIDI-OX for on a regular basis so we can make sure we're covering all the common scenarios.

@Psychlist1972 Thanks for the info Pete! I'm sure you've endured a fair amount of slings and arrows. While I've had my fair share of WinRoadRage since the days of my first Win98SE SoundBlaster AWE32Pnp box, WinXP was a massive improvement and Win7 (obviously outside the scope of Midi Updates) was so spectacular that its still my main workhorse handling 4 'maxed out' MOTU 828mkII and an ungodly amount of USB devices without a hiccup... to the extent my only real fear is the poor single outlet running half of it.. or where the next piece of 'must have' gear will go... or if the entire affair will simply just collapse into my downstairs living room. I digress...

Thanks :)

Let's see how many of these we'll have covered with what we're planning to deliver for v1.

As for MidiOx (in no particular order of import):

• Midi Monitor (logging) with Filter Options (& save ops)

This is built into the MIDI console. "midi endpoint monitor". If you specify the Id of the endpoint, then you can start monitoring with no other interaction. Otherwise, you are prompted for the endpoint.

• Midi Status (grid showing what messages are Rx/Tx)

That I'll need to look into.

• Midi Filtering (particularly helpful when dealing with devices like Yamaha EX5 that spew Active Sensing(FEH) and TimingClock(F8H) with curiously no means to disable it)

I have a couple other Yamaha boards here and they are all chatty :) Filtering hasn't made it for 1.0, but most of the infrastructure is there, so it'll be a fast follow-on

• Loopback Ports (ie: MidiYoke)

Built-in to Windows MIDI Services. We have diagnostics loopback endpoints which can be used to verify things are running, and then we have regular loopback endpoints that can be created by the user or by applications. Finally, we have virtual devices which are like loopbacks, but they have a lot more MIDI 2.0 functionality tied to them so an application can act as a real MIDI 2.0 device, and respond to all the appropriate queries.

• Virtual Keyboard (namely for setup & triage of issues)

Right now I have a virtual 16-pad grid. I plan to create a keyboard, but it's not there just yet. Good idea.

• Sysex Rx/Tx (for dumps)

Sending MIDI 1.0 SysEx files is in the console as well as the GUI settings app. Receiving is coming.

You can also save a dump of any arbitrary messages, but they are in UMP format. Roland, Yamaha, and others have been using this for repeated testing, because you can also send messages from the files.

• Midi Split/Duplication
• Midi Merge (understanding this can cause user-induced mayhem)
• Midi Port Routing

Virtual Patch Bay is something I've been working on. It's easy to split / merge when you have the messages in UMP format. It's not going to make it for v1, but will be there shortly afterwards.

• All Sound Off / All Note Off / Reset All Controllers

I'll see what I can do on this one. In a MIDI 2.0 device, that's a lot of messages since you still use channel messages for this, and each device can have up to 16 groups of 16 channels. There's no global device "panic" just yet.

• MTC Transport

I haven't used this in MIDI-OX. I'll look into this. I'm actually surprised to hear folks use MIDI-OX for that.

• Profile Management

  • Midi Config Profiles

  • MidiTools Profiles (if 'MidiOx' tools are aggregated into a single app)

    • save-able Setup profiles are a big help both in eliminating human error involved with repetitively configuring each time a theoretical app is loaded
    • allows for fast, 'error free' config changes when needed

MIDI 2.0 has something called a Profile (from Profiles and Property Exchange) so we call these "Setups". The setup is stored in a json file that you can, with some care, reuse on another device. Intent is to make it easy to move your settings between, say, a studio PC and a laptop you bring with you to perform. The reason I say "with some care" is because most USB devices today do not have serial numbers, and so get new Ids when you plug them in. This becomes a problem especially if you have more than one of the same device, and you have custom properties for them.

• CLI interface (along the lines of the beloved 'sc.exe' api) would be swell, but unsure of size of audience for that type of thing.

  • scripting things is nice alternative to "hand-config>save to profile" and allows for portability & git archive (along the lines of Azure pipeline yml, although that's declarative)

Right now, the MIDI console is the # 1 way folks have been testing devices with Windows MIDI Services, so it is the most complete tool. It also has more user-focused info like properties for endpoints. It's scriptable, but if folks want to do more complex multi-step operations, I may want to augment that. Right now, each time you send a command, it makes a connection, sends the info, and then disconnects.

Other:

• Adhoc Sysex/CC/RPN/NRPN Send

Right now, this requires you to understand the messages in MIDI UMP format. I'm looking for more GUI approach, but won't have it out in time for v1. Good idea.

• EthernetMIDI would be HUGE

I agree! I'm working to have a near-production-ready prototype ready by NAMM. The spec is finished now and will just need to be voted in.

• OneNote Search/Replace 😎

Thanks again sir!

So we have some, but not all. Thanks for the detailed list!

I should also mention that the new service has built-in outbound message scheduling for timestamped messages. Oh, and everything works on 64 bit Intel/AMD as well as 64 bit Arm64 Windows PCs.

Finally, here's an in-progress look at the MIDI settings app.

(and +1 to the OneNote request :) )

I realize I'm filling up someone else's Github bug report/discussion here, which isn't cool of me to do, so if folks have requests/suggestions for Windows MIDI Services, please join our discord server at https://aka.ms/mididiscord or if a bug, log it on our github repo https://aka.ms/midirepo

Pete

[unityconstruct]

Full disclosure: Profiles not in MidiOx, but their addition to CueMix (and some other device front-ends) pushes back my already-early-click-induced-onset of arthritis by saving me 400 additional clicks per session. Also tends to reduce user-error/complain/nuisance. Figured I'd throw it in there. None are hills to die on for myself.

I likes!

Again, much love on the outreach of information sir!

[damiensellier]

@Psychlist1972 HI Pete, Thank you so much for reaching out with our small Ctrlr community.
Multi-Client on pc is obviously what we struggle the most with since it requires the user to use virtual port solutions and some non-standard settings in the different hosts.
Ctrlr is just a JUCE application and more than 50% of VSTs are developped on the JUCE framework nowadays. I guess you are already in touch with the guys at JUCE, and everyone there should be really happy about your new MS MIDI implementation because there was so many posts on their forum about muti-client, midi 2.0 etc over the years.
I suggest you write about it like you did in a dedicated thread on the JUCE forum, you'll get some love there :) :
https://forum.juce.com/c/general-juce-discussion/10

Can't wait to test the new MIDI multi-client capabilities on WIN 10 and WIN 11 and bypass all those annoying virtual port managers and virtual MIDI routers. Built in capabilities will be a big relief for our projects!

Thanks for your help Pete.

Damien

[dervur]

"IMO, this should be celebrated, not derided."

I'm sorry if it looked like this choice was derided. I of course celebrate this decision, it was more of a frustrated comment because dealing with MIDI on Windows it has been quite frustrating with a lot of annoying virtual ports and loops.

Of course I can't wait to have this feature and thank you for the answer. This looks truly amazing.

[damiensellier]

Hi @dervur, I'm trying to understand exactly what's happening under the hood with this PanelIsDirty property.

This property has no effect when opening a panel either as panel file or as a vst/app instance.
It only helps to determine if a current project/pannel has been modified and show some hints in the GUI about that (title as * suffix, when trying to close it gives an alert that it's been changed etc). But it's reset to 0 when saved or saved as or exported.

I'm still trying to understand exactly when it crashes.

• Is it when you load Ctrlr in your DAW as a VST and open a panel, then export this very panel as a new Instance (restricted/unrestricted)?

I'm trying to figure out at which point PanelIsDirty is required to be True vs false to avoid crashing the daw. I never experienced that on Mac.

If you can give me the exact steps to replicate the crash I'd appreciate it.

The issue page is here : damiensellier#37

Thanks
Damien

[damiensellier]

Not sure if it's really gone, I think the line of code is trying to look for panelisdirty in the top level properties' tree.
I'll add another line at the panel level to clear it as well to be 100% sure.
I'll post later about where and what to add and will let you know.

[damiensellier]

@unityconstruct so from what you exported, if you check in the xml from the CTRLR side panel utility tab you don't get the panelIsDirty="0" key in the "panel" line ?

<panel name="panelname" panelShowDialogs="1" panelMessageTime="10000.0"
       panelAuthorName="" panelAuthorEmail="" panelAuthorDonateUrl=""
       panelAuthorUrl="" panelAuthorDesc="" panelVersionMajor="1.0"
       panelVersionMinor="0" panelVersionName="" panelVendor="" panelDevice=""
       panelMidiSnapshotAfterLoad="0" panelMidiSnapshotAfterProgramChange="0"
  ...
       panelResources="-- None" panelPropertyDisplayIDs="0" ctrlrUseEditorWrapper="0"
       panelIndex="0" panelIsDirty="0"> // HERE

[unityconstruct]

@damiensellier the Instance.dll doesn't show tabs as with the CtrlrX.exe, don't see a way to access underlying XML
Instance.dll is in forground(no tabs)
CtrlrX.exe is in background(with tabs) - far Right

BUT....
From the Instance.dll, just did SaveAs, and XML has NO panelIsDirty attribute
Note: Doh! This was from VST, not VST3
DirtyFixPanelVST3InstanceSaveToPanel.zip

      panelResources="-- None" panelPropertyDisplayIDs="1" ctrlrUseEditorWrapper="0"
       panelIndex="0" uiPanelEditMode="0">

[damiensellier]

YEP it's gone, I just checked :

This is the exported VST panel xml :

<panel name="paneldirtybug" panelShowDialogs="1" panelMessageTime="10000.0"
       panelAuthorName="damientest" panelAuthorEmail="" panelAuthorDonateUrl=""
...
       panelResources="-- None" panelPropertyDisplayIDs="0" ctrlrUseEditorWrapper="0"
       panelIndex="0" uiPanelEditMode="0"> //  panelIsDirty prop is gone

I'll wait for @dervur to confirm but I'm calling it a FIX.
Thanks @unityconstruct for your help
Damien

[damiensellier]

The Tabs not showing up in the exported (not restricted) VST instance is another problem to solve :)
No idea why but I'll open an Issue in the CtrlrX bug report.

damiensellier#40