I’ve been generating some internal original samples as well as analog stereo ins from that little Waldorf Rocket desktop synth (very cool surprise, every time I use it i like it better). The problem seems really simple, but i’m worried it can’t be fixed b felt satisfied by support, the community OR worse still that an OB update WON"T fix, but there is of course, no way of knowing that without trying. SO I load up currently active project containing currently active pattern (RUNNING DIGITAKT OS 1.11 AND OB 2.0.12 WITH PRETTY GOOD FUNCTIONALITY SO FAR EXCEPT FOR THIS KIND OF STUFF). I sample as close to the amount with start and end points as I can in realtime, then when I’m done I fine tune the ends for a good loop (if that is what i’m after), click yes to confirm, then I’m brought to the naming screen, entering a quick name and hitting yes to confirm save and bam “load error” OVER AND OVER AGAIN. Even though I suspect that going beyond the 64MB is not the likely cause for every load error. It can’t be over the limit thought, there are 7 other voices none larger than 2MB.
The RAM doesn’t hold only the samples of the track sounds of the active pattern, but all the samples you have loaded into the sample slot list. So unload some (unused) stuff from the sample slot list and try again.
Nevertheless I wonder why it requires additional RAM when saving. Are saving and assigning to a track two separate steps on the Digitakt? Because the assigning to a track (or a new slot in the sample slot list) will require additional RAM, while the saving operation shouldn’t.
THANK YOU! that is bad news but a perfect explanation. And yup, assigning and saving are two different steps, at least in the case of RECORDED samples. Thanks again!
Sampling on the digitakt uses memory separate from the project ram and +drive which is always available even if the project ram or +drive is full. After sampling on the DT, one is asked to save the sample as well as assign it to a track. Saving the sample puts it on the +drive, assigning it to a track loads it into the project ram. So, It is possible to still sample if both project ram and +drive are full and then run into an error when attempting to save the sample.
I know that. But as I wrote: I wonder why saving would require additional RAM. The sample is there in the separate “record buffer” and all the device needs to do is write it to the +drive.
But will thinking about it again:
@daveypassage : are you trying to overwriting an already existing sample on the +drive which has a corresponding sound in the slot list? Because that would explain the “load error”, when the Digitakt tries to reload the now longer sample.
Saving the sample takes it from the buffer to the +drive. Loading the sample pulls the sample from the +drive to the project ram.
Thus, available project ram is needed to load the sample after recording. The “load error” is possibly a product of the project ram being full.
Op is not clear on whether they are trying to simply save the sample to the +drive or load it to the project after saving. As it is a “load error” and not one about saving, I assume it’s the latter. Additionally OP should check in the system menu how full the current project ram is and how full the plus drive is.
I’m just following the steps after recording a new sample, so I am not (at least knowingly) trying to overwrite any memory slots. I think it is a bit clearer to me now how the Digitakt memory is organized. At first I assumed that if i could record the amount while in the active pattern it would be possible to save or assign the amount in the same pattern, but now that I understand the sample buffer memory, that has been clarified. Silly assumption. When I look at +Drive I see that my recorded samples ARE saved they’re just unassigned/unassignable to the current pattern. So simply because the sample is too long to assign to the current “active” pattern doesn’t mean it is not saved, only unassigned. Thanks very much for all the help folks!
Hey there folks, really cool discussion. It feels really good to know that my ‘problem’ has lead to a conversation. I just think that’s dope, so thank you all. What I wanted to add, very briefly, and after quickly navigating (WITH HELP 
) my way to an albeit limited understanding of the memory organization of DT (which is sitting next to me unused for 2 DAYS and is calling to me). I think the whole issue basically rests with the post sampling procedure. Altogether, in my humble opinion, the sampling feature of DT needs some refining. Practically speaking it WORKS BEAUTIFULLY! However some of the GUI and data entry seem kind of faulty. At least to me. For one thing, it is confusing after recording and editing your sample as to whether it IS NECESSARY to assign your sample to a track iN ORDER TO SAVE IT. The other option to “press no to skip” sounds just so vague and uncertain! WHERE is my sample going if not to the pads in front of me. However, once I took the plunge, stuff started working far more smoothly. It is a bit more time consuming to skip and retrieve new samples from +drive, but it’s not terribly. I tend to agree that the problem with assigning and getting a load error is simply a question of remaining RAM in project memory. When I sample, skip assigning, retrieve the sample from +drive and add it to my project, things work great. OR, if I know I’ve got space in the project allotment (128), I WILL assign the sample to a track after recording. To be continued…