From what I understand about the new extended live looping times that will be available in the next update -
The extended times are possible via sharing of the 2mb per track limit, so if you only use 1 live loop you can times it’s length by 8 by ‘borrowing’ the sample memory limit from the other 7 tracks making it 16mb on that one track.
So, if that’s possible in the live looping bank how easy would that be to implement across the sampling tracks?
I can understand why it might be a good idea to portion up the sample RAM in even and equal chunks and I’m guessing it might be something to do with access time? but in effect it means there will often be decent portions of sample RAM sitting there unused, which since I started thinking about it seems a shame and kind of wasteful. Also the issue of sharing available RAM across different slots in other devices is pretty much universally based on how much RAM remains….so it really does beg the question why a pre-set memory allocation!?
I’m actually happy to work with 2mb per slot in practice but given that it is demonstrably do-able in the live looping bank it sure would be nice to be able spread those other unused 2mb portions around.
Lastly I do want to say that if that 2mb allocation is part of insuring an ultra tight sync up between a note event happening and the sample being triggered and that if any jiggling with the existing system might lead to less accurate timing then please - completely ignore this feature request!!!
for sample tracks its not totally necessary as long samples are streamed off the SD card. I have not in any practical scenario noticed a problem with that. That said being able to allocate the 64 mb differently for samples would be pretty cool.
It doesn’t seem likely to me that trigger time to actual playback of a sample can be as fast from an SD as it is from dedicated RAM, if it is the same that’s very impressive. But then why not run all the live loops from the SD and have basically unlimited loop length?
I’m guessing that you are running longer less timing critical samples from the SD.
I’m imagining scenarios like - I’ve done a bounce down of a number of drum tracks maybe with some live slider action in place of CC’s to some panning, filters etc and I end up with a 4 bar stereo loop, well I’m going to want to know that wherever I’m triggering that sample from it’s going to be as tight as any other shorter percussive sample ie. It sounds exactly as it did (timing wise) before bounce down.
If the RAM sharing is implementable for live loops I DO hope they consider doing it for the sample slots at some point in the future because it would open up a lot of further creative possibilities and it should be a thing as it is in almost every other sampler!
+1 with this.
As someone who does not use live loops I would be happy to have an option to deactivate live loops and allocate more RAM to standard tracks. It would be nice for loops.
I was thinking that the other day, too! I have memory fragmentation come to my mind but I am not even sure if that’s what’s happening. I cannot imagine how difficult it can be to change something like that to a more advanced allocation strategy given that it is baremetal development. (As in, I absolutely have no clue)
I would be very curious to know the reasoning for these design decisions to primarily understand how something like an S2400 functions as a system because, to a great extent, it is still a black box to me.
I have noticed that even if I just have a file open or in the project above 2MB it becomes unstable and starts dropping notes and being generally slack on the sync/timing/clock. I started a thread about it a while back titled something like “Clock stability” I believe. This is how I even found out about the 2MB limit, as far as I was concerned from the manual etc the limit was 64MB, and I do still think this should be made a bit clearer for anyone that has yet to buy the machine/ figure this part out etc.
I have just today got a larger and faster SD though, so will test if that helps at all soon, fingers crossed.
Either way I don’t mind the 2MB limit at all personally, limitations like that activate my brain creatively moreso than having everything and all the space in the world available. Having said that, fine with adding some added options for this, as long as it doesn’t bring more instability and timing/sync/clock issues, so I would probably want to suggest that that gets it’s own “mode” you switch to in the settings maybe? I dunno, but I do worry this may make it even less stable in that regard.
I am very curious as well about their design concept at these below the surface levels! Especially the RAM allocation protocols and the ‘why on earth!’ of it.
I knew there were idiosyncrasies about this machine before I bought into the S2400, but when the penny dropped on this thing about the RAM……well I don’t regret signing up but it’s kind of bugging me. I’d probably be happy with an explanation from one of the developers at this point but it would be even better if they could look into some user definable RAM allocation like in the looper bank.
I was thinking about the thread you posted on or started when I answered SAP at the beginning of this thread….so thanks for joining in. I’d put money on it that no one is running percussive loops off the SD card, streaming off of storage media has been considered a no no for a long time! And as far as I know even DAWs stream but buffer in RAM so what we are hearing when our DAWs play back/record is information sitting in RAM whilst the rest of the file streams in.
I wonder if it’s possible to implement the use of actual 12bit files too, since it currently saves 12 as 16bit from what I understand. Would drastically reduce sample size, and surely reduce stress on the processing no? My programming knowledge, especially of this box, is a firm 0 though lol.
Would also love the option to convert a sample to mono in the box… rather than just playing it in mono, since that halves sample size.
I just think features like this and also some basic editing stuff like being able to cut/paste audio within the editor would be even more useful, given the 2MB “limit”.
The thing is it just isn’t really mentioned as even being a potential issue anywhere, and I just now in fact, had a flick through one of the new manual vids, to see if maybe there was any easter eggs for the upcoming update, and it’s again presented as each track can play 64MB samples no problemo. Which, just isn’t the case from my experience, where even just having a file above 2MB in the project causes inconsistency, dropping notes etc. I noticed it even more so now I’ve been sequencing from the Amiga, and the 2400 has even worse issues keeping up if there’s a large file present.
Like I say though, maybe the faster SD will help with this. We will soon see I guess, fingers crossed.
Agreed on most points but the 12 bit thing I firmly defer to their greater knowledge and anyway 16 bit files are the midway point these days. 24 bit takes up significantly more space.
I think some people don’t realise that if you want to test timing issues down in the millisecond range you have to do it within pretty strict parameters, starting with samples where you can clearly hear the slop. So yeah do report back when you test with your new card but for the sake of clarity please do it with very tight rhythmic material.
I just mean, it’s a bit of a waste of space, if I sample/resample something to 12 bit and save it as 16 bit. Plus it would allow for longer files, since the limit is MB and not length. Files would be smaller, and surely if it’s having to essentially live convert it or whatever currently, that must be more taxing on the processing? Like I say though I have 0 clue if there’s any truth to that on the programming side, I’m not a programmer at all. So just a random guess.
I understand……but surely greater gains can be made by assigning unused 2mb slots to any given sample track! Which is why I started the request, because if they can do it in the looper bank D….then it would seem from the outside (so to speak) that this should be possible in the sampling banks A B and C.
