I know, and we are on the same page.
But I’m hoping that if enough people get behind this idea that they (the Isla team) may take it on board and implement it……it’s not like it’s a crazy wishful thinking type of request! they are literally doing exactly this in Bank D when it’s in looper mode for the next update.
Here’s why I mention 12bit and mono here though. I just converted a 55.5MB WAV file (16Bit 44100)… and in 12Bit 26k mono it is now 8.92MB. That is a very big difference obviously
EDIT: think the program lied to me and og file was 24Bit, I think. Either way though, still a big difference, even if so.
So from what I can make out about their existing ‘rules’ about using the 64mb sample RAM -
2mb sections of RAM is probably for some reason a fixed thing.
Perhaps the next chunk up is the 16mb allocation per bank.
They are implementing the ability for users to allocate the 2mb chunks in a different configuration within bank D when it is in looper mode.
Perhaps the flexibility within bank D also shows that it is only possible to ‘share’ unused 2mb slots amongst tracks in the same bank?
Given that I do not know why there are these apparent restrictions being placed on the way RAM is accessed and allocated! I’m going to adjust my feature request to be -
Can we have the possibility of sharing the 2mb chunks around within individual banks? but of course if there isn’t some hard coded restriction on sharing 2mb slots across banks then the ability to do that would be EVEN BETTER!!!
Absolutely valid point……I’m just concerned about keeping this thread on the topic of those 2mb slots 
You know why? Because it really does look like a do-able request.
Your idea about the 12bit files is also a good point, but,.I’ve got zero clues about how and why the 12 bit engine converts from 16 bit so I can’t even make a picture in my tiny head about ways in which that might be done differently.
Just bumping this now in the hope that Mickey can give a brief explanation of the underlying structure governing the ram allocation and to see if this feature will be a future possibility?
The only feature that is limited by the 2MB buffer is looping. Is allowing looping on longer samples worth the effort that it would take to change the way memory is allocated? I think I know what @av500 would say, but I will leave it to him to comment.
So you are saying that to all intents and purposes we already have extended sample time in sample tracks due to being able to stream from the SD. And that the only feature we lack is looping those samples beyond the 2mb limit (time will depend on our chosen bit depth/sample rate)
But what I pointed out in the beginning of this thread is that for some applications eg. in timing critical playback of percussive sample loops longer than that 2mb limit, streaming is definitely not ideal, and no one will recommend it!
So IMO the ability to stream samples from the SD is just a nice extra feature tagged on to the basic sample playback functionality, but shouldn’t really be sold as ‘the solution’ to longer sample time playback.
Sample playback for timing critical content will remain for me strictly limited to the 2mb slot limit.
Streaming from the SD is for non-timing critical samples.
I hope you do not take my pointing out the flaw in the logic personally. And also want to say here that I am so far (a week) loving making music on my S2400. So thank you for your time, effort and attention to the details in the design/implementation of the OS.
But I am certain the point I make about ‘timing critical’ is absolutely pertinent to a stand-alone sampler sequencer. In fact it was partly upon hearing Brad in a video from some time ago state that the S2400 has ‘sample accurate’ timing that I have bought into the project, amongst other things.
No offense taken.
Great.
So I am guessing you get my point?
Timing critical is of the very essence when it comes to sequencing devices, we all want it or at the very least want to believe that our devices have the potential to be inhumanly tight rhythm machines!
It is not fun to have a niggling doubt that one’s hard programmed beats might be slipping in and out of ‘inhumanly tight’ time. LOL