DSP Robotics Support

RJHollins wrote:Is this problem only within FS ? The exported .EXE and .VST work ?

As far as we can tell so far, that's correct. The bits that lock up are all primitives that only have a GUI when you're in the workspace. Stuff that is "user programmed", routed through an MGUI primitive, doesn't seem to be affected at all.

Until we know more from Malc, it's probably best not to use this design just yet - the lock-up of float/int boxes etc. makes it very frustrating to try and get any work done on the schematic!

trogluddite wrote:it's probably best not to use this design just yet

Unless your a sucker for weird bugs
I'm still using it, i think it's great that you've captured this bug inside Trog...
it's like a "bonus" really , better for us all in the long run....
And i think deep inside malc's heart, having users discover bugs is exactly what
he would want....cause he gets a better FS too...
And the knob is still great...still trying too work it out...
having some probs with bitmaps though, and
de-triggering not working exactly at high speed changes...

can't find fsm with bug...or dodgy selector.. must have deleted...
will post to malc if it turns up..

Did manage to get a green gui fix happening on the other knob, but really
struggling at the next stage:to de-trigger it....again at high speed..good fun though

de-triggering not working exactly at high speed changes...

Hi Billv ... trying to follow you on this. What is 'de-triggering' ?

thx

Getting rid of "false triggers".

Ahh, OK ... the false triggers.

I'm looking at the example code you posted to see both the issue and the approaches to deal with this.

From some of the topic discussions and examples posted on 'being mindful of triggers', I saw the same things you posted in your 1st example.

I don't have 'THE' solution, but in my use, I have all knobs/sliders, etc, working in a 0-1 range, and use the 'Scaling' module to make any range changes. Insert between is the 'Changed' primitive. Definitely helped to cut down the extraneous triggers.

I see what you mean about the 'speed' giving variations in the number of triggers. In fact, the 'reset to Default' value gives only a single trigger no matter where the knob was previously. For my schematic, this is not an issue ... in fact, I think it is the best result. [I should note that most of my knobs are 'Stepped'].

Another factor is that I'm using a modified SM knob as my core module in FS, as it had been customized for how I needed it to function. Since it is based in 'Green', I wonder if the green timing is having an affect on the posted triggers ?? [just speculating].

I'm sure you're working on something heavy ... again Hope a solution can be crafted.

RJHollins wrote: Hope a solution can be crafted

The solution in theory is easy....I'm just not going about the right way as usual

RJHollins wrote:working on something heavy

Perfect statement....
My project has become too heavy for my cpu...
Looks like the X11 development is over....
Its always run better as VST and Standalone than in FS...
but at the moment, I've hit that point where it's just crap in FS...
not consistant....not right.....so too annoying to continue working on.
So I'm looking at finishing this update...then putting the X11 'on ice'....
Fortunatly, it's a good update ...so I might get away with it...
Mind blowing how much more "sense" it makes with preset system installed...
Should be released this week.....
Looking forward to ending it so I can start messing around with other ideas......

billv wrote:Getting rid of "false triggers".

Getting the "exactly 100 triggers" would be very tricky - it's not a problem with the trigger system at, it's because of the way that the OS deals with the mouse. The mouse driver will only report the position to FS (via Windoze) at a set rate.

As an example with easy, made up numbers, let's say that...
- Mouse sensitivity: 1px = output changes by 1.
- Windows reports the mouse position to FS: 20 messages per second (fixed by the mouse driver)
- Knob movement: You go the full 0-100 in exactly one second.
In this case, there are 20 new mouse positions reported by Windows over the 1 sec of movement, so, on average, each new position has moved by 5 pixels; and the output changes by roughly 5 for every trigger.

That's one of the reasons why hardcore gamers pay a fortune for expensive mice with custom drivers - to get a higher polling rate for the mouse to match the super-high fps of their fancy graphics card, for more responsive and accurate mutant-alien-zombie-nazi targetting!

To get exactly 100 triggers, you'd have to 'interpolate' the mouse values, sliding up or down to the new value whenever it changed by more than one 'step' - a green/Ruby de-zipper, in effect.
But that brings its own problems...
How fast do you slide? Impossible to say because the mouse is operated by an unpredictable human - what if the next mouse message shows that they slowed right down, or decided to change direction? Slide too slowly and the user will get frustrated by the 'lag' - too quickly, and the effect is not much different than just using a regular de-zipper - plus of course the extra CPU load of the 'slider' module (which would have to be timer based).

If you need every 'in-between' value to be output because you're testing for special values, then it's usually easier to refactor the code that does the testing - i.e. test that the previous value was one side of the threshold, and the new value is the other side, so that hitting the exact number doesn't matter (that's how the 'MIDI Catchup' works in my schematic).

trogluddite wrote:Getting the "exactly 100 triggers" would be very tricky

Yeh...my 'easy solution' ideas still not working...thanks for the 'heads up' Trog.
Lots to think about....

trogluddite wrote:Until we know more from Malc, it's probably best not to use this design just yet

Any news on this..??

No news yet.
Might be quite a tricky de-bug with only one reliable test schematic (and it is quite a big chunk of code!). I've been trying to find something much simpler that shows the bug, and found a couple that do it very occasionally - but nothing yet that does it every single time like this one does.