No, I got that bit, and created an object using plain C to dynamically allocate and load from a file to SDRAM.
Downside is that the object will (I assume) load the data multiple times to SDRAM, in a polyphonic sub-patch.
I can fix that using a singleton, as you advised @lokki to do.
Ah, that's a good explanation, thank you!
Ah, I'd love to see an example of what you mean, here.
What I want to do, I think, is to ensure that data copied to SDRAM by Object A is accessible by Object B, even if Object B is inside a sub-patch, and Object A is outside it.
If the sub-patch is polyphonic, I want all 'virtual' instances of the Object B to be able to access the data Object A has placed in SDRAM.
If Object A is also inside the poly sub-patch, I don't want the data to be copied to SDRAM multiple times.
As I understand it, this is where the singleton/factory class come in, because the singleton instance is effectively created in the global scope, and can therefore be access by any object, anywhere in a patch.
What I can't get my head around is if it's possible to allow Object B to access the pointer pointing to the SDRAM data copied by Object A in the same way that eg a factory delay object accesses data from a table object- by using the name of the other object in an objRef attribute.
If this isn't possible, then I'll give up on the idea of a separate Loader object, and just roll the Loader into the Reader. If possible though, I'd like to be consistent with the standard way of doing things.
Do you mean the objects will be created in SRAM, rather than SDRAM? That's OK, I think, as long as my class instances can still allocate SDRAM, and load data to it.