Custom port type with Skanky SDK

danielmorena's picture

Dear forum, there's an example (project/snippet) here in the forum with a custom port type implemented using the Skanky SDK? I noticed the QCPort class, but i can't tell how much i need to implement in my subclass in order to make it function properly. Also, which will solve my problem as well, is the QCVirtualPort be used to pass on a C++ value? thanks!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

smokris's picture
Re: Custom port type with Skanky SDK

Subclassing QCObjectPort may be the right thing to do if you want to pass around a C++ object. In QCObjectPort.h, see the "Override" category --- this summarizes what you can override in your subclass.

The ParticleTools source includes several QCPort subclasses --- see /ports/*Port.mm. So does the TextureTools source --- see KinemeTexturePort.mm.

danielmorena's picture
Re: Custom port type with Skanky SDK

Excellent, i will dig there. The C++ object i want to expose is the cv::Mat, the architecture i'm designing will benefit from less conversion back and forth native quartz image format, an approach that kineme cvtools also use. Any additional advices? Thanks for your quick response!

gtoledo3's picture
Re: Custom port type with Skanky SDK

If you make a custom port, be aware that if someone makes an input splitter, it will cause QC to create an input splitter with a non-existent type, which will then cause the user's qtz file to create exceptions. If a user has done this ALOT, it will make a bunch of patches in the composition that will throw exceptions whenever anyone touches them, hovers over them, etc.

You can keep everything as a Virtual port, or possibly even as a an index of QC structure, and then when a user makes splitters, and it won't cause exceptions, BUT the user will also be able to connect "wrong" things, which will then cause exceptions. Subclassing QCObjectPort will always result in a solution that is subtly imperfect, so be aware of that aspect. Depending on the usage, you might want to just keep it a virtual port.

franz's picture
Re: Custom port type with Skanky SDK

mmm, can I create a virtual port using the standard API ? (I didn't find documentation relative to that subject).

gtoledo3's picture
Re: Custom port type with Skanky SDK

franz wrote:
mmm, can I create a virtual port using the standard API ? (I didn't find documentation relative to that subject).

I'm pretty sure virtual is still off limits to my memory (I'm pretty darn sure I've tried that a couple times); that's too bad, b/c it would solve a lot of use cases. You can pass some pretty wacky stuff as an index of a structure though... it might be worth trying that out in the standard api if there was an occasion for use, it may be possible to do.

danielmorena's picture
Re: Custom port type with Skanky SDK

Interesting! it's for a very specific personal usage, so i think that's will not be a problem, i will try that as well. Another thing, a little off topic, but pertinent: when digging in the Skanky SDK... i have found the header for the default QC patches like Billboard. It's possible to extend this classes? This will solve another problem of my project. I've been trying without success, the compiler raise an exception:

OBJC_METACLASS$_Test in Test.o ld: symbol(s) not found collect2: ld returned 1 exit status

like there's a library missing....