Anyway for a Juce plugin to detect/get track name/color from host DAW?

[PixelPacker]

Thanks!

Unfortunately either Reaper does not support Vst::ChannelContext::IInfoListener or my implementation is doing something wrong - either way, setChannelContextInfos is not called.

[yairadix]

Yes you’re right now checking again using @pixelpacker’s patch I indeed get the track name in Logic X.

[yairadix]

I made a commit based on @pixelpacker patch which is hopefully close to something @jules may accept into JUCE.

Also under WTFPL. Note that it is on a JUCE fork which stayed at JUCE 4 for the time being, but I don’t think the relevant code parts changed anyhow. (We’ll probably update to JUCE 5 when it makes sense for us, but at the moment it introduces bugs)

[yfede]

@pixelpacker

either Reaper does not support Vst::ChannelContext::IInfoListener or my implementation is doing something wrong

Since it also supports AU plug-ins, you may check with that format to see if at least the devs of REAPER are willing to share those informations with plug-ins. (Albeit I agree with you that even if that is implemented for AU, it says nothing about the implementation for VST3)

Other hosts that support VST3 out there are Studio One 3 or SONAR (Win only), which are paid but that may offer a trial period long enough for your debugging to take place (and/or NFR licenses for this purpose)

[raketa]

@pixelpacker

I don’t think that having the plugin format wrappers non-customizable is awkward - Actually, I’m more that happy not having to deal with them too often

Well. You already do. And you created an own repository and will keep track if JUCE gets an update and merge and commit those changes. I really don’t see how not being able to inherit the wrapper is an advantage?

@pixelpacker

regarding the including:
When the projucer writes the project files, you have the option to copy the modules or to leave them in place (which is what I usually opt for). If you don’t copy the modules cpp files will be created in JuceLibraryCode that include the files of the module itself. You can think of it like symlinks that work on all platforms.

But what does it solve?

[PixelPacker]

@raketa

@pixelpacker

I don’t think that having the plugin format wrappers non-customizable is awkward - Actually, I’m more that happy not having to deal with them too often

Well. You already do. And you created an own repository and will keep track if JUCE gets an update and merge and commit those changes. I really don’t see how not being able to inherit the wrapper is an advantage?

No, I don’t have a separate repository. I just made the changes and I’m hoping, that it will be included into mainline before by Hard Disk crashes It’s not an advantage, but it’s not that easy to do from an architectural perspective, because this is the glue code between the Plugin SDKs and the client code written in JUCE. If the Plugin wrappers would use virtual methods/inheritance then there would have to be some mechanism in JUCE to instantiate the user customised implementation for each Plugin API. (unless I’m missing something).

@pixelpacker

regarding the including:
When the projucer writes the project files, you have the option to copy the modules or to leave them in place (which is what I usually opt for). If you don’t copy the modules cpp files will be created in JuceLibraryCode that include the files of the module itself. You can think of it like symlinks that work on all platforms.

But what does it solve?

I’m including JUCE as a git submodule into my repository. So if I make changes to the JUCE code, it’s easy for me to make a patch, because I’m working on the original files and not on a copy of the module source files. Also if I pull the JUCE submodule, all the projects in the main repository will use the updated JUCE code, without me having to re-save the projects. JUCE is linked into my project so to speak.

[PixelPacker]

May I ask why you opted to use the “if” instead of the switch? Less changes?

[yairadix]

Yes, less changes as well trying to imitate the style of JUCE’s code. I’m really trying to keep my changes small and avoid style changes and cleanups because I have to do lots of merges with JUCE and it’s much easier this way. This also makes it easier for ROLI to see what changed and to integrate it into main JUCE if they choose.

[daniel]

@jules, @fabian, given that a working solution was made by fellow jucers, is it in the backlog to review/rewrite/merge that into the product?

I have a workflow for a plugin with proxy instances, where this functionality would be extremly valuable, as it would allow me to manage several plugins inside one GUI (being identified by their track names).

A short statement would be appreciated!

[jules]

Sure, it’s definitely something that’d be good for us to add. I think we may have missed this thread when it first appeared, but will try to look at it when we get chance.

[rip-off]

@jules @fabian
Hi, any updates on these. I’ve tried to use the patch with JUCE 4.2.3 and JUCE 5. None were successfull, the setChannelContextInfos() never gets called.
I’m trying to get track name of the track the VST3 Plugin is inserted on in Nuendo.

[fr810]

Hi @rip-off, we are looking at the best way to add this to JUCE and will have a look at the patches mentioned above.

[daniel]

@fabian

Hi @rip-off, we are looking at the best way to add this to JUCE and will have a look at the patches mentioned above.

May I bump this?
Not asking for a specific date, but is it on the radar or down to the bottom of the backlog or anything in between?

[fr810]

Yup, this feature is now on develop with commit b56e389. See the documentation here.

[reFX]

Thank you so much. This is great.

[daniel]

Great, thanks so much @fabian! I didn’t dare to hope to get it that soon. I will try it out the next few days.