Custom File Loader and Structs

#1

This is related to @lokki question about loading arrays, but coming at it from a slightly different direction, so I thought it worth making a new thread.

I'm working on a custom file-loader object, that I'd like to operate in the same way as the Factory 'table/alloc/16b sdram load' object- ie you select a file, then the contents of that file is copied to SDRAM, and becomes available to other objects in the patch by setting an attribute to the name of the first object.

However, I don't want my file-loader just to load simple arrays into SDRAM. I want to define a struct in the loader (let's called it 'ROMHeader'), and to be able to access the SDRAM data in other objects by means of a pointer of type ROMHeader.

Is this possible?

a|x

#2

Oh, and the length of the file to be loaded is not known in advance.

#3

yes, as I said in the other thread, it’s just data , you can cast it to whatever you want.

The only issue you may encounter is byte alignment and struct packing - but I’d give it a go first , as it may not be an issue for you - so you can avoid this topic :wink:

#4

Hi @thetechnobear thanks for the quick reply.

Is the fact that the size of the file to be copied to SDRAM isn’t known in advance a problem, though?

The alloc 16b sdram object has at attribute for the number of bytes to be allocated.

#5

NO, assuming you follow the advice I gave in the other thread about how to get filesize and dynamically allocate the memory.

#6

Ah, ok. but @lokki’s scenario was slightly different. He wanted to load data into an object for use exclusively by that same object.l, and wanted to ensure that multiple instances of the object shared the same data.

That’s not really what I’m trying to do.

I want other objects to be able to access the data, in the same way they would if it was at ‘alloc’, or table object.

#7

No, part 2 of his question was about accessing from other objects.

#8

I will read through the thread again. I didn't pick up that point when I just scanned through the thread a while ago.

a|x

#9

Hmm.. I still don't think what you suggest will work for me.

I'm embarrassingly vague on OOP terminology, but I understand you're proposing a singleton pattern, whereby only a single instance of data-loader class is, or can be created.

Doesn't that inherently preclude the use of more than one instance of the class (ie more than one of my Loader objects, loading different files)?

That's exactly what @lokki wanted, but it's not really what I'm after.

I want something that works (to the user) in exactly the same way as a 'table/alloc' module and eg a 'table read', ie the user references the data in the 'loader' object by entering the name of the 'loader' in a text attribute of the 'reader' object.

I'd also need the Loader object to be 'poly-safe', by which I understand that if used polyphonically, it will not load the same data into SDRAM multiple times.

In the past, I was able to modify the factory 'table/alloc 16bt sdram' object to load my file into an 8-bit array in SDRAM, but this only worked because the size of the file to be loaded was known in advance, and could be set in a const.

#10

Hit that one already, in fact. I found that rearranging the order of variables in the struct solved the problem, but it had me scratching my head for a while.

#11

I managed to upload the data as uint8_t, then cast the pointer to the struct type I'd defined, and all is good.

Having said that, I was reading on a forum that casting an int pointer to a struct pointer is potentially a Very Bad thing to do (or at least, bad practice).

It seems to work but should I be aware of any potential pitfalls?

a|x

#12

just the normal problems with static casting things ... you basically stop the compiler from doing any syntax checks, so if you give it bad data it'll crash and burn.
so yeah, its generally to be avoided...
that's why we generally use void pointers for 'type changing', to kind of remind us to take care :wink:

#13

Makes sense. But, if I've made checks all along the way that the memory has been allocated, that file has been copied etc., and the format of the file is known, I should be OK, I guess.

I see. I will look into those, thanks for the tip.

a|x