Simple way to get processor reference(pointer) from controller?

I have a custom view that needs to draw arbitrary stuff based on data (in a C based struct). This data is kept in the processor.

Following this thread I see that I can implement verifyView in my controller to gain access to the instance of my custom view component (manufactured via uidesc).

Now that I have the view instance, I need to give it the pointer to the C struct and struggling to find a sensible way to do this. The data exchange seems extraordinarily complex for such a simple task. Also the example here is a clue but it seems to have got a bit caried away with the specifics of the particular example data to the extent that it’s not really intelligible for a simpler case.

So is there a simple way to get a pointer to my AudioEffect from my EditController?

Many thanks in advance.

1 Like

There’s a reason why data exchange exists. All the bugs, crashes and race conditions you will get by accessing your realtime data from the UI thread will bite you hard at some point.
Really, take the advice and use data exchange for this.

1 Like

Thanks Arne. I understand thread safety very well.

Simple example - processor body has a lot of data that is required to create a visualisation. This data is derived from configuration, state (history), control (params) and inputs - where this state is crucial for visualisation. Drawing should occur on UI thread but copying all necessary data over data exchange is overkill and performance is poor. Alternatively, one can do off-screen drawing in processor thread and then send pixels across which again is a lot of data to pump, unnecessarily loads processor thread and likely limits fps.

Now in any other environment, the solution would be to use a mutex and share one copy of the data across threads. This has clear performance advantages and is completely appropriate (and perhaps more desirable) for real time processing.

But perhaps I am misunderstanding data exchange. On first look I see a non-standard, overly verbose and partial solution for a well understood and neatly solvable (and widely solved) problem. (Sorry for that: I am known to be a harsh critic :frowning: ) .

I’ll give it another go over the weekend, perhaps I can create a wrapper to (at least) simplify dx so it’s a bit more comfortable to use.

1 Like

You can take the advice from someone who has more than 20 years of experience in this field, or you can naively use a mutex in your real-time thread to have unpredictable running time of your audio processing and risk dropouts.
Just saying.

1 Like

Thanks Arne - will likely do that. Been coding professionally for 30+ yrs myself - mutexes and shared memory in RT applications would be an interesting conversation over a beer sometime.

1 Like

Ok so I am almost there with data exchange.
But since I’ve added dex, there seems to be a memory leak somewhere - report as below:

Detected memory leaks!
Dumping objects ->
C:\apps\VST_SDK\vst3sdk\base\source\timer.cpp(328) : {7677} normal block at 0x00000000102338B0, 32 bytes long.
 Data: <0               > 30 C8 CE A6 F9 7F 00 00 01 00 00 00 00 00 CD CD 
C:\apps\VST_SDK\vst3sdk\base\source\timer.cpp(328) : {2014} normal block at 0x000000000A4CF280, 32 bytes long.
 Data: <0               > 30 C8 CE A6 F9 7F 00 00 01 00 00 00 00 00 CD CD 
C:\apps\VST_SDK\vst3sdk\base\source\timer.cpp(328) : {1984} normal block at 0x000000000A4CECE0, 32 bytes long.
 Data: <0               > 30 C8 CE A6 F9 7F 00 00 01 00 00 00 00 00 CD CD 
C:\apps\VST_SDK\vst3sdk\base\source\timer.cpp(328) : {1954} normal block at 0x000000000A4CF220, 32 bytes long.
 Data: <0               > 30 C8 CE A6 F9 7F 00 00 01 00 00 00 00 00 CD CD 
Object dump complete.

Any suggestions on how to track this down?

This will be one of the bugfixes in our next release:

+++ b/public.sdk/source/vst/utility/dataexchange.cpp
@@ -101,7 +101,7 @@ struct MessageHandler : ITimerCallback
 			return false;
 		config = c;
 
-		timer = Timer::create (this, 1);
+		timer = owned (Timer::create (this, 1));
 		if (!timer)
 			return false;