Panel Name and Author Name (Ctrlr|Instigator) don't change while exported as VST2 & VST3

[damiensellier]

Hi everybody,

I tried to export vst3 instances with the latest versions of ctrlr (5.6 and above).
Ctrlr.vst3 is working fine, that's alright.
But if you export an instance from the vst3 within the host to get a vst3 version of your panel, the exported vst3 is not ok.

This is what I understood :
the exported vst3 actually works as intended.
BUT the plugin name, whatever you called it (Global "name" and "PanelAuthorname") stays "Ctrlr" and "Instigator".
This is the reason why we cannot see our exported vst3 instances since they have the same global name and publisher name than the original ctrlr plugin (already available in your plugin directory).

The host sees that as a duplicate and discards it. If the ctrlr.vst3 is removed from the plugin directory, you'll see your exported instance with the wrong name.

So it's not about the plugin itself but how it's identified during the export. It should be listed properly by the given name and your author name from the global settings.

I don't think it would be too hard to find the reason from the binaries but I'm a newbie in app building so it's definitely not something I feel good enough to fiddle with.

Any help would be appreciated ;)

Thanks in advance!

Damien

[damiensellier]

I exported version 5.6.23 (shown as 5.5.0) VST2 version successfully. It's a little bit better, the exported instance from VST2 has its name changed according to the global panel "name" but the "vendor name" is still "Instigator" not the custom one from the global PanelAuthorname field. I could not find where the connection between the global panel fields (name and PanelAuthorname) and the vst infos within the host is failing.

[damiensellier]

I narrowed down where the problem could occure.
everything related to the panel identification in the host is in the following source files :
https://github.com/RomanKubiak/ctrlr/blob/master/Source/Native/CtrlrMac.cpp
https://github.com/RomanKubiak/ctrlr/blob/master/Source/Core/CtrlrManager/CtrlrManagerInstance.cpp

The first one "CtrlrMac.cpp", creates the VST bundle (folder) containing Info.plist which is actually an XML tree including the name of the panel and the AuthorName.
So it's very possible, this info.plist is not well read by ctrlr in the host.

The second one "CtrlrManagerInstance.cpp" is the most relevant.
From Line 83 this is where the magic happens :

const String CtrlrManager::getInstanceNameForHost() const
{
	if (getInstanceMode() == InstanceSingle
        || getInstanceMode() == InstanceSingleRestriced)
	{
		return (ctrlrPlayerInstanceTree.getProperty(Ids::name).toString() + "|" + ctrlrPlayerInstanceTree.getProperty(Ids::panelAuthorName).toString());
	}
	else
	{
		return ("Ctrlr|Instigator");
	}
}

const String CtrlrManager::getInstanceName() const
{
	if (isSingleInstance())
	{
		return (ctrlrPlayerInstanceTree.getProperty(Ids::name));
	}
	else
	{
		return ("Ctrlr");
	}
}

the previous working version had a slightly different code for that :

const String CtrlrManager::getInstanceNameForHost() const
{
	if (getInstanceMode() == InstanceSingle
        || getInstanceMode() == InstanceSingleRestriced)
	{
		return (ctrlrPlayerInstanceTree.getProperty(Ids::name).toString() + "|" + ctrlrPlayerInstanceTree.getProperty(Ids::panelAuthorName).toString());
	}
	else
	{
		return ("Ctrlr|Instigator");
	}
}

const String CtrlrManager::getInstanceName() const
{
	if (getInstanceMode() == InstanceSingle
        || getInstanceMode() == InstanceSingleRestriced)
	{
		return (ctrlrPlayerInstanceTree.getProperty(Ids::name));
	}
	else
	{
		return ("Ctrlr");
	}
}

So my bet is that the issue is coming from that particular file, or not far away.

EDIT 2023.03.04: This is only for VST2 identification not for VST3 unfortunately.

[damiensellier]

Ahaha I saw that and replied, but your post disappeared. As mentioned before this code snippet is only for VST2 unfortunately.

If we can just override the Projucer preprocessor global variables passed to the JUCE VST3 wrapper it's a win 100%.

