Expanders across Plugins?

Development
21

Thanks for the insight. What is it I ought to make static? My understanding is dynamic_cast isn’t the most performant operation so if there’s something I ought to make static I’d be interested in knowing. It’s limited to onExpanderChange so that ought to keep it from being called frequently.

22

sorry i didn’t mean static as in C++ static. I meant “static as in you never change your header declaration again”. So like if you have module A and B collaborating via dynamic cast to Foo* then Foo* is fixed

This is why COM ends up with interfaces like IDirectWriteFontFactory7 since the mutation is just a new interface always

1 Like
23

I thought the question was about getting pointers directly to two modules and trying to tickle their insides. I know the expander api is correct. Fwiw, I’m pretty sure I had expander modules available before 1.0 shipped. Looking back at the post I was replying to, think they were in fact discussing having one module directly talk to another.

24

Thanks everyone for your help. I’m finally getting around to this, and it works well!

There is one more thing thought I need to figure out how to split across plugins: global variables.

And for context on why I’m using global variables: In this plugin there is a control module that can be virtually connected to any number of other plugins. The connection process is similar to Midi mapping. On the control module you press a button to enter mapping state, and then every mappable module shows if its connected or not. I control if we are in this configuration state, thought a global variable.

My current thought is maybe I can subclass the Model struct to have the extra variables on it. But maybe there is a better way someone else can think of?

25

If the modules are all within the same plugin a standard easy global variable works fine.

26

The topic title, as well as the Patheros posts explicitly state he is trying to use expanders across different plugins.

2 Likes
27

the global source plugin has an interface which returns a pointer to the global and which your modules implement. the recipient module does a dynamic cast of the module and if it matches can call the function to get a pointer to the global. that’s basically what i’d do.

but also, you know, threads, globals, etc… there be monsters.

2 Likes
28

Hey, so @cosinekitty’s suggestion of sharing the same header file is working well on Windows. But it doesn’t seem to be working on Mac. The dynamic_cast from Module to the shared struct is not working. The header and cpp files for the shared structure are identical. Anyone have suggestions as to what might be causing this?

29

I was able to solve my own problem. For anyone else attempting this I’ll post what my two issues where

First I was using dynamic_cast instead of the c-type cast and field checking in the code that Don posted above. So I had…

struct MyModule : Module
{
};

void checkExpanders(){
  ...
  void *ptr = ...;
  MyModule *module = dynamic_cast<>(ptr);
  if (module)
  {
     
  }
  ...
}

but I needed

const uint32_t MYSIG = 0x50536574;   // ASCII "PSet"
struct MyModule : Module
{
    size_t sizeInBytes = sizeof(MyModule);
    uint32_t signature = MYSIG;
};

void checkExpanders(){
  ...
  void *ptr = ...;
  MyModule *module = (MyModule *)ptr;
  if (module->sizeInBytes == sizeof(MyModule) && module->signature == MYSIG)
  {
     
  }
  ...
}

Second I wanted to generalize this functionality across several modules so I had a shared struct that did not actually extend Module. So what I had was

struct Interface {...}
struct ModuleA : Interface, Module {...}
struct ModuleB : Interface, Module {...}

but what I needed was

struct Interface : Module {...}
struct ModuleA : Interface {...}
struct ModuleB : Interface {...}

Hopefully that helps anyone trying to do something similar :slight_smile:

5 Likes