I haven’t seen any easy method to retrieve it, but I’m wondering if some weird workaround could be hypothesized.
Have you had a look at the Presonus VST3 Extensions?
I don’t know about the project name, but it is definitely possible to obtain the bus name (even the bus colour), at least for DAWs that support it.
On the other hand, i wouldn’t really consider this an easy method of doing so
Track colour and name is already available directly through the AudioProcessor::TrackProperties.
But I haven’t seen that for the project name. I haven’t checked the extra API though.
Actually I think that is the best answer lol, I just glanced over it, but it looks like it provides two global variables that would be perfect.
const Steinberg::FIDString kDocumentName = "documentName"
const Steinberg::FIDString kDocumentID = "documentID"
I downloaded the files and it look like its just a couple header files? If that’s all I gotta add I would say it actually is an easy method of doing so lol
Those look like constants that have those strings in them and can’t ever have any other text in them. I am quite sure those are not going to help you in this case.
You might be right, but what would be the purposes for the global variables listed in 2.8 if they are just constant default names?
They are constant names. They are used as identifiers when you call some API function. But I doubt in juce those functions are exposed. To have the API expandable that function is called using a string identifier.
I searched the JUCE source code, kDocumentName is not found. But maybe I just missed it.
You will need to use an additional API, and accessing that is not a walk in the park, but doable. Some advances were made recently.
Ah I think I misunderstood the usage of the extension. And you’re probably right, for what I’m looking to achieve I think that would be a lofty task.
On another note, I should say, the project name in particular isn’t important, more so I’m trying to uniquely Identify the project from within the plugin and basically determine if the plugin has ever been opened in this project before. Maybe that makes the task simpler lol.
Edit: And I should clarify, just checking for other instances already existing in the project would be insufficient. If the plugin was at any point opened and then deleted, the ‘hasExistedFlag’ will still be true.
For hosts that run the plugin in process you could simply add a static counter, kind of a reference count of how many instances of your plugin are currently loaded:
class MyProcessor : public juce::AudioProcessor
MyProcessor() : /* ... */
static int currentInstances = 0;
static int overallInstances = 0;
just an idea
The Presonus extensions are working on the lower level VST/VST3 interface level which JUCE abstracts away from you. We previously integrated them by modifying the JUCE code. In the meantime, JUCE added VST3ClientExtensions to make it possible to integrate such third party extensions without modifying the JUCE codebase. Still, you need to be quite familiar with how the VST3 API works and have a basic understanding of the COM interface it uses in order to integrate it, which is not really straightforward if you are new to that.
Yes, it possible, it certainly not easy , possible
Would simply asking the user for the project name in the UI and storing this on disk work?
The project name can change at anytime so I’m afraid that, even if you had access to it, that would not be a reliable way of knowing if your plugin was previously loaded in the session.
The static counter workaround described by @daniel seems to be the way to go. Although as stated it’ll work only for hosts running plugins in-process.
I’m curious so I thought I’d ask: what is your end goal here? Why do you need to know these things? What could you possibly gain by knowing fhe project name or if your plugin had been loaded before or not?
Thank you for the class suggestion I’ll check that out. You are correct I’m not super familiar with the VST3 API, however by looking at how JUCE obtains the track colour and track name, I’m guessing the implementation would be similar but just using the properties the Extension API provides.
@dimbouche You raise a valid point as well. Also this might be a dumb question but what do you and Daniel mean by running plugins in-process? Do most hosts run plugins in process or is it a select few?
@reFX Truthfully it’s a really out there idea, but I think it’s pretty unique so I don’t want to quite say lol
Sometimes, DAWs (hosts) can run your plugin in a separate process as the host’s one. This allows to prevent the host from crashing when your plugin crashes.
I know that Reaper offers that option, and also the latest Logic I think, but maybe others could tell you more precisely which hosts do that.
In case you really want to integrate the VST3 extension (and I cannot tell you if it will even solve your problem), maybe this topic where I asked for help with using the Extension interface, along with the juce example code mentioned there might help you Need help understanding VST3 extensions - #5 by reuk