ctrlr/JUCE/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp

Line 3417 in c1f67d2

globalFactory = new JucePluginFactory();

See my newer post below where I posted the exact lines to work with. #394 (reply in thread)

Not sure if it's possible from the CtrlrProcessor.cpp, where everything really starts.
From JUCE Diagrams, the host loads the VST3 Juce wrapper, then the wrapper calls the CtrlrProcessor. If we can pass the name of the panel, author and GUID from the panel XML tree to the VST3 Wrapper that would be the best solution.

[dnaldoog]

So in this file there are fixed define constants.

ctrlr/JuceLibraryCode/JucePluginDefines.h

Line 41 in 69a38a1

#define JucePlugin_Name "Ctrlr"

If you substituted the JUCE constant JucePlugin_Name say on line 41 would that work?

Just stabbing in the dark of course!

[damiensellier]

No, unfortunately it will not work. Those variables are used by xcode and visual studio to build Ctrlr and are used later to define the VST3 PluginFactory class used by the Host like Cubase according to the Steinberg VST3 sdk. But they are static.
What we need a is dynamic way of feeding our panel ID details (Panel Name, Panel Author, Panel GUID, Panel Version) to the Juce VST3 wrapper. So if you change the JucePlugin_Name at line 41 you'll get a Ctrlr build with this substitute name but it will remain static. This is exactly what we do now from the Projucer to export custom intermediate Builds that matches our panel names to get the final VST3 plugin named properly recognized as such in Cubase. But that's not dynamic and this is why it requires building a new VST3 intermediate instance with a custom name everytime we need a new VST3 panel. If you don't go through this process, you'll get a plugin recognized in Cubase as "Ctrlr" by "Instigator" whatever the panel name & author are.

What we really need to override is the following variables in the juce_VST3_Wrapper.cpp:

static const PClassInfo2 componentClass (JuceVST3Component::iid,
PClassInfo::kManyInstances,
kVstAudioEffectClass,
JucePlugin_Name,
JucePlugin_Vst3ComponentFlags,
JucePlugin_Vst3Category,
JucePlugin_Manufacturer,
JucePlugin_VersionString,
kVstVersionString);

So this is why we would need to override them from the CtrlrProcessor if it's possible with a dynamic definition that passes the datas from the different IDs in the Panel XML tree. Or worst case scenario just replace those variables directly in the juce_VST3_Wrapper.cpp by using other variables names which refers to those Panel ID values associated to a function that grabs those XML keys from the panel.

static const PClassInfo2 componentClass (JuceVST3Component::iid,
PClassInfo::kManyInstances,
kVstAudioEffectClass,
JucePlugin_Name, // needs to be replaced by JucePluginNameForHost
JucePlugin_Vst3ComponentFlags,
JucePlugin_Vst3Category,
JucePlugin_Manufacturer, // needs to be replaced by JucePluginManufacturerForHost
JucePlugin_VersionString, // needs to be replaced by JucePluginVersionForHost
kVstVersionString);

This method is used somewhere else in the Ctrlr core with something like:

ctrlr/Source/Core/CtrlrManager/CtrlrManagerInstance.cpp

Line 96 in c1f67d2

const String CtrlrManager::getInstanceName() const

const String CtrlrManager::getInstanceName() const
{
	if (isSingleInstance())
	{
		return (ctrlrPlayerInstanceTree.getProperty(Ids::name));
	}
	else
	{
		return ("Ctrlr");
	}
}

It shouldn't be too much different to get the panel name, the author name and the version name etc to pass those results as the new variables required by our modded JUCE VST3 wrapper.

...

This is where my skills stops, I understood the mechanic and the logic but I don't know how to speak C++ to
achieve that. We probably need to link to the CtrlrManagerInstance.cpp file in the header, then add those new variables names as overrides in the .h file create 4 new void functions to grab those values from the XML and pass them to the static const PClassInfo2 componentClass at the end of the JUCE VST3 wrapper file. I would need to go back to school :)

[dnaldoog]

It looks difficult and obviously you have done a very deep dive. I some small knowledge of C++ so if I can help I will.

