Some thoughts on your PR :

1. We should not touch anything at runtime BUT check for it because that could create conflict.

Can this be an "uninstall script" that would NOT be at runtime but at "Installation" step. (Much easier to deal with (not in code!))

Basically adding a step : "to install distroAV, you must uninstall OBS-ndi first".

I can update the documentation as well.

2. I thought that we could access it and "migrate to distroAV" config.
   I am not sure how this is doable but as we control both OBS-ndi and distroAV code, we should be able to do something like this.

• Read distroAV config - check for OBS-ndi config > import as distroAV config > wipe out the OBS-ndi config (or have it with a "obs-ndi-config-imported-to-distroav flag so this does not get re processed)

Or the new installation process migrate it is OBS-ndi is detected (might actually be easier ahaha).

Overall : Having this as a step in installation could be a good "middle ground" that prevent us from doing too much in the code. But deal with all this at the Install process.
Then we only check distroAV config in code. Period ^^

Migrating Settings may not be much of a concern at all!

Both config.cpp and all of the other settings (ndi-source, ndi-filter, main-output, preview-output, etc) load settings keyed with prefix NDIPlugin.
We don't need to rename that key, and both DistroAV and OBS-NDI can read and write to that same key with no problem.

Hindsight says that key should have been be a less generic namespace than NDIPlugin, something more like org.distroav.obsndi (that obsndi is fine, since the plugin is DistroAV's plugin for OBS and NDI)... but that is water under the bridge.
But, @Palakis was a psychic genius when he came up with that prefix because since it isn't obs-ndi we don't have to rebrand our configs/settings!

The only complication we may have is just how to best deal with loading 2 plugins.
They do both seem to be co-existing side by side... OK.

Interestingly, only one NDI(tm) Source shows up in the Add Source popup:

I'll look into which plugin that actually pops up (probably depends on which plugin loaded first or last), but maybe we should change that to say DistroAV NDI(r) Source?

Probably a similar story for the other properties (filter, etc).

But, as shown above, both plugins' global settings show up separately but load and save the same values.

NOICE!

"DistroAV NDI source "plugin is too long.
We could do the release that "nullify" the OBS-ndi part. (So when installing distroAV, it override the OBS-ndi and actively disable it)

Not sure how that would be detected but can be a simple message that display in the log file : OBS-ndi is now DistroAV, the OBS-ndi file will soon be removed from the releases in favor of distroAV file.

DistroAV NDI® Source
is no longer than
macOS Screen Capture

I don't follow your comment...

We could do the release that "nullify" the OBS-ndi part. (So when installing distroAV, it override the OBS-ndi and actively disable it)

How to "nullify" the OBS-NDI part?
The only way I know to actively disable a plugin it is to just uninstall it, which the installer should do anyway when going from any version to the next.
The problem is that not everyone will use an installer, so we have to have a non-installer solution, so we might as well make that solution a prominent and usable one.

DistroAV will simply detect OBS-NDI and if present tell the user something along the lines of:

1. OBS-NDI is now DistroAV.
2. DistroAV has detected a previous version of OBS-NDI.
3. DistroAV and OBS-NDI are separate plugins that use the same settings and should not be used at the same time.
4. DistroAV requires OBS-NDI to be uninstalled before it can load.
5. DistroAV will keep and use all of their OBS-NDI settings even after uninstalling OBS-NDI.
6. DistroAV will unload

Not sure how that would be detected but can be a simple message that display in the log file : OBS-ndi is now DistroAV, the OBS-ndi file will soon be removed from the releases in favor of distroAV file.

What does the OBS-ndi file will soon be removed from the releases mean?

Belay that!

I spoke a little prematurely after first pass of playing a little bit with the OBS UI when both plugins were loaded.

After playing with this a bit more, loading the DistroAV Settings and making and applying a change (Main Output on/off, name, etc), those changes do NOT show up in the OBS-NDI Settings, and vice versa.

I need to do a little more testing on this...

...confirmed things seem OK with settings.

The problem was simply that the OutputSettings::showEvent(...) was not calling Config::Load().

Will be fixed in my next push.

Some feedback on "avoiding conflict with OBS-NDI obsolete file" from my research :

• Installer versions : We should remove the old files there.
• Non-Installer version : Adding the step in the Wiki on how to manually remove (most of it are already there :D)

Anyway we need the check + error message if distroAV detect obs-ndi.

Some feedback on "avoiding conflict with OBS-NDI obsolete file" from my research :

• Installer versions : We should remove the old files there.
• Non-Installer version : Adding the step in the Wiki on how to manually remove (most of it are already there :D)

Anyway we need the check + error message if distroAV detect obs-ndi.

For our wiki, we could also reference OBS' wiki:
https://obsproject.com/kb/plugins-guide

CCing @Palakis on this one.

One last issue on this "Part 1 of 2" PR (basic rename/rebrand; no NDI6; NDI6 is "Part 2 of 2"):
https://github.com/DistroAV/DistroAV/blob/6.0_distroav_rebrand_and_ndi6/buildspec.json#L46-L50

    "platformConfig": {
        "macos": {
            "bundleId": "fr.palakis.obs-ndi"
        }
    },

This shows up on a Mac at:
~/Library/Application Support/obs-studio/plugins/obs-ndi.plugin/Contents/Info.plist

...
<key>CFBundleIdentifier</key>
<string>fr.palakis.obs-ndi</string>
...

To be obvious: The schema is {company domain}.{app name}

Two topics...

Topic 1: What name to use?

I want to rename this to something like one of the following:

1. org.distroav.distroav
   This one is obvious, but kindof limits us to only ever releasing an app/plugin that works with only OBS and NDI.
   Not that I think I will ever have the time to, but it would be nice if we did not immediately limit ourself and started off with a naming scheme that makes if possible to have apps/plugins that work with more than just OBS or NDI.
2. org.distroav.distroav.obs-ndi
   This makes it easier to fantasize about other hypothetical combos such as a vmix-srt (vMix already has NDI built in, which kills me why OBS thinks they need to stay away from officially supporting NDI).
   The problem with this name is that it sticks with the taboo OBS-NDI that we are trying to get away from.
   But the fact is, how else would you call something that mashes up foo and bar other than foo-bar?
   Maybe...
3. org.distroav.distroav.ndi4obs
   Implies the display name "DistroAV: NDI for OBS", as if "DistroAV" is the app and "NDI for OBS" is a variant.
4. org.distroav.distroavndi4obs
   This name drops the . to imply a more mashed up name of "DistroAV NDI for OBS", as if that is just the whole name of the app.
   It is subtly different from Incompatible licenses #4.

It is just a package name that no one will ever really see, but to someone techy digging under the covers it could be important to disambiguate things.

And my fantasy of ever having more than one distroav variant is admittedly very ridiculous.

Still, a good flexible package name is an important thing to have.

I prefer # 4 or # 1.

I predict we will choose the simpler # 1.

So: What name to use?

Topic 2: Does renaming this break anything?

I am not sure how changing will affect either:

1. Signing with the Apple Developer account.
   (Speaking of which, I should create a DistroAV Apple Developer account for next year)
   Is there any hard-code that the Apple Developer account is only set up to sign fr.palakis.obs-ndi and absolutely will not sign org.distroav.distroav and we have to set something else up?
2. Installing org.distroav.distroav when fr.palakis.obs-ndi is already installed.
   Will the Mac installer know these are the same app and how to handle the package rename?

Can Apple Developer signing or package installing handle package renames?

I pushed org.distroav.distroav just to get something on the board to discuss.
We can discuss this here or on Discord and change this any time up until we release 6.0.0.

I am going to go ahead and merge this PR to branch 6.0.0_actual.
6.0.0_actual will be collection of all individually reviewed PRs that will be merged to master when everything is ready.