STS bad MIDI timing...

[Grok]

all is in the title...Seen this with STS 5000 and Windows XP

There are little timing imprecisions with the execution of MIDI notes on...

Is there a way to get the STS more precise? Where do the issue come from?

[braincell]

It's impossible to say with such little information. You need to list everything about your computer. I uses the STS series with windows xp and can go as low as 4 mil delay which is practically zereo latency.

[Grok]

Well, the only thing I can say is that my XP is tweaked for audio...

I've seen this little timing imprecision when recording a drum sequence that was in two part: a VSTi and the STS 5000.

When I looked to the resultings waveforms, the VSTi one was in perfect synchro, and the STS one had inconstants imperfections, like if it was "humanized"...

So maybe the STS has an inbox automatic humanizer?

[kimgr]

The VSTi is an "audio-instrument", and is therefore sample accurate on playback. (But not when played "live".)
The STS-5000 is a (hardware) midi-instrument, and therefore does not have that advantage...
On a correctly installed/tuned OS, the STS has a latency of approx. 1-1.5 ms +-0.5 which is way better than any other hardware sampler...

Kim.

[Grok]

Thank you for your answer, Kimgr

[spacef]

Normally those midi timing issues on NOte ON have been solved. It was pretty bad on the first versions of the STS (irregularities in the Note On triggers, rather than latency) but with the latest versions it should be fine. At least that's what i see here, it is much better now (sts5000).

<font size=-1>[ This Message was edited by: spacef on 2003-02-11 06:25 ]</font>

[Grok]

Yes, it is usable anyway: it can be seen on the waveforms but I can't hear these "imprecisions"

[braincell]

If you can't hear it I would not refer to it as "bad midi timing"!

[Grok]

Ok, so just refer it as "bad timing"

or: "inconstant timing response on MIDI notes on"

[mr swim]

I'm pretty sure there are midi timing problems coming from the sequencer too. At least, I know that it used to be an ongoing problem for cubase users (including myself) - and still is an issue (at least for me !). This is particularly noticable for me when I'm using midi control data. If midi data changes on the beat, it is <i>sometimes</i> noticable just milliseconds afterwards. I always presumed that this was the same issue that caused midi clock irregularities on the bpm-timed delays etc in Scope. In other words, that it was an issue with the sequencer data and not the Pulsar environment . . . .

[at0m]

Hi,

The extra latency can be caused by some processing (ie. formants) being done on cpu. CPU means latency.

The wiggly timing can be improved by using non-emulated drivers or other than CW's software drivers. The latter means sending time critical MIDI via the hardware input to dsp.

Good luck!

[finfreluchette]

same problem for me in 2013 with Samplitude and Scope 5.1 32 bits

samplers timings are bad (like if it was "humanized", sometime it's audible)
but strangely, synth timings are perfect (Minimax, Profit 5 ...)

I don't use emulated ports and Bios is correctly set.
Any idea ?

[fra77x]

Midi timing and latency are unrelated. You can have huge or minimum latency and good or bad midi timing. Inaccuracies in midi are called midi jitter.

There is no bad "sts" midi timing and "perfect" synthesizers. You just don't listen to the jitter at the synth sounds but becomes evident at percusive sounds.

Most software sequencers offer mediocre midi timing. That does not applies only to scope, it applies to all hardware synths driven with these.

Solutions: Good midi interfaces. Hardware sequencers. MDS-8 or others scope modular sequencers. Audio driven sequencers.
Sampling and using vst samplers.

Regards

[finfreluchette]

I just found the solution

The problem was that I have an old Pulsar (version 1) in my computer with Pulsar II.
I removed the Pulsar 1.

Thank you anyway for the advices fra77x !!

[bimole]

Hi,

10 years later...

I'm fiddling with STS samplers and AKAI CD-ROM Sound Libraries .
My hardware is :
1 Pulsar II card, Scope V7, Win10 32bits, Z97 chipset (MSI Z97-G43), i5-4670 CPU, 8Gb RAM (3.4Gb usable), no "discrete" GPU).

All samplers are working pretty well after replacing KGPar2.sys, KGPar3.sys and TStretch.sys.
I have not replaced s3kimix.dsp nor s4kimix because it ask me for a v5.1 licence I don't have.
I have "missing files" message when I launch STS3000 & 4000 but after clicking OK, it works fine.

It's not the point...