[damiensellier]

@dnaldoog I don't think it's going to be too difficult, it's just I don't know how to create a good c++ structure that says :
JucePluginNameForHost = ctrlrPlayerInstanceTree.getProperty(Ids::name) // for all required VST3 Identification variables

And how to link the Juce VST3 wrapper to the ctrlrPlayerInstanceTree function properly. we need to define 5 new variables :

JucePluginNameForHost
JucePluginManufacturerForHost
JucePlugin_ManufacturerCodeForHost
JucePlugin_VersionStringForHost
JucePlugin_PluginIdForHost

and put them at the end of the Juce VST3 wrapper instead of :

JucePlugin_Name
JucePlugin_Manufacturer
JucePlugin_ManufacturerCode
JucePlugin_VersionString
JucePlugin_PluginCode

Is it something you could do? Let me know if you need more infos ;)
Damien

[Godlike-Productions]

I'm finding that the VST3's created from 5.6.23 won't receive any MIDI from the host. This is a major issue, especially on Windows where you can only assign each MIDI port either to the host or to Ctrlr. You need to be able to pass MIDI from the host through Ctrlr to the underlying MIDI port (for example to pass note data).

Can anyone else confirm whether they see this, or if they know how to solve the problem. I'm not sure if this is the same on Macs or not.

I can't get the MIDI monitor to show any MIDI input from the host even on a brand new panel. It does show MIDI In and Out to and from the physical port, but no connection to the host :(

I notice that there is an option for No MIDI Input to Panel

I wonder if there's some code around this that is disabling MIDI being received to the panel regardless of this option.

[Godlike-Productions]

A bit more testing here. The "generic" 5.6.23 VST3 that Sjoerd initially did for me allows MIDI input. It's just the customized one that doesn't work. Soooooo close.

[damiensellier]

I never tried using it on a PC, so I can't tell. I am really procrastinating on exporting my panels as PC VSTs, I'm a little bit scared to face problems like this. I'll try and I'll tell you if I have the same issue.
I never used this global no midi input from panel. Maybe it's the culprit.
I'm running my panels everyday to check if there's some issue on the mid term but for now on Mac intel I have zero problem.
I'll come back to you about my Win10 experience asap.
Cheers
Damien

[Godlike-Productions]

I'm half way through my first build on a native Win 10 system (not in an emulator). I'll let you know how I go.

[Godlike-Productions]

I got it working. The build from Windows with Visual Studio 19 allows MIDI input.

[dobo365]

Hi John, would it be possible to have the results of your build (exe, app, vst2, vst3, au)? Which version will this be as the last one I have is 5.6.23 (but I never used it). Would like to export in VST3.
Other question: did you documented all steps to make such a build?
If I well remember, Damien did a Word document but I never tried it.
I have also Windows 10 and VS2019 installed so could be interested in your version.

[Godlike-Productions]

