yes!
I got it!
-add this code at the end of the k-rate code:
outlet_playing=g_MidiMessage && g_Msec < g_MidiMessage->time;-and add a boolean output called "playing"
this will go high as long as the song plays and off when the song has ended.
Then use a logic inverter and a timed pulse (timers) to trigger the next load.
Ah!
Simultaneous posting!
Ok, should I add this on the file itself with an editor or on the object definiition window in axoloti ?
Cheers.
ps. don't embed the file, just open it, edit it and save it. If you embed it, it cannot find the header files anymore..
you can also just edit it using the windows text editor, but changing it in the object definition window is easier and faster, but again, don't embed the module 
Ok,
I am unsure about what "embed" means in this context.
Should I remove the other outlet you already had there ? <bool32 name="end"/>
Also, at the end of the k-rate code, you have a for loop, with all the cases... where, in relation to this loop, should I place the code above? after the loop, outside of it ?
Thanks again
oh, the module just crashed overhere after looping 4 midi files a couple of times (at a very fast rate)..
It seems it's overflowing the sdram, so there's probably a code needed to remove the old midi data from the table to prevent this. It's probably just adding tables to tables to tables etc..
yes, you can remove that one, but you'll also need to remove the parts where it's mentioned in the code.
The last case of the switch can be removed (the one with the EOT)
and also somewhere above the switch it says:
outlet_end=0;
you'll have to remove that one too
Hello @SirSickSik, I've encountered the SDRAM overflow you mentioned, even without the "done playing" code.
Any idea where to start trying to remove that problem ?
For now, even an automatic 'reset' of the patch would be an acceptable workaround, if that fixes the SDRAM overflow, as this patch is going to be running for hours in an installation. (I'll share the whole project in the forum as soon as I can).
Thank you !
there should be a way to remove these from the sdram I think, but I don't know the code for that. I would like to though, so if anyone mentions it somewhere, please let me know.
But you could indeed try to re-init the patch.
For that you might try to just save an extra patch that only has a patch-change in it.
So that after your files have ended playing, it will switch over to that other patch, which will order it to switch back to the midi patch.
Don't know if it will work correctly though, you just have to try it out..
I'm just thinking that I might be able to do the memory allocation in the way the normal delaylines and tables are done. Not sure though, but this might fix the problem.. trying to recode it now
I found out the problem lies in the "TinyMidiLoader" code, which is part of the header file.
Seems this one allocates to sdram and just adds each newly loaded midi file to the table without removing the old one.
So to fix this, I should edit the header file, so it removes the old file before going on or uses a pre-defined table which you can pre-initialise in the local and init sections, giving it a fixed allowed buffersize, IF I can find out where the mistake lies at all..
tried out lots of things, but don't seem to be able to free the memory and reset the allocation pointer..
Hello, thank you for trying.
i believe that is a midi library. Perhaps there is a github page or similar, for issues.
I'll take a look
Thank you
the problem is that it is allocating memory by itself using "malloc", this creates a new memory with each assignment.
I looked into the code and even though there are structures for "realloc" (that would overwrite the same buffer) it seems the code actually still just uses the malloc instead of the realloc. But I still haven't been able to find out where this happens..
why not add a free() before the malloc() of the next file?
https://www.tutorialspoint.com/how-do-malloc-and-free-work-in-c-cplusplus
tried it on several different things in the module, but couldn't get it to work and on some things even crashed the axoloti.
It's some table that being created inside the TinyMidiLoader code.
But instead of altering the code in there and use the free(), I think it might be more useful if we could assign a table that the code may use and declare it ourself at local&init code.
also, in the tinymidiloader code, there are several places where it uses free(), so I think it's bit weird that it doesn't free up the allocated memory..
Apologies for not being able to add anything useful here, I am more of a client server type of guy, can't program in C
Will keep an eye for anything I can do.
Thank you