I have also experienced these "inconstant timing response on MIDI notes on" only on STS3000 (other STS don't seem to have this issue).
When I plug the Scope midi keyboard directly to the STS3000 and playing fast repetitive notes on the PC keyboard, it only plays one note on two.
It also has issue with polyphony, whereas no problem with STS2000P, 4000, 5000.

Any idea?
OK you will probably tell me "just use other STS!" and you would be right but it's not satisfying !!!

Other STS-related problem ,the famous "No more driver memory for async vxd connections" message.
2 16-voice samplers can be loaded in scope but when I try to load an extra one, I get this error message.
As I read on the forum, it seems to be related to the allocated polyphony of loaded samplers (32 voices seem to be a brickwall).
Can it be solved ?


Cheers,
JB

Edit : I've just made the test with an arpegiator (Arpeg02). Everything is fine even at 250bpm with all samplers except STS3000 where notes are dropped as the tempo rises. Really weird

[valis]

STS Samplers and MIDI both use main system memory in scope to function, and those connections to the systems are shown as ASYNC in the DSP meter. The busier the host system, the more impact this will have on timing. It may not be obvious what constitutes “busy” from Scope’s perspective either.

System RAM is reserved for the samples as well, and onboard RAM allocation for Scope is limited.

[bimole]

Thanks you for the piece of advice.
It's true that, in the DSP-meter windows, async reaches quite high values with samplers whereas it remain low with synths or reverbs.
Should I understand that the DSP bargraph is not the only load indicator?
But what I dont clearly understand Is that some people may be limited for the number of sampler instances, other not (or less)... My setup is quite modern so I expected only DSP shortage.
What about you?
And any Idea regarding the dropped notes with sts3000?

[garyb]

when was STS made?
what was the standard?
what is it supposed to be?

[valis]

What Gary is saying is that the STS Samplers were made at a time when they were quite competitive with the software samplers.

Software samplers, when used entirely in a DAW context, not only have access to gigabytes of memory and disk (via disk streaming), but also have timing as accurate as the DAW supports with any other plugin. You do not get midi timing issues (though there are some process buffer concerns, and track automation may vary via DAW) because it never leaves the DAW's own process(es).

Scope on the other hand shares anything NOT on the DSP chips themselves with the host system. The GUI (the application Scope) communicates with the boards as a piece of software running on the host OS and CPU/Ram etc, and has to communicate with the boards via the PCI bus (for the PCI based systems) or via the PCIe bus (for Xite). The MIDI is *also* something that communicates with the host system, and while midi directly into Scope is actually rather tight it's still (to my understanding) processed via ASYNC.

Delays, samplers, and other devices that implement a buffer (use 'memory' to store data) that exceeds what is available on a SHARC chip also use the host system.

Your DAW uses the host system, as well as many background processes. Since the DAW tends to be the primary process (aside from the Windows kernel and modern Win GUI) using the system, if you have several background applications, some USB devices, several drives (especially fast SSDs which may implement additional host buffers) and Scope all running in tandem, these compete for the system bus.

What is the system bus? At its core it's the CPU and the modern ring architecture that allows cores to talk to each other, system RAM and peripherals. That 'peripherals' part is important, as the Scope system wants to be able to communicate with its boards on an equal footing (hence setting the Processor Resources within the Windows advanced settings to prefer "Background processes") rather than being lower priority. SImply adjusting this setting along with the power profile you're using will make a HUGE difference in Scope performance when your DAW is using more of the system than being idle (ie, 1 midi and 1 audio track don't stress a system much, but typical projects will compete with Scope).

And again, the STS Samplers are not currently supported as they cannot compete with native software in the same way. If Scope is primarily a sampling workstation for you, it is likely best to use it as you would an outboard sampler and tie it to a separate machine hosting your heavy DAW projects to keep MIDI tight.

[Bud Weiser]

... STS Samplers ...
If Scope is primarily a sampling workstation for you, it is likely best to use it as you would an outboard sampler and tie it to a separate machine hosting your heavy DAW projects to keep MIDI tight.

^^^^^
THIS !

My former DAW rackmount, 32Bit Win XP (or Win 7) Pro, Intel Pentium D 945 dual core, 4GB of RAM, SATA300 HDDs and a combo of Luna II (w/ extension card) and Pulsar II cards and SCOPE v5.1.
Works well for STS and VDAT.
I also use an old MusicQuest (Opcode) 8PortSE 8x8 MIDI interface w/ the unfortunately discontinued but ultra stable and tight "Earthvegaconnections" MIDI driver w/ this system and a Creamware A16 Ultra via Z-Link as well.
These MIDI interaces w/ that driver and connected to the parallel port are the best for 32Bit PC.

Yeah,- 6HU, relatively heavy and might sound insane,- but replaces a much bigger rack w/ several AKAI hardware samplers and 19" Syndrives.

I don´t like the sound of AKAI libraries in NI Kontakt and other virtual sample players/ samplers and STS sounds way more close to the AKAI hardware, offers more RAM and polyphony.

Unfortunately, it doesn´t work well for EMU libraries.
It sounds much too different from the original hardware (EMU E64 here).

But,- ll the above might be obsolete when there´s no need to use the old AKAI (and EMU) libraries at all,- so to each his own.



Bud