Not sure this is aimed at me (I'm Jason BTW), so was a bit confused.

Anyway, I didn't document all the steps, and when I tried again later, something failed. I'm going to try this again soon, and will try to document what I do. It was a while ago, and I've been very busy with legal stuff and other projects.

[Godlike-Productions]

I've successfully built 5.6.29 in VS2019. You need projucer 6.0.8 (though others have had it working in 6.1.3 and 6.1.4, I had no luck with 6.1.6, but it could have been other issues). 6.0.8 is available here - https://github.com/juce-framework/JUCE/releases/tag/6.0.8

Otherwise follow the instructions in the document here - https://godlike.com.au/index.php?id=361 (download the compiling on win 10 pdf).

To make custom named VST3's, change the details in projucer here

and here

both accessible when you click the gear icon.

Once you've changed them, press the export to VS2019 button, follow the pdf to compile the shared code and then compile the VST3. The VST3 is your new constructor. It will have the correct name, but you'll need to open your ctrlr project as normal and create a restricted instance from the VST3.

If you need to make more vst3 constructors, change the details in projucer, re-export, then compile the shared code and then the VST3 again. There is a tool in this thread that will save the step of projucer and recompile shared code, but I haven't tried it. I only have a few to do, so it doesn't take too long.

[damiensellier]

Hi everybody,

I make reference to the VST3 naming issue we talked above. I investigate and found why it's not working as VST3.

To recap:
the exported vst3 actually works as intended. BUT the plugin name, whatever you called it (Global "name" and "PanelAuthorname") stays "Ctrlr" and "Instigator" because the name is taken from the ProJucer settings from the VST3 build.
This is the reason why we cannot see our exported vst3 instances since they have the same global name and publisher name than the original ctrlr plugin (already available in your plugin directory).

So, here is what I found:

The VST2 exported naming works properly because the name is passed to the host with the following JUCE function AudioProcessor::getName() :

ctrlr/Source/Plugin/CtrlrProcessor.cpp

Line 66 in 8aa00d8

const String CtrlrProcessor::getName() const

const String CtrlrProcessor::getName() const
{
	if (ctrlrManager)
    {
		return (ctrlrManager->getInstanceNameForHost());
    }
	else
    {
		return ("Ctrlr");
    }
}

This function refers to :

ctrlr/Source/Core/CtrlrManager/CtrlrManagerInstance.cpp

Line 83 in c1f67d2

const String CtrlrManager::getInstanceNameForHost() const

const String CtrlrManager::getInstanceNameForHost() const
{
	if (getInstanceMode() == InstanceSingle
        || getInstanceMode() == InstanceSingleRestriced)
	{
		return (ctrlrPlayerInstanceTree.getProperty(Ids::name).toString() + "|" + ctrlrPlayerInstanceTree.getProperty(Ids::panelAuthorName).toString());
	}
	else
	{
		return ("Ctrlr|Instigator");
	}
}

The way VST2 get its name is different from VST3. It seems that CtrlrProcessor::getName() cannot pass the name to the JUCE VST3 wrapper module. I don't know why exactly, maybe because of JUCE not passing the name properly to the VST3 instance, or maybe because of the sequence of loading which is different from VST2 and VST3 in the host.

The VST3 plugin strings passed to the host are exactly there:

ctrlr/JUCE/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp

Line 3419 in c1f67d2

static const PClassInfo2 componentClass (JuceVST3Component::iid,

according to the VST3 sdk.

static const PClassInfo2 componentClass (JuceVST3Component::iid,
                                                 PClassInfo::kManyInstances,
                                                 kVstAudioEffectClass,
                                                 JucePlugin_Name,
                                                 JucePlugin_Vst3ComponentFlags,
                                                 JucePlugin_Vst3Category,
                                                 JucePlugin_Manufacturer,
                                                 JucePlugin_VersionString,
                                                 kVstVersionString);

As we can see, JucePlugin_Name is the name we set in the Projucer configuration in the field "Plugin Name". Same for JucePlugin_Manufacturer etc It's all defined in the Projucer project settings. And this is what we have to dynamically override them another way.

So we would need to either override JucePlugin_Name from the CtrlrProcessor.cpp with a declaration like :

JucePlugin_Name = ctrlrPlayerInstanceTree.getProperty(Ids::name).toString() 
JucePlugin_Manufacturer = ctrlrPlayerInstanceTree.getProperty(Ids::author).toString() 

Or replace JucePlugin_Name directly in juce_VST3_Wrapper.cpp L3419 with the appropriate code that gets the panel name from the Panel Properties xml tree.

Or even get those info from Info.plist located in the VST3 package in /Contents/ Those are updated during the export of the panel instance.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDisplayName</key>
	<string>Ctrlr</string>
	<key>CFBundleExecutable</key>
	<string>Ctrlr</string>
	<key>CFBundleIdentifier</key>
	<string>com.instigator.Ctrlr</string>
	<key>CFBundleName</key>
	<string>Ctrlr</string>

	<key>NSHumanReadableCopyright</key>
	<string>instigator</string>
</dict>
</plist>

I don't know how to write that in a C++ syntax but this would be the solution to have dynamic naming for VST3 exported instances of our panels instead of having to build VST3 CTRLR instance with the name of the panel hard coded as JucePlugin_Name.

Is anyone fluent enough with C++ could help with that? That would be awesome and would allow to export 1 CTRLR build for as many as VST3 CTRLR pannels we want.

Thanks

Damien

[damiensellier]

Hi @bijlevel . Good news! hope everything is fine on your side.
Well the issue is very simple to understand. When you load CTRLR as VST3 in a DAW and export a panel as a VST3 instance, the given VST3 will have "Ctrlr" for name and ignore the "panel name" infos. As a result the DAW see both plugins as duplicate and the exported VST3 is always ignored. The work around was to build a new VST3 with projucer/xcode with a different plugin name and plugin manufacturer to prevent this issue but it's not for most of Ctrlr users.

It worked with VST2 because the naming and identification from the host is different. It's DAW, System and Format dependent. For exemple, macOS VST2 instance identification by the host like Cubase is from the build Content/Infos.plist strings "CFBundleName". macOS AudioUnits DAW will identifies the plugin with the AudioProcessor:getName() class.

But for VST3 it's a totally different deal. Since Ctrlr has not really been updated officially for a while and VST3 format is not optimized but became mandatory by 2023 standards we really need to figure this naming problem out.

I dug down into this naming problem and found out that Cubase (at least on Mac) identifies VST3 plugins via the JucePlugin_Name and JucePlugin_Manufacturer Preprocessing globals taken from the Projucer interface while building the Ctrlr plugin :

As you can see on the picture, JucePlugin_Name is Ctrlr and JucePlugin_Manufacturer is Instigator.

When building a VST3 instance of CTRLR the wrapper just look for those infos and pass them to the host for identification while loading, that's it.

This is right here in JUCE/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp from line 3399 and below.

ctrlr/JUCE/modules/juce_audio_plugin_client/VST3/juce_VST3_Wrapper.cpp

Line 3399 in c1f67d2

//==============================================================================

The easiest way would just be to hack this file and replace JucePlugin_Name & JucePlugin_Manufacturer by other variables :

static const PClassInfo2 componentClass (JuceVST3Component::iid,
                                                 PClassInfo::kManyInstances,
                                                 kVstAudioEffectClass,
                                                 JucePlugin_Name, // needs to be replaced by JucePluginNameForHost
                                                 JucePlugin_Vst3ComponentFlags,
                                                 JucePlugin_Vst3Category,
                                                 JucePlugin_Manufacturer, // needs to be replaced by JucePluginManufacturerForHost
                                                 JucePlugin_VersionString,
                                                 kVstVersionString);

And grab those two identifiers from either the Info.plist in the exported panel VST3 instance :

	<key>CFBundleName</key>
	<string>Ctrlr</string> // this is updated by Ctrlr on export from the Panel name field

 	<key>NSHumanReadableCopyright</key>
	<string>instigator</string> // this is updated by Ctrlr on export from the Panel Author field

This is where my C++ skills are not good enough to write the required code snippet. It would work at least for macOS. 99% guaranteed. There's some code already available in CTRLR to Store/Read/Write the Info.plist for inspiration :) :

ctrlr/Source/Native/CtrlrMac.cpp

Line 125 in 8aa00d8

File plist = bundle.getChildFile("Contents/Info.plist");

A crossplatform solution would be to grab the same Panel name and panel author infos from the Panel XML ValueTree itself.

return (ctrlrPlayerInstanceTree.getProperty(Ids::name).toString())
and
return (ctrlrPlayerInstanceTree.getProperty(Ids::panelAuthorName).toString());

NOTE: Maybe VST3 Hosts also require the unique GUID of the VST3/Panel. The naming concept would be still the same anyway.

Is it something you would be able to do @bijlevel ?

Let me know ;)

Damien

[bijlevel]

Hi Damien,
All is well, thank you! For the time being I'm still busy with a very time consuming project, so no time (yet) to spend on Ctrlr issues, maybe from May on, but I can't promise anything. I'm also not an C++ expert, far from that, but maybe with each others (and everybody elses) help, we can find a solution. Once I dive into it I don't let go (most of the time... ;-))!

