STS bad MIDI timing...

Talk about the STS series of Creamware samplers.

Moderators: valis, garyb

Grok
Posts: 487
Joined: Sun May 20, 2001 4:00 pm
Location: Paris, France, toujours l'amour

Post by 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?
Toujours l'Amour!
User avatar
braincell
Posts: 5943
Joined: Thu Sep 13, 2001 4:00 pm
Location: Washington DC

Post by 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
Posts: 487
Joined: Sun May 20, 2001 4:00 pm
Location: Paris, France, toujours l'amour

Post by 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?
Toujours l'Amour!
kimgr
Posts: 621
Joined: Tue May 22, 2001 4:00 pm
Location: Easter Bronx, DK
Contact:

Post by 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
Posts: 487
Joined: Sun May 20, 2001 4:00 pm
Location: Paris, France, toujours l'amour

Post by Grok »

Thank you for your answer, Kimgr :smile:
Toujours l'Amour!
User avatar
spacef
Posts: 3234
Joined: Sun Jun 17, 2001 4:00 pm
Contact:

Post by 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
Posts: 487
Joined: Sun May 20, 2001 4:00 pm
Location: Paris, France, toujours l'amour

Post by Grok »

Yes, it is usable anyway: it can be seen on the waveforms but I can't hear these "imprecisions"
Toujours l'Amour!
User avatar
braincell
Posts: 5943
Joined: Thu Sep 13, 2001 4:00 pm
Location: Washington DC

Post by braincell »

If you can't hear it I would not refer to it as "bad midi timing"!
Grok
Posts: 487
Joined: Sun May 20, 2001 4:00 pm
Location: Paris, France, toujours l'amour

Post by Grok »

Ok, so just refer it as "bad timing"

or: "inconstant timing response on MIDI notes on"
Toujours l'Amour!
mr swim
Posts: 397
Joined: Wed Apr 10, 2002 4:00 pm
Location: Londres
Contact:

Post by 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 . . . .
User avatar
at0m
Posts: 4743
Joined: Sat Jun 30, 2001 4:00 pm
Location: Bubble Metropolis
Contact:

Post by 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!
more has been done with less
https://soundcloud.com/at0m-studio
finfreluchette
Posts: 18
Joined: Wed Oct 23, 2013 3:02 am

Re: STS bad MIDI timing...

Post by finfreluchette »

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

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
Posts: 889
Joined: Tue Apr 17, 2001 4:00 pm

Re: STS bad MIDI timing...

Post by 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
Posts: 18
Joined: Wed Oct 23, 2013 3:02 am

Re: STS bad MIDI timing...

Post by 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
Posts: 8
Joined: Wed Feb 21, 2024 7:49 am

Re: STS bad MIDI timing...

Post by bimole »

Hi,

10 years later...

I'm fiddling with STS samplers and AKAI CD-ROM Sound Libraries :D .
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 :(
User avatar
valis
Posts: 7306
Joined: Sun Sep 23, 2001 4:00 pm
Location: West Coast USA
Contact:

Re: STS bad MIDI timing...

Post by 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
Posts: 8
Joined: Wed Feb 21, 2024 7:49 am

Re: STS bad MIDI timing...

Post by 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?
User avatar
garyb
Moderator
Posts: 23248
Joined: Sun Apr 15, 2001 4:00 pm
Location: ghetto by the sea

Re: STS bad MIDI timing...

Post by garyb »

when was STS made?
what was the standard?
what is it supposed to be?
User avatar
valis
Posts: 7306
Joined: Sun Sep 23, 2001 4:00 pm
Location: West Coast USA
Contact:

Re: STS bad MIDI timing...

Post by 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.
User avatar
Bud Weiser
Posts: 2684
Joined: Tue Sep 14, 2010 5:29 am
Location: nowhere land

Re: STS bad MIDI timing...

Post by Bud Weiser »

valis wrote: Fri Mar 08, 2024 1:21 am ... 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.

:wink:

Bud
Post Reply