X11 Bugfix's required before Update.

[billv]

Yeh guys, the bugs in the X11 2.0 Update are starting to pile up.
Starting to get to the un-acceptable stage...might have to do a quick bugfix update only...
A got a couple of whoppers, so i thought i'd start this thread and go through them one by one.
Note:
All test done in FL unless otherwise stated.

Bug no 1.
The Eq Mod.
HOW TO CREATE THE ERROR
1:activate every note in host step sequencer
2:run host, then turn the Eq on
RESULT
Usually within 2/3 seconds, soundcard locks up with continual sound, forcing host shutdown, soundcard
re-install.
(It's not the sound card, have seen this happen many times in FS, it's just dodgy programming.)
TESTING THE ERROR CREATION
1:activate just a few in host step sequencer, maybe get a few more seconds, still crashes.
2: Try all other Seqs in X11-No issues. So it's only when the Host is generating the notes.
ATTEMPTED FIX
Note the Eq still is running on windows ticker. So my first thought was the two timing systems,
Windows + Ruby, were clashing here somewhere.
So I ditched windows timer and put ruby ticker in, but I'm still seeing the same results.
MY OPTIONS
1:I could always bypass this whole issue by dis-abling the EQ when synth is used as VST Plug.
2: Ditch the Eq Mod. get a free matrix trigger back in compensation.
3: Fix the bloody thing

So any ideas here, bring it on......I got no idea..

[nix]

Do you want a 3-band eq that Bryntesson gave me to test?
I can't build one(biquad filter), but I think this one works.
Otherwise send me ur schematic and I can have a look at the green/blue conversion
Green should behave the same a if it were a stream hmm

[billv]

Otherwise send me ur schematic

Schematic is online. X11 2.0(Examples)
Sorry it's a big download. havn't had the time to compress issue into smaller FSM. Please forgive

[nix]

OK, I'll have a look in the next couple of hours man.
Fingers crossed I can help.
I've got Project X now, just having a first squiz.
You have the old default eq I see.
I know I was crashing it pretty good with lots of automation 3 years ago.

I don't mind the d/l size,
your server isn't pushing it that good though.
Don't worry about that at all mate.

Arghh- green and red GUI--ouch
I used to wind green stretch film onto red cores, man I just hate that combination--hehe!

[trogluddite]

You have the old default eq I see.

Green should behave the same a if it were a stream hmm

Aha - I think there may be a clue there...

For low CPU, the stock EQ calculates the bi-quad parameters in green IIRC.
Particularly if the schematic is highly loaded this can cause a very particular problem...

The co-efficient calculations take your Freq, and Reso and then outputs five values that then get used by the bi-quad to make the filtering.
It's important here that the five co-efficients are a "matching set" - all "singing from the same hymn book", so to speak.
But when green is highly loaded, there can sometimes not be enough CPU power to "instantly" work out all of the green triggers within the time of one sample (or even many samples )- 'green' has lesser CPU priority than the streams. So the results of the co-efficient maths 'pop-out; one at a time instead of all at once.
This can sometimes make the five co-efficients "out-of-step" with each other just for a short moment, especially if the value is moved quickly so that the "jump" is very large.
The mismatch between the co-efficients can then sometimes end up creating a very unstable filter curve - enough to put out-of-range values into the filter feedback loops, thus locking it up. This sounds very much like what is described when the bugs happens - a feedback loop "lock-up" that can't be recovered without re-starting.

Two things can help to get rid of this problem...
1) The stock EQ, I think, does not have de-zippers - so value jumps might be quite large. De-zippers would make the values change more slowly, so that any "mismatch" of co-efficients was smaller. This may not fix the problem entirely - but, if it does improve things, that will confirm the source of the problem.
2) Use an EQ that calculates the co-efficients in code/stream. This guarantees that all the co-efficient values change at exactly the same sample - even if the co-efficient part of the code is hopped to save CPU.

It's also worth just trying out a few different filter codes from the forums - some designs just do not like to be modulated very quickly, whereas others are very robust. The EQ probably wasn't designed with modulation in mind, so it could be that the designer traded stability for a better/different sound.

[billv]

Thanks for explanation trog. tried the de-zippers. Didn't work though.

Use an EQ that calculates the co-efficients in code/stream

Will do some searching and try that.
Cheers.

[billv]

Found another in SM Toolbox. There's de-zipper's already it in.
It lasted about 5 sec before lock up.
The big "hint" with my problem here, for me, is

So it's only when the Host is generating the notes.

Question:
When the host sends notes, are there any other "discreet" messages going
through in "red", that I don't know about??????????

Anyway, for reference, here's the EQ I just tried

Code: Select all

streamin in;
streamin freq;   // normalized frequency
streamin q;   // Q factor
streamin A;   // peak attenuation factor
streamout out;

float in1,in2,out1,out2;
float a0,a1,a2,b0,b1,b2;
float sin,cos,alpha,abs;
float q2,fh;

stage(0)
  {
  abs = 3.4e38|0.999999|0.1;
  }
 
stage(2)
  {
  hop(512)
    {
    fh  = 0.5*freq;
    sin = sin1(fh);
    cos = cos1(fh);
    q2  = q + q;
    alpha = sin/(A*2*q);
    a0  = A*q2/(A*q2 + sin);
    a1  = a0*-2*cos;
    a2  = (A*q2 - sin)/(A*q2 + sin);
    b0  = (A*q2 + A*A*sin)/(A*q2 + sin);
    b1  = a1;
    b2  = (A*q2 - A*A*sin)/(A*q2 + sin);
    }
   
  out = in*b0 + in1*b1 + in2*b2 - out1*a1 - out2*a2;
  out = ((out&abs) > 1e-11)&out;
  out2 = out1;
  out1 = out;
  in2 = in1;
  in1 = in;
  }

[trogluddite]

No hidden messages as such - but there is something else going on that might have a bearing.
MIDI and 'green' operate on different CPU threads - 'green' only does something when there is a trigger and otherwise in "asleep", whereas MIDI will need to be continuously look at the data stream to see if any new notes have arrived.
So somewhere in FS is a "communication channel" between those two threads that allows MIDI to "wake up" the green parts when there is an event to deal with.
There have been problems with that cross-thread communication in the past (e.g. MIDI being unable to start Timers) - I'm not aware of any specific problem that would affect your EQ automation, but it's possible that it has some bearing on your bugs.

One little bit of diagnosis that might be worth trying - connect a stream readout to the outputs of each filter section that can be seen in the exported VST. If the problem is due to a filter-loop lock-up, you'll most likely see "INF's" or "NAN's" coming out of one or more of the filter blocks.

[maria1019]

Do you want a 3-band eq that Bryntesson gave me to test?

[billv]

Do you want a 3-band eq that Bryntesson gave me to test?

Thanks
Sort of prefer the parametric, got some 3-band designs in toolbox.....hhmmm
but I think it may not be needed. Will get back to you on that. thanks for offering......

One little bit of diagnosis that might be worth trying

That's the deal on lock -up.

ScreenShot211.png (25.04 KiB) Viewed 21184 times

I tested the last version built in SM: X11 1.32 .
Eq Runs perfect in host mode Trog, like it always did.
Reminder: 1.32 to 2.0, was just a timing fix......... .