Clock stability

Hi, yeah thanks for reminding me, I do remember reading that somewhere.

Don’t have mine yet, gotta wait until November!

To me that is a must have constraint I always apply. Else I get clicks and stutters and timing issues, since I use multi-slices on all tracks.

What is a must have constraint, sorry? Keeping all your samples under 2meg?

Yes, exactly that!

If that’s the case, it may be nice to have some form of “commit to memory” type function I mentioned, if such a thing is doable. Which would then mean you can sample to your hearts content, and when you’re ready, commit a sample to memory, so you’re not losing that space until you’re done sampling/ ready to do so (unless it’s under 2mb already anyway ofc). Does this make any sense? haha

It is not that hard to stay under 2MB.

Stereo samples < 10 secs.
Mono samples < 20 secs.

No biggie. It is even good for creativity, since it let’s you make choices early on. But that is just my 2c

1 Like

Highly depends, some of the work I need to do atm for example, requires the use of stems and acapellas. But I’m not really using this machine for the project, although I’d like to involve it a bit at least haha. Not every song has the same requirements.

FWIW I have made many full tunes on my 950 which is just under 60 sec at reasonable sample rates, as well as on the Amiga, hell, I’ve made a tune with 2 channels in Protracker on a broken Amiga. Doesn’t mean any tune is doable like that though.

I don’t mind quirks or limitations, I just need to know what they are and how they work/ what causes them, so I can avoid the issues, basically.

1 Like

Been noticing this again. So yesterday I had about 14 sequences, intro up to and including 1st “drop” basically. So obviously sounds build up throughout the sequences. I repeatedly noticed on some of the sequences the first notes of a couple sounds would start a 16th late. This would happen the first time they played (I’m pretty sure it only happened the first time they played after not playing for a bit anyway), one I noticed was a hi hat (a multi slice from a 4 bar loop), the other the break (multi-slice, 1 bar loop).

It’s really making me think it has issues playing stuff off the SD card consistently. My current SD is 100/mbs transfer rate (the silver SanDisk ones). I’m tempted to try and grab one with a 170mbs transfer rate (Kingston Canvas Go, the blue ones)… Anyone think that could help?

Mind that the max speed is a representation of reading large files. This gives you an idea of the performance of application that use mainly large files (like recording video of 4k or up.

Our use case (reading multiple small files) is totally different. The max speed do not tell you anything. The much more important parameter is the access time, the time between a request for reading a file and the time the reading starts taking place.

The best thing you can do is making sure that all samples are read from memory and the SD card is only loading and saving songs for persistant storage.

Yeah that’s what I thought.

Thing is the Octatrack can stream samples off CF card, which at best is around the same speed as an SD right? And I’ve never encountered this. So wonder if it actually is down to streaming off SD or not.

I’ve just checked, and all the samples currently used in the tune load in the waveform editor whilst the sequence is playing, which means they’re under 2mb correct? Is there another way to check file sizes? Must be being blind haha.

There is a few longer samples loaded, but I haven’t used them in a sequence yet.

1 Like

Ah spotted where to see file size, was indeed being blind haha

Right, so the largest files are 3X 2mb, one of which is used 2 unused currently, and 1 3mb one which is being used. However the tracks I have noticed the skipping on, are under 2mb.

Why not create some new stuff with stereo < 9.7s and mono < 19.4s and see what happens then? If the problem is gone, then my advice would be to do the same as me… use the limitation to your advantage. And if the sample has to be used for longer than that, split the file to multiple tracks.

Yeah will have a mess around in coming days.

Need to get this one finished one way or another though, and can’t really trim down anything, especially since there’s no basic cut/paste etc so can’t for example cut out silences between samples on multis etc. Starts and ends are already cut down obviously, also there’s a 9-10 bar pad for example which gets used in full. So yeah, kinda problematic on this one lol.

Are we actually certain samples under 2mb get loaded into the ram? The manual doesn’t seem super clear on this to me.

I don’t know if it can be related with your issue but last year I noticed a lag the first time something is played. (after loading basically)

I’m pretty sure it will be related, however in my case it isn’t just on first play, but seemingly random… Will continue keeping an eye on it anyhow

1 Like

Quite certain. Every time it has come up here, this was acknowledged. The manual says (p.32):
“the 64 MB sample RAM is divided into 32 play buffers”. So every pad has been assigned 2MB of RAM.
My experience with creating 50+ complex beats (meaning mainly multi slices), while keeping every pad < 2MB, causing NO problems… that is my proof. Before that I got into problems even if only one sample was streamed from SD. Later I upgraded my SD to a faster one, but still got cracks and slacks when using 3-4 samps > 2MB.
Do your own research and you will find out.

1 Like

Right, cool. Could have just said this to start with lol. :stuck_out_tongue:

So, the 2400 can’t handle samples above 2mb and be stable. And using any samples streaming off the SD = Writeoff. Understood, and good to know.

If I notice any further instability even with everything under 2mb I’ll update this then. Likewise, will update if this does completely solve it and I don’t notice any further instability in the coming days when trying.

Would be good if the manual informed you not to use samples above 2mb then tbh.

1 Like