about GUIDs and their IIDs

This is really a message for Matt Jefferson and Nick Gill, but chime in if you noticed anything similar, or can point out my mistake.

Can we confirm on 6.6 we have a change to GUID value referred to by the constant

IID_IBMDSwitcherInput (and others, but lets focus on just one)

From:

{66F3D466-8C8C-4DB4-B313-8DD2EC665DBB}

To:

{875D3396-6C8A-4FD8-93B7-D1CB655F2AF2}

which changes the interface header back to something much more like the original 2.7.2 interface which was on:

{E7F28BBD-ADD2-41A2-AD7F-36B0D708C65C}

and the 2.8-6.5 GUID is now on constant

IID_IBMDSwitcherInput_v6_5_1

And hence although existing pre-compiled EXEs will continue working, this change breaks existing code, and users need to update their references to this IID_ (and a few others) to use the Get/Set (PropertyID, Value) access functions

----- OR ------

update their calls to use the very old & new "GetShortName(value)" / "SetShortName(value)".

I know this has been previous discussed regarding interface updates with respect to the Decklink SDK, and I'm not so crazy as to ask you to not re-use IID_ constants, but maybe you guys could give a - "Code breaking update alert" on the Developer sub-forum when you release a new API that changes the IIDs - You know when the update will break everyone's code, would it really hurt to alert us. I don't mind making the changes - but prefer to plan when to do it......

I'm not asking for detailed "Change Log" or anything big, just a "heads-up guys, we've changed the interface ID constants, beware recompiling your code on this update".

You do get that "people" (maybe only me), loose loads of hours trying to figure out "what the h3ll just happened" when you change these header definition "don't you????".

If it was a mistake and "a BMD interface leaking out" let us know before we change too much code. I know the SDK documentation is updated, and so it "should be" a real update that won't revert, but if your docs are auto-generated, and this is an interface you'd rather have hidden, and hence will remove it again later, it determines whether as developers we should:

(A) Change the IIDs we are using to pickup the interface
(B) Change all the calls as the old one will eventually get deleted.

[Nicholas Gill]

Hi John,

I can confirm that the SDK interfaces were revised in the Switchers 6.6 SDK release.

Within each new SDK release is included a ReadMe.rtf file which documents any included interface changes. The 6.6 release included the following changes [1].

As you have already identified, the revised SDK interfaces do not affect binary compatibility. If the application chooses to update to the new SDK, it does require changes to accommodate for the updated interfaces.

Please note, that there is no requirement to update to the latest version of the SDK - unless the application needs to use the new functionality available in an updated SDK.

i.e. If an application is written to use Switchers 6.5.1 SDK, it can continue to be built against the 6.5.1 SDK and be deployed on systems with 6.5.1+.

This is the primary approach used to maintain interface compatibility, and why SDKs are included as distinct packages.

In addition to maintaining binary compatibility with previous releases, each new SDK release maintains the previous SDK interfaces - if an older SDK package is no longer available, an application may continue to be built against the legacy interface included in a newer SDK package with minimal effort (by directly referring to the legacy SDK interface).

An application will generally be built against a particular version of the SDK interfaces. As new features are implemented, the application may need to move to newer SDK versions to gain access to newer SDK features - at that point the application would have to adapt to changes introduced between the SDK revisions.

To be specific - there is no requirement that an application adapt to the 6.6 SDK to be used with the ATEM Switchers 6.6 Update.

This is intended to ensure that API users can plan when to adapt to changes in the SDK interfaces.

Cheers,

-nick

[1] Changes in Blackmagic Switchers SDK 6.6

- Updated Interfaces

- IBMDSwitcherInput
This interface has been reworked to provide strongly-typed property-specific getters and setters, moving away from the generic ID-based access design. A new method was added to reset the short and long names to factory default; otherwise it is functionally equivalent to the previous design.

- IBMDSwitcherInputCallback
Adopt the Notify convention, in line with other callback interfaces.

- New Types

- BMDSwitcherInputEventType
Used in IBMDSwitcherInputCallback to specify the context of callback notification.

- Removed Types

- BMDSwitcherInputPropertyId
Not used by IBMDSwitcherInput and IBMDSwitcherInputCallback anymore.

Many thanks for the reply, and mega-thanks for pointing me at the fact the rtf file within the separate SDK is different from the one included in the main build, I have to admit because you need to supply contact details including serial numbers EVERY TIME to get hold of the separate SDK, I don't do that as often as I should. (I should set up a macro to do it once a week)

To be specific - there is no requirement that an application adapt to the 6.6 SDK to be used with the ATEM Switchers 6.6 Update.

Whereas I understand this, and it may be literally true, it's not quite as simple as that in reality.

The ATEM Firmware / Software is part of a huge bundle, that includes the SDK, so whereas it is available as a separate download, it's always there in ProgFiles\BMD\ATEM\DevSDK\, and lets be honest, that rtf file includes none of the text you mention it looks like this:



So that gives you one impression, but I'm sure you are correct about the SDK specific download. Might it be useful to include the same information in both readme.rtf files. copy-paste can be done with a simple Ctrl-C, Ctrl-V.

As I said, I really appreciate your reply, and you know I love a bit of passive aggressive. But why you want me to highlight this slightly weird approach, is beyond me?

Why send developers mixed messages, "Are there changes??, one readme says No, one says Yes", you must go on registration treasure hunt to find out - How exciting......

You know I raised this on behalf one of your forum members struggling to compile your examples, which by the way, don't link the version specific IDLs, they link to the BMDSwitcherAPI ones that are always the most up to date.

Thanks again for info.

John

[Nicholas Gill]

Hi John,

First I apologise if anything in the previous message came across as passive-aggressive. It is difficult to convey tone unambiguously in a written context. Providing the missing context explicitly, I'm trying only to be helpful and informative.

I actually wasn't aware that the main Switchers package also included the SDK - whenever I have needed to use the Switchers SDK I've used the separate SDK package.

This appears to be the core of the issue, the "Switchers 6.6 Update" which includes the SDK actually includes the Switchers 6.6.1 SDK, and is noting only the differences wrt. the previous 6.6 SDK, i.e. 6.6->6.6.1 introduced no changes.

I agree that this is confusing, as it is not clear that upgrading from a previous Switchers package will have introduced other changes (specifically in this case the changes introduced in the 6.6 SDK).

So this can be addressed, I've passed this observation onto the Product Manager for the ATEM team.

Cheers,

-nick

Thanks Nick, that makes sense.