[damiensellier]

Thanks mate no worries, I'll take some time to dig into that this month so that we can have a working VST3 exporter ASAP. VST2 is now deprecated so we need the new format.

[Ted-juh]

Doesn't it get the name/ version name from the "JucePluginDefines.h file?

#ifndef JucePlugin_Name
#define JucePlugin_Name "Ctrlr"
#endif
#ifndef JucePlugin_Desc
#define JucePlugin_Desc "Ctrlr"
#endif
#ifndef JucePlugin_Manufacturer
#define JucePlugin_Manufacturer "Instigator"
#endif

In other words, if you can update those definitions, it will output a different name/ manufacturer or version number. Am I right? Or is this only on recompiling the whole Ctrlr project?

Edit 1: Or is this file generated from the things you fill in in the Projucer?
Edit 2: After some testing, yes, this file is autogenerated from the Projucer settings as stated at the top of the file.

[damiensellier]

@Ted-juh those are statics and only for the compilation unfortunately.

[dobo365]

Thx to all trying to find the workaround to this problem.
I'm manually modifying the VST2 IDs directly in hexa so they are identified as being different in the DAW's that are looking for that (Ableton, Studio One).
Did it on Windows since long but discovered only recently that I also need to do it for that MacOS VSTs.
Isn't the unique ID appearing in the same way in VST3 files as it is in VST2?
If someone would give me 2 exported VST3's (can be empty panels) with their original different names and ID from Ctrlr, I can try looking at changing directly in the hexa code.

