Noticed this again last night, I’m talking just using a few internal sounds, a drum break, an 808, a pad, and a stab in one sequenced loop. The loop tends to sound slightly different/ not identical every time round. Like the bass would land in a slightly different spot each time, or the break would sound like it’s too fast (meaning the sequence would have slowed down by a fraction for a moment).
I had noticed this before when multi-tracking into the PC and the odd hit would be pushed forward by around a 16th note. At that point figured there was a chance it was user error, however I don’t think it was. Yesterday definitely wasn’t, but I didn’t multi-track it to visually confirm what my ears were telling me.
Also to add to this, if you go into track settings while playing a pattern, and click on the bit where it gives you the sample information, like STEREO/MONO, it completely bugs out and judders all over the place.
For the stereo/mono item it looks like “expected” behavior to me. The frequency is calculated and it seems it impacts the machine sequencer response.
If it’s not a bug, a feature request to deactivate this feature when the sequencer is running for people doing live shows could be nice. To avoid pressing this item accidentally and prevent the s2400 from lagging during a performance.
I’m not doing live stuff but I’ll create this feature request to see what people say.
Yeah if it’s expected behaviour, that’s fine. And I guess for live purposes, as you say would probably be best to move it to the general settings or something then, but it does seem to make most sense where it is already I think. I don’t plan on using it live either tbf.
Curious if anyone else has noticed slight instabilities with the clock in general though, my friend that also has one seems to agree FWIW.
Just reading through the manual again, noticed all the samples stream off the SD card? Perhaps this is the cause for occasional lag instability? Would it be possible to implement an “import sample to ram” type feature?
Sample Size
There is no limit on the length of a sample that can be played from the SD card. The only size limits are on sampling time, and waveform editing.
From the previous discussions, IIRC, there’s a certain sample size threshold after which the sample will be played back from SD Card instead of RAM. My understanding of that paragraph is that, if the sample is played from the SD Card, any sample can be played as long as you have sample time left. I am not entirely sure about this, though.
It seems you have a few issues concerning your machine so why not trying another SD card?
At the release of the machine SD card was often designated as the culprit for what was going wrong.
Concerning RAM it’s a bit complex and I think Vlad or Mickey have the right answer.
The 64 mb RAM has an impact on sampling time, regular loops, waveform editor, the looper and I suppose other things. I guess the important factor is if your sample is more than 2mb or not when you run the sequencer.
Anyway, virtually you can run anything from the SD card but if you have a sample over 64 mb you cannot use the waveform editor and so on so in practice you can’t do much with a very long sample.
I’ve tried it with 3 SD cards and behaviour has been unanimous throughout. It’s something that would be quite easily missed too tbh, especially if your whole song is one shots. When I have noticed it is with sliced breaks where the slices cut each other off. Since it’ll be a perfect loop running, then suddenly you hear an extra transient before the slice gets cut off by the next, meaning the sequence slowed down a tiny bit to allow more of that slice to play. Hopefully that makes sense.
Hi, I’m new here and waiting to receive my S2400 so I can’t run any tests myself, but I just thought to suggest a simple way to test clock stability.
From memory - program in a pattern of sixteenth notes triggering a sample with the fastest attack time possible and a relatively quick decay (high hat, rim shot etc), set bpm to 120, record this pattern into your computer at 48khz (bit depth 16 or 24….pretty sure it makes no difference)……
Now the tricky bit, cut out a section chosen at random of 16 or 32 hits ie. a bar or 2, but make sure that the slice position of you beginning point looks exactly the same as the end cut, to do this you need a waveform editor that allows max zoom in down to sample resolution and max out the height of the display as well……next put in markers before each of your 16 hits and slice the file into 16 (or 32). Now if you look in the info for each slice the amount of samples in each one should be exactly the same. In reality most clocks are not sample accurate or the clock is accurate but something further up the chain of events is introducing variations in timing accuracy.
Nerdy shit I know but interesting to check out sequencing devices using this method. It came courtesy of the guy who ran Innerclock (now discountinued stable clocking gizmos).
Just to add that the method above does rely on your being as precise as possible with the slice points, but like I said if you have a decent waveform editor/display it is easy to do.
I tested a few bits of kit in the past using this method and the results were interesting! Oddly enough the tightest clock was an old PC running Logic 5 (PC version)! It was sample accurate.
MPC1000 = a bit sloppy
Korg DDD1 = sloppy
Analogue Solutions Europa = a random distribution of 2 identical sample counts!?
Apparently the MPC3000 is 100% accurate as is the MPC4000 and a few other hardware sequencers.
Many iOS devices measured sample accurate as well according to Innerclocks site.
Problem is this is too random, hence why I’m pointing at SD cards as the potential problem, if it does just stream the audio from SD.
I have noticed it when multi tracking about 3 min worth of tracks once, where the break had 2 or 3 hits where it started like roughly a 16th late (visual confirmation). Someone else has mentioned this problem elsewhere too.
And as for the more recent events that lead to me posting this, I can hear it’s doing it. If I can hear it, you don’t really need to go to sample level to see it’s out, if you know what I mean. It does it every once in a while, seeminly randomly, it will also judder around when navigating the machine occasionally, similarly to when you hit on track info in track settings but not quite as bad. It seems random, which all leads me to think that if it does stream audio off SD, it would most likely be the culprit, more so than the actual clock.
Hi, you are right. I wasn’t posting that test as a diagnostic for your problem…more just a general clock testing method.
The bug you have definitely seems like something happening higher up the chain than the base clock……we’ll we need to hope it isn’t base clock jitter at a 16th!!!
I really doubt it is clock at this point tbf, since it’s so random. Otherwise it would happen more consistently surely.
Obviously when originally posting this, I wasn’t aware of what else it could be causing it and needed a title, so not sure how accurate “clock stability” is at this point haha.
Guess we need someone to even confirm if samples do stream off the SD. I feel like they must do since I THINK you can still sample to the full spec when you have samples loaded already.
Samples are loaded to and held in RAM……but if I am wrong about that and all the samples are streaming from the SD in real time I’m asking for my money back.
Yeah I just loaded 8 stem tracks each about 4 min long, they all play, which can only mean they stream off SD. So maybe it’s worth having all samples under 2MB?
I don’t think you can sample a 64MB sample when you have loaded samples already.
I tested a similar usecase once: loaded a 63MB sample in A1, opened it up in the graphical editor, set the start and end to a range of 9 secs (little under 2MB), tried to save the range to A2… CRASH!
EDIT: In the latest firmware this problem does not exist anymore. So it must have been fixed, but not made it into the release notes.
So maybe you should test it out and see if there is more memory than 64MB.
