Occasionally when editing loop/slice points with the graphical waveform display open I am experiencing moderate delay when hit different pads with an associated delay in the waveform display.
It doesn’t seem to happen when the sample length is <8-9 seconds, but with ~12-20+ second samples (individual slices ~2-5s) it seems to happen a lot.
Once exiting the waveform display it doesn’t happen, so it seems to be actually associated with the waveform display editing mode.
Hi, I don’t think it’s a bug, rather you have to quit the waveform to play with your pads
As @TARO1001FEUY noted it’s not a bug. Longer samples aren’t stored in RAM. Drawing the waveform and loading the slice/sample takes a bit of time so there is some delay in wave edit mode with larger samples.
Thanks - yeah I guess “bug” isn’t the right word for it.
Anyone looked into whether this is related to brand/type of SD card or just the actual processor is a little underpowered.
Interestingly, if you record a sequence and go back to the waveform editor it has no issue displaying the waveform and jumping around the positions (presumably with a larger sample still being streamed from the SD) which would argue that this is fixable.
@st1 In the waveform editor:
If the machine is not in multi mode, pad presses switch between different samples. If a sample is larger than the 2MB buffer space allotted to each sample, then it has to be loaded into the full 64MB buffer. That is what takes time. How much time depends on the speed and sector disorganization level of the SD card.
If the machine is in multi mode, pad presses switch between slices. A large sample has already been fully loaded into the big buffer as soon as the waveform editor is displayed. So jumping between slices is fast because they are all in memory.
I understand what you are saying however, when editing the slice points of a sample in multi-mode with the waveform open shouldn’t it be loaded into the buffer at that point*? Or am I missing something?
*It is slow at this point. Others have reported this as well.
Yes, that is what I am saying. When switching slices in multi-mode, the sound is already loaded in the buffer, and the only delay would be the redrawing of the waveform.
I am not clear on when it is faster. Maybe a video would help at this point?
I will make a video when I have a chance - the response lag/delay happens with a sample assigned to a bank/pad while in multi-mode w/ the waveform open.
Others on the thread seem to understand what I am describing.
Closing the waveform display remedies the response lag/delay.
Caught a video with both the lag/delay, but even so much lag that it is affecting the sequencer playing a simple drum chop (sequencer is totally glitching out); the sample isn’t that large, and was sampled directly from vinyl → s2400.
Also on video, slice points (which are set and locked suddenly jump); I really hope these issues are figured out because it is actually affecting the enjoyability of the unit.
@Mickey - Forum upload is stating *.mp4 are not authorized.
do you have google drive?
i just use that beast system for this sort of stuff, upload to there - you get 15gig, you can then share the link - dead easy to do
Good idea
2 videos - poorly chopped drum sequence for demo purposes with pattern recorded.
Medium length sample recorded/assigned to bank B1. No pre-recorded pattern. Slice points assigned/set in multi-mode, and the slices points locked. Drum is on A5 or 6, tracks are not overlapping (regarding outputs)
1st video demonstrates the slice lag, so much so that it is affecting the drum sample sequence playback.
2nd video shows a locked slice point jumping while hit the pads (4th slot) - right towards the beginning (should have truncated the video). No pattern recorded for that track (that would bump to a previous recorded slice point).
I don’t necessarily expect an “answer” per se regarding these points, but I am curious if anyone from ISLA has any comment/feedback.
@st1 It’s difficult to make out what’s going on in the videos. It sounds like you’re reporting two potential things…
Regarding the delay when switching between waveform views, I think Mickey has answered this above. The drawing of longer samples’ waveforms can take a small amount of time, and yes, affect the playback. That is how it is.
Regarding jumping slice points. That is a known issue, and should be fixed in the next update 
Yeah, sorry, not the cleanest videos - but yes, two things going on (happened to catch the slice point jump while recording as well).
I posted the video in response to Mickey’s note stating that in multi-mode the sample should be loaded into the buffer and should not have a lag but the waveform re-draw can. Others noted above stating what you just did, that with the waveform open there is a lag (which as illustrated in the video affects others things - such as a playing sequence). I was just caught off guard by this issue, as most gear I have owned from circa '00 onwards has incorporated waveform display, but not had this type of lag; in turn assumed tasks were being processed separately/in parallel, but the way it affects the other playing sample(s) and throws of the timing of the sequencer looks like it is really drawing away a lot of resources. I wont draw any direct gear comparisons for fear of 
.
As for the slice points jumping - I thought locking the slice points was the fix for the original slice point jumping issue. This was a jumping locked slice point - but if that is a known recognized issue I guess I’ll be patient.
Is there a place/list that the new known bugs being addressed are posted to cut down on duplicate posts (like this one)?
I agree, it can be very annoying when the sequence Glitches out when opening the waveform view. I don’t mind a bit of loading time but the glitch of the sequence is not very nice. Could be really bad if you intentionally or unintentionally happen to open the waveform view in a live performance.
I suppose you already thought about it years ago but preventing the audio side of the sequencer from lagging or stuttering should be prioritary in this case of multiscling.
I wouldn’t mind if the waveform takes twice or triple time as much time to load as long of the audio plays fine. Audio lag is the worst situation for an audio sequencer as a user point of view.
I know it’s possible to switch to the mixer view to avoid this but the workflow then has different limitations and it is not very user friendly as well.
Or maybe in the worst case, imposing a constraint like it is not possible to display waveforms in multislices when the sequencer is running for the cases that create stuttering or lag.
If nothing can be done, hopefully a hardware fix is on the list for s2400mk2 
Yep - this is the train of thought I am on as well.
I can’t really comment on the method of multitasking being used with the processor/display, the overall capabilities of the processor etc (or the level of programming language being used), but I guess it is a little disappointing.
If there is interest I can retake the videos (hard to bang pads and hold the cell steady/in-focus) - although by listening, and watching the hang-up on the screen and stuttering of the beat, it is illustrating exactly what is happening = Delay/lag + sequencer glitching out, which I understand it is related to waveform display.
I am really not trying to be a pain in rear, but basic functionality items like this need to be worked out or the product is going to catch a lot of flak from a more general/broad user base. I have had decent success making good patterns, and want this to succeed, otherwise I wouldn’t be wasting my time posting.