Radek

Hi.
I have an SB Live! card and kx drivers in Windows XP. While playing on a midi keyboard I've noticed that some notes (key presses) are skipped. It occures when the sustain pedal is active and too many keys are pressed. With the original SB drivers it never happened. The problem appears also while playing some midi files. Does anyone know how to remedy this issue? I do not want to get back to the original SB drivers because they cause problems with large soundfont files.
Thanks for any answer.
Radek

Lex Nahumury

The maximum hardware polyphony (num of hardware voices) is always 64 mono voices,
no matter what driver you use.
This includes simultanious wave/pcm and synth playback.
So you simply reached max poly which hapens easily using sustain pedal.

Use kX Analyzer to monitor your voice allocation.

/LeMury

Radek

[color=#000000]Yes, I thought of that. But is there any way to set higher priorities to the newest voices on the list? Instead of skipping the newest note better to purge the oldest (or maybe the most silent). I'm asking because, as I've said, with the original SB Live! drivers I never experienced the problem of losing any notes.[/color]
[color=#000000]Anyway, thanks for your interest.[/color]
[color=#000000]Radek[/color]

Lex Nahumury

[color=black]

Quote:

But is there any way to set higher priorities to the newest voices on the list

[/color]
[color=black]I don't know exactly what kinda note-stealing algoritme Eugene uses in the SF engine,[/color]
[color=black]but afaik kX does use 'steal oldest/most silent' algoritme.[/color]

[color=black]/LeMury[/color]

[color=#000000]ps;[/color]
[color=#000000]

Quote:

[color=#000000]with the original SB Live! drivers I never experienced the problem of losing any notes.[/color]

It may use different algo, however, note dropping also *has to* and *does* occure with CL drivers as well.
[/color]

Radek

[color=#000000]Then this must not be the case of the algorithm used. I'm pretty sure that the driver simply ignores some key presses when I've pressed too many and the sustain pedal had been active. The same happens, however, while playing midi files. I have to edit and cut the length of some notes so that others can be heard. Maybe the problem lies in the configuration of the drivers or somewhere else beyond the kx drivers?[/color]

Lex Nahumury

[color=black]Then my best guess is; it has to be kX's note-stealing algoritme.[/color]
[color=black](Eugene??)[/color]
[color=black][/color]
[color=black]/LeMury[/color]

bennetng

Creative drivers are buggy too. People who instrested can go to my homepage and check it yourself

http://www.geocities.co.jp/Hollywood/9807/driver.html


the soundfont being used is AnotherGS v2.0, can be downloaded from here

http://bennetng.kc-studio.com/AnotherGS/AnotherGS.html

wmjordan

I guess that I have discussed about this problem with LeMury before.

We all have a feeling that the KX's algorithm does not seem as good as the Creative one when handling "too many" MIDI notes at the same time.

Eugene Gavrilov

kX stealing algorithm is quite complex -- it analyzes several voice parameters, including 'pedal', 'volume', 'voice type' etc..

[for each voice]
first we check if voice is stopped (CPF register)
then we check if voice is looping silence (zero-looping sf voice)
then we check voice's current volume (CVCF)
if voice stage is 'releasing' and volume is <0x200 we steal this voice
otherwise we add 0x1000 [for voices that are NOT being released] to voice's volume and add it to the list of voices to be processed later
[probably, this constant, '0x1000', needs to be double-checked!]

--
if we still cannot find appropriate voices, we process the list of voices:
(note that in this case we should stop/release the whole instrument's note, not just one voice. thus, if we have multi-voice sample, it will terminate synchroneously)
if we find the same note already playing, we remove it from the list if it's volume is not maximum (thus we do not get the same situation when subsequent notes steal voices in 'sustained' state etc..)
then we find note with minimal volume (that is, min among max )
we also check if the particular voice occupies more or less audio memory (in order to solve 32Mb issue) -- this is a flag that is triggered whenever synth engine detects 32Mb limit approaching.

===
of course, this algorithm might be improved

/E

Radek

[color=#000000]Many thanks for such a comprehensive answer. I think maybe I have an idea of how to improve this algorithm. First, in my opinion, the newly pressed key or the newly played note must always have priority over all other played notes regardless of its and their volumes (or maybe almost regardless - the driver still could ignore the note if its volume was way too low compared to all other notes). If the note is audible for a human listener (i.e. it wouldn't be drowned out by all other notes) it must not be dropped. If the driver ignores any key-presses on a keyboard it always stands out. My second suggestion is that if I've played let's say 5 C-notes at maximum volume and then I play 1 G-note at half the maximum volume the G-note would be more distinguishing then any of the C-notes. This means that any of the several appearances of the same note in the same octave is much less important than another newly pressed note even if the latter is relatively silent and all the others are at max. volume.[/color]

Samir

Maybe simple FIFO is best for this purpose?!?

__________________
MU3NKA 3A HAPO6!

Eugene Gavrilov

how about pseudo-code / algorithm?

E.

droc2003

If you think about the way real instruments work, you can only have one instance of the same note happening at a time, except that on some instruments, like the piano, resonance from a previously struck note might persist after re-hitting the same note. The best algorithm to accomplish that sound is probably something like this:

Is the same note already active among the oldest 6 or 8 notes played? If yes, then steal that note. If no, then steal the oldest note.

However, on single note instruments, like woodwinds, hangover resonances don't happen. Then, you would always want to steal the same note if it were already active, or the oldest note if not.

It would be nice if the kxDriver had some way to support this on a per soundfont basis, since that info cannot be stored in the soundfont itself. You could allow the user to decide how many notes into the end of the keystroke buffer to look, zero would mean always steal the same note first, 6 would mean only steal the same note if it is one of the last 6 played.

Radek

[color=#000000]Right, that could work. I too think that stealing the oldest of the same notes is far better than ignoring the newly played note. Because older notes quiet down newer notes are more often louder. That brings, however, another question. What to do if the newest note is more quiet than all the other occurrences of this note? Even if it’s hardly audible I wouldn't ignore it. In my opinion the best possible choice would be the following algorithm:[/color]

[color=#000000] [/color]

[color=#000000]1) if there are any other occurrences of the newly played note and any of them is more quiet than the newest steal the most quiet of the same notes[/color]

[color=#000000] [/color]

[color=#000000]2) if there are two or more occurrences of the newly played note but all of them are louder steal the most quiet of the previous occurrences (even if it’s louder than the newest note)[/color]

[color=#000000] [/color]

[color=#000000]3) if there is only one another occurrence of the newly played note but it is louder or if the newly played note doesn’t have any other occurrences (it’s unique) look for other triplets or pairs and steal the most quiet note of them; and if none are found then do the ordinary fifo algorithm (i.e. steal the oldest of all played notes).[/color]

[color=#000000] [/color]

[color=#000000]For some reason the search of notes could be limited to the last six notes on list (or the number specified by the user), like droc2003 suggested, but I don’t think it’s necessary. Or maybe it is, I don’t know.[/color]

[color=#000000] [/color]

[color=#000000]Of course some of the obvious actions in the original algorithm must be added as well (check if voice is stopped, etc.)[/color]

[color=#000000] [/color]

[color=#000000]What is pseudo-code, anyway?[/color]

Game3DFreak

[color=#000000]http://www.webopedia.com/TERM/P/pseudocode.html

[/color]

droc2003

This is why I suggested that the driver keep track of the currently active notes and their age and allow the user to decide if they want to have the driver:

A. Only steal the oldest note - You would want this when note dropout is not a problem.

B. Steal the same note, but only if it is among the oldest 6 or whatever notes in the buffer - You would want this for stereo piano patches to reduce apparent note dropout.

C. Always steal the same note if it is active - You would probably want this for single-note instruments like woodwinds (along with reducing their available polyphony to say 2 voices).

There is no perfect algorithm for note stealing, that's why flexibility would be nice.

goku420

I have only come across the problem like this, and it was with playing back a random midi track all together. I have a SB Live Platinum, and the KX drivers give me an option of 2 KX Synths to use, just like the creative drivers. I can fix the problem and get the track to play by using the 2nd KX synth for that track. I have definitely experienced the same problem with the original creative drivers that it doesn't play a midi track until you stop and try again, but I never found a work around for the problem with the creative drivers and probably didn't try the second synth. Anyways, I hope I've been a bit of help.

48N6E2

Excuse me for the ignorance. Is there way to change the algorithm of voice stealing through DANE or it should be done through edit/recompile of kX source? Or there is the third way. It would be enough to me to be able to switch between the curent alhorithm and the algorithm which just kick the oldest one.

Lex Nahumury

No, there is no way to change this other than through driver source code which is not open.

/LeMury