[damiensellier]

Salut Dominique! Je vais t'exporter des VST3 mac demain tu pourras regarder ce qui change. C'est encore un moyen détourné ce serait mieux de travailler sur la racine du problème, mais c'est une bonne idée. Par contre ca marchera pas si tu exportes le VST3 en restricted instance puisqu'il encrypte les données du panel. Je te prépare ça ASAP ;) A bientôt et merci pour ton aide.

EDIT: I think It won't help because the different Panel IDs (panel name, author name, GUID) are not reached by the host while loading. The VST3 gets the plugin ID informations from the JUCE VST3 wrapper only, which passes the global JUCE build plugin ID informations (JucePlugin_Name, JucePlugin_Manufacturer etc). This is why it's different from VST2 and VST3. Name will stay as in the projucer 'Ctrlr' by 'Instigator' with the same GUID whatever the panel infos are. I'll export 2 VST3 instances anyway and their relative panel name and author if you want. Have a nice week!

[damiensellier]

If someone would give me 2 exported VST3's (can be empty panels) with their original different names and ID from Ctrlr, I can try looking at changing directly in the hexa code.

Here are the files:
VST3panelsForDoBo365.zip

NOTE : I use the following Ctrlr version for both Mac and Windows Panels, as Standalone App/exe, VST2, VST3 and AU without problem but the VST3 naming issue we are discussing in this thread.
Version = 5.6.1, Build date = Wed Jan 27 17:08:43 CET 2021, Branch = master, Juce = 6.0.7, libusb = 1.0.19, liblo = 0.28, lua = Lua 5.1.4, luabind = 0.9.0, boost = 1.57.0,

I don't use 5.3.198 anymore, it's useless.

[dobo365]

Is this version 5.6.1 newer or older than the 5.6.23? I suppose older but I know the numbers have been mixed up...
Could you point me to some link where I could download it (Standalone App/exe, VST2, VST3 and AU)?
I have a VST3 5.6.23 that I never tried but I wonder if you didn't made it ;-)

I look at the VST3 files now...

[damiensellier]

@dobo365 yes the version numbers are messed up it's the build from ctrlr 5.5.9, the commit I use is [f452347] probably the latest master before upgrading JUCE.
Not sure the builds are available in the folder, maybe you'll have to do it yourself. Let me know, I have the macOS at hand if you want. https://github.com/RomanKubiak/ctrlr/tree/7c578328a59fccd1da0968708c6afad7e63399a6

And also godlikeproductions make some available on his page in the right sidebar : https://godlike.com.au/index.php?id=361

