When using table/alloc 16b I get the error: "region `CCMSRAM' overflowed by 16997 bytes"
I'm getting this even after ensuring everything is cleared from the board from previous sessions, and just nine objects in the patch. This happens if I choose 32768 as the size, but it's fine with 16384 or lower.
It's as if it can't handle the largest allocatable amount, and I can't imagine it's due to complexity cause there's barely anything to the patch anyway, I'd just started building it.
It is because you have loaded too many objects that uses CCMSRAM and therefore it is overflown.
In you particular case I am pretty confident that it is because you use the table/alloc 16b. Try the table/alloc 16b sdram instead. I think that might help. I am not 100% sure, but try it 
Thanks Jaffa, but I just did a test where literally, the only object in the patch was the table/alloc 16b object, absolutely nothing else whatsoever, but I still get an overflow error.
It just won't accept having the largest size allocated to it, even with the simplest, completely useless patch.
No it wont because the ccmsram(sram?) is a lot smaller than the sdram.
Sdram is larger and can therefor use larger tablesizes
Yes, but table/alloc 16b is the Non-SDRAM version of the object (SRAM).
Are you sure you're not thinking about the table/alloc 16b sdram object instead?
Do you get the same problem if you use what I'm using, even when it's the only object in the patch, and everything else has been cleared?
Read what I wrote again. I wrote that table/alloc 16b uses Sram, which is smaller, that is the one that you are using, which gives you errors.... If you want to load larger files you can not use that object.
You need to use the table/alloc 16b sdram..... As I also wrote in the first post.
No cause I dont use that object for larger files. It does not work with larger files. Sdram has 8megabyte. I am not sure how big sram is, but it is a lot smaller.
I think you are kind of making this harder than it is.
Just use the table/alloc 16b sdram and be a happy man, like everyone else
you are correct @axoman this is a bug (32b has the same issue)
the various table sizes should obviously only present whats available.
my guess (and its only that) is it probably did work on an early version of axoloti, but the memory layout changes over time, as johannes allows more memory for various things, and takes it away from others. so at some point it stopped working ... that or its was copy and pasted from somewhere else 
give sram is pretty precious we do advise using sdram for large tables (so the variant objects) even though its a bit slower.
Well getting smarter everyday here
@thetechnobear How large is the SRAM actually? I know sd-ram is 8 mgb.
Thanks
Well, I am a happy man, I was just pointing out a bug. And speaking of happy, I'd be positively euphoric if someone would show me how to play a simple table in reverse. In fact, if you show me, I'll forgive you for doubting my incredible noob talents
Thanks for the heads-up, Mark, and no worries, I wouldn't normally use SRAM anyway. I only noticed it cause I was playing around with various sample-related objects, seeing what's what etc.
its actually quite a bit more complicated than this, as its segmented, some of which the patch does not have access too currently. Johannes goal is to make as much of these resources available to the user (in a simple way) as axoloti develops... though each step is more complex/involved to achieve, easy pickings are already done
Im not sure whats available to do this, essentially its not hard, you just need to go backwards thru the table,
so its essentially the same as table/play but reduce pos each time rather than increase it. pitched is the same just frequency is the amount to dec by.
just be careful of two things:
off hand not sure if this is possible as a patch or not, or if someone has already done this in the community library.
Thanks Mark, and yeah, unfortunately the coding stuff is of no use to me (that's partly why I came to Axoloti) it has to be a patch for me to understand it.
It does sound as if it can be patched, I get the impression at least three people know how it's done, and it looks like Blindsmyth posted a video of such a thing in that "reversed audio" thread, but I can't make it out due to the resolution of the video. I'm hoping one of them will post a patch when they see my post, that would be great!
Does seem odd not to have a reverse toggle on the relevant table objects though, especially as reversing a sample is such a popular thing among sample users. But as you know, I feel the same way about the filters, I feel they should have bipolar gain by default. These are really the sorts of things that will constantly trip-up relative noobs like me, cause we expect building-blocks to do this stuff for us.
I think what goes on in our heads most times is stuff like:
On the one hand, the noobs have a point because Axoloti is an object-based environment, so it's fair to expect this to an extent. But on the other, as I read you point out before, the more object variants there are, the bigger the nightmare for maintaining them.
TO plsy the table in reverse, you need to use a saw lfo and then invert the signal. Basically:
Saw up lfo = forward
Saw down(inverted saw up) = reverse.
Both should be unipolar, since a table input goes from 0-64.
(This works best for the regular table. To use this tip for the table/play version, you should make the grain size very small, to able to hear it playing reverse properly).
Thanks jaffa, your're forgiven, still need help with it though, so I've quoted you in the other thread so we can keep it in the right place.
I'm getting this region `SRAM' overflowed by 1468 bytes error
this is concerning, it's happening often
I hope I doesn't mean that my patches are too big and complex.
If I convert subpatchs to objects is that going to use less RAM?
Can I use the SDCARD as RAM and run large complex patches from there?
big hmmm, the patches I'm getting this on are not anywhere near as complex as the patches I want to run.
Are you using any delays? Or tables? They can quickly use all the SRAM, which you dont have much of. Try using SDRAM versions. You have a lot more SDRAM than SRAM so this might be the place to start. OFr example tables:
table/alloc 16b
table/alloc 16b sdram
This will clear up some SRAM for other purposes.
You mean coding some "finished" objects? If so I would say yes you can save a some DSP. But how much is hard to tell cause we don't get any rappport from Axoloti on how much is actually used. But since I started coding objects instead of makign subpatch, I definately get more bang for the buck.
Yeah, well, I have sometimes same issue and often had to use 2-3 axolotis at the same time to get the processing power I needed. But there are things you can do as mentioned above .
Thanks Jaffa that is helpful, I'll try a few things and see how we go.
I think I will code my system up in C++ now I have the design worked out clearly in Axo
the visual sequential way of working with the Axo environment suits me and it has enabled me to get my design sorted out nicely.
I can implement it in C++ reasonable easily now and I'll worry about getting data out of it into MIDI once i get the object library coded up and tested, gonna take a month or so but it's been a long term project for me so a few more weeks is no big deal.
Just wish I didn't have to eat and sleep and do gis and stuff so I could focus 24/7 on it.