ok not exactly.
more like:
lpc_common a;
a.lpc_data
etc...
and file loading
lpc_common:dataInit()
and, would the function definition not have to be in a .c file?
ok not exactly.
more like:
lpc_common a;
a.lpc_data
etc...
and file loading
lpc_common:dataInit()
and, would the function definition not have to be in a .c file?
ok i had a go at this. i tried to make two really simple objects, one with a param dial, one with an outlet. i then tried to send the value from the param of one object to the outlet of the other object by passing the value to a variable defined in a class in a header file.
but, i get always this error:
/Users/lokki/Documents/axoloti/build/xpatch.o: In function `PatchProcess(long*, long*)':
xpatch.cpp:(.text+0x110): undefined reference to `Fly::datafly'
collect2: error: ld returned 1 exit status
the contents of my common.h file are only:
class Fly{
public:
static uint32_t datafly;
};
i'll attach the two objects. if you @thetechnobear or someone else can point me in the right direction with this simple example, that would be great. i looked at: https://en.wikipedia.org/wiki/C%2B%2B_classes and thought i did it right...
thanks.
classreceive.axo (508 Bytes)
classsend.axo (524 Bytes)
your just declaring the static, you need to instantiate it as well
you header file should look like
#pragma once
class Fly{
public:
static uint32_t datafly;
};
uint32_t Fly::datafly=0;
note: normally this would not be done in the header file, but in the compilable module (C file) ... but thats not used in axo.
however, what I do, is still break up my C code into headers and C files, and then just include the C file in the header file.
this means that when axoloti supports compilable modules, you can easily move your code into proper modules, as its already split correctly.
for 'trivial examples' though not necessary as you'd probably never want to go to the effort of having a separate module.
just as a follow up, i did it with all the data loading functions and stuff as well, all in a class now, and if you load multiple instances, the data will only be loaded the first time, but reused by the other modul-instances. this is nice, small memory footprint. thanks heaps @thetechnobear, i really really dig your way of helping me out here, i learn a lot and i am having fun!
Hi All!
Coming late to this thread, but I'm just wondering if the above offers a solution to a problem I had when working on my LPC objects.
One of my objects requires a number of pre-defined multi-dimensional arrays. I'd like put them directly into SDRAM somehow, and ideally, also make them available to other objects. I don't want to load the data from a binary file on the SD card.
Is this possible using any of the methods outlined above? Sorry if this has been covered already. It's been a while since I worked on any Axoloti coding, so it's taking me a while to get back into the swing of things.
a|x
Thanks @lokki for answering in a pvt. I can roll the data into a binary file in the object directory, and load that automatically into SDRAM at patch init.
a|x
Yeah the point of this is the user doesnât know the data is held in a file, itâs automatic to them. (Like lmnts)
The only thing to becareful of is they have to use an sdcard, which theoretically is not a requirement , but in practice most users have.
Again, just to repeat (as important) this is designed for initializing /allocating data at startup , if you keep allocating/freeing you are likely to have issues.
Also remember a patch can only take a certain amount of time, otherwise initialisation will timeout.
(Canât remember off hand what that timeout is)
Also remember to check return value from the Malloc , the more object developers use this, the more likely users are to run out of sdram during initialisation... and if you donât log the failure, theyâll just start complaining of boards âcrashingâ
Hi @thetechnobear Are there any relatively simple examples of the use of C header files and C++ objects in external files in the factory library?
I've been avoiding C++, because I've always been a bit scared of OOP, but it's probably about time I gave it a try.
a|x
the push object... or the really simple one i sent you. (to answer a question i was not asked)
I can't seem to work out how to hard-code the path for the binary file to be loaded from (same directory as the .axo itself), the destination path on the SD Card, and the reference to the file when loading it.
I've tried adding this block to the XML definition of the object:
<file-depends>
<file-depend localFilename="lpc_tables.raw" targetPath="/shared/lpc/lpc_tables.raw"/>
</file-depends>
Then I tried this line, to attempt to open the file:
file_error = f_open(&bin_file, "/shared/lpc/lpc_tables.raw", FA_READ | FA_OPEN_EXISTING);
a|x
Solved that one (hadn't actually put the raw file at the specified location- d'oh!).
Is it OK for my object to save data into /shared, or is this reserved for factory objects like lmnts?
If not, how do I specify the file should be copied to a directory named after the patch?
a|x
the question is, what happens when the directory is not on the sdcard? does it autocreate? or can we except every user to have shared on their sdcard? (did the lpc folder in shared get created automatically or did you have to create it first?) might consider to move my data to shared as well in that case. (at least the coefficients, not sure about the word file and the onsets)
It automatically creates it. I don't know what happens if it's already there, but I presume it just adds the sub-directory and data file to the existing top-level directory.
a|x