Version = 5.6.23, Build date = czw, 8 kwi 2021, 14:37:02 CEST, Branch = master, Juce = 6.0.8, libusb = 1.0.19, liblo = 0.28, lua = Lua 5.1.4, luabind = 0.9.0, boost = 1.57.0,

VST3 for macOS:
Ctrlr 5.6.23.vst3.zip

Those version number are a big mess. I can't even figure out where this discrepancy comes from. But this VST3 is working nicely.

App for macOS:
Ctrlr 5.6.23 [f452347 with Pace Header].zip

[Godlike-Productions]

The way we did it was to compile a version for each plugin with the values changed in the source. We use those specific builds to export our instances. It's a pain, but so far the only way we've got it to work.

[synthmania67]

It just doesn't work, no matter what I do. I only get error messages.
I give up with CTRLR.
Thanks for the help though.

[bijlevel]

Why do you want to compile CTRLR? I can send (or upload here) you compiled versions of CTRLR standalone for Mac Intel or Silicon.

[synthmania67]

The reason is that I need an individual VST3 for my panels with the right name. That's why i wanted to compile a separate version of each.
It's driving me crazy.

[bijlevel]

Well it just happens I'm working on the same thing. But because it is some time ago I did this on my Intel iMac I have to check if everything stills works as expected. If all goes wel, then I can to make a different version of the ctrlr jucer file with the right plugin name for my VST3 and AU. I will let you know if this miracle happens ;-) and then I can build a CTRLR VST3 generator for your plugin with the desired name. But for that you have to send me some specific data. Which, I will let you know when I'm ready with my own plugins. This will take time, as always ;-).

BTW @damiensellier is a real expert on this thing, so if he wants to jump on this bandwagon sooner then me, it is of course fine by me!

[synthmania67]

Hi bijlevel, i would be very happy if you could help me with this. i have been trying to do this for almost a year now.
Since VST2 is no longer accepted by most DAWs, nobody can use my panels anymore.

[Ted-juh]

Here's a panel that produces a JucePluginDefines.h file that you can replace with the one in the JuceLibraryCode folder.

generateJucePluginDefines 1.0.zip

What does it do?
It lets you create a unique ID (or pluginID or FUID). (It takes the PluginName and translates it into Hex code). You can also set the amount of VST input/ output channels. Set the plugin manufacturer, plugin version number, and plugin description. Pretty basic but I think it's all you need for now to differentiate VST3 plugins.

How does it work?
Open the ctrlr.sln file and compile the Ctrlr SharedCode at least once. From then on you can easily replace the JucePluginDefines.h in the JuceLibraryCode folder and build a different Ctrlr_x64.vst3. Open it in your daw and open the panel to your liking and save it as a restricted instance vst3. It should show up next to other created VST3's because it has a different PluginID.

What you shouldn't do?
Open the Projucer and change settings, this will overwrite the JucePluginDefines.h file.

I know it isn't the way Damien intended. But for now, it's a way to easily produce a different PluginID for VST3s. You can make several JucePluginDefines.h files and just replace them without the need to compile the Ctrlr_SharedCode because you changed something in the Projucer settings (Needed to generate the hex code that the PluginID is made of.). It's more time-saving.

*edit, new file. Thnx Dnaldoog for checking the code.

[damiensellier]

I think those Ctrlr newer versions work fine from 5.6.23, but there's probably some incompatibility issues with your panels programmed on an older version. We are using JUCE library v6+
it's not your fault, the way some JUCE functions are implemented are a bit different for exemple the sendMessageNow() etc
Also on 5.3.... Juce was version 4. And they deprecated and changed things along the way.

You can check what they've changed between v4 and v6.0.8, maybe it will give you some hints about why it's crashing in certain actions/events

You can also try running your LUA scripts with error protection by embedding your functions into pcall() :
#385 (comment)

If I can help you can post a panel here and I'll take a look at what could be the culprit.

[synthmania67]

What else comes to mind:

A search function within the modulator list "visible columns" would be a nice thing.
Searching there is a pain...:-)

[damiensellier]

I just noticed something probably related to your disk access issue. When I try to export an instance on my mac mini mojave, everything is fine, but when I do the same thing with the same build on mojave, my macbook stalls.
There's something about the way ctrlr is trying to access the disk that stops at this very moment. It's either because Ctrlr is only working on the mac it's been built on (unsigned but whitelisted) or it's more about a different type of access rights on Mojave OS and above. I need to check that. I'll try to sign the app to see if it's ok on my other computers. I'm happy all versions work on Windows...

[bijlevel]

@damiensellier said >Please check in the mac APP bundle in Plugins/Ctrlr.appex<

This Ctrlr.appex appears in all my build folders of the various compiled CTRLR sources. I never gave it a thought, I don't even know what it does of what it means...

BTW I did check the file sizes on Godlike Productions website, but the only one having 79 Mb is a previous 5.6.23 debug version, which you don't need IMHO.

[synthmania67]

Which version for windows is the best?

[bijlevel]

It's all good I'm alive, just a cavity to clean up.

I updated the code on my branch, that should be alright this way. I forgot to push the files I talked about previously to the repository.

https://github.com/damiensellier/CtrlrX

Let me know if it's alright on your side.

@damiensellier Your version 5.6.28 does compile OK on my Intel and Silicon Mac. So thumbs up for your excellent work! Should we in one way another make the app's available? Jason (Godlike Productions) is willing to host app's on his site

[bijlevel]

See thread #599. He has written a kind of guide to compile CTRLR with VS 2022, but using VS2019 tool (?). I myself was planning to try and build CTRLR on Win 11 with VS 2022 (or if needed VS2019) on my VMWare Win 11 for Silicon Mac.

[synthmania67]

Hi, thanks for guiding me. I´ve read this. Unfortunately I had no luck producing a successful build . I got 55!! (mostly C3246) errors and 100 warnings. Ohe of the errors:
error C3246: "LFile": Von "juce::File" cannot be inherited as it has been declared as "final".
or same with
\CtrlrX-5.6.0\Source\Misc\boost\boost\type_traits\is_polymorphic.hpp | Line 51 |

???

[Ted-juh]

Did you run the "remove finals" script as said in Bylevel's manual?

[synthmania67]

Sorry, no. I don´t know exactly what you mean.

[synthmania67]

Ah, know I understand what he means with "final". So should do that :-)

[synthmania67]

This was not the solution. I have no clue what I am doing wrong.

To prevent from the "final" error I did exactly what Bylevel said. The only difference is the file "remove_finals_from_JUCE.sh" which was only existing in the "Sricpt" folder of the used build (Damien`s 5.6.29) with Juce 6.08.

Compiling under windows is apparently even more difficult than on my MAC :-)

BTW: If you´re using "CYGWIN" it is essential to leave a space between the prompt and the link you have dragged into the window. Otherwise the error message "no such file or directory" will appear.

[Ted-juh]

Those are the same errors I had with Damien's latest build. If you open CtrlrPanel.cpp and scroll to those lines it shows a few "property" that are red underlined.

I solved that error by deleting some spaces between the straight upward dashes and the word "property" and add the spaces again until the words "property" weren't erroring out anymore. Something to do with a backslash or space that is returning as a weird symbol through copying over code.

This error is solvable, so it seems. Can you tell what you did to remove those "final" errors? It might help others if they run into the same problem.

Don't worry about the German language. I'm from the Netherlands, living 20 km from the German border. Ich spreche ein bisschen Deutsch. 😉 Aber ich sehe keine Fehler in Deine Visual Studio.

[synthmania67]

Ok, my fault. I´m using 6.1.4. Thanks to both :-)
The only thing I´ve changed was using Juce 6.1.4 instead of 6.0.8.
Now I will go to sleep and give it a try tomorrow.

[synthmania67]

Good Morning :-)

Today I open the file" CtrlrPanel.cpp" with Sublime and I can see the wrong spaces in this block. Unfortunately these things happen with copy and paste 😉

[synthmania67]

[synthmania67]

Small update:
The creation of "Shared Code" was successful and finished after about 10 minutes. Joy on my side...
Now switched directly to VST3...
I've been standing here for an hour!!!

My Mac is totally overwhelmed :-)