"Supergreen" theory

[billv]

I would start now with making the test design on a whole X11

Ok tester method no.3......great stuff....still thinking......

First one, just grabbed your test module in FS and dragged around the workspace: it throws the timing off.

Yeh, the seq module just doesn't work on it's own, full stop.

Second, a PPQ to ramp module, (ASM 2 mono) so sample accurate, same exercise: timing stays ok.

Thats interesting...any chance you can upload that one???

I don't know what this is worth...

It helps mate....were in the s**t here....any help is appreciated
Late for work....will check your uploads tonight...thanks for that.

Yes, dragging modules around the workspace will kill (delay?) green triggers.

Again the X11 is a "troublemaker" here....try picking up the X11 and dragging and throwing it around
while recording...damn thing dosn't miss.

[tester]

On the other hand - maybe it's time for X12?

[tektoog]

any chance you can upload that one???

Sure,
It's a Trog's thingy I believe... Here you go:

Test PPQ to Ramps.fsm

(26.75 KiB) Downloaded 1082 times

Check the videos also... they talk for themselves
All the best...

[billv]

2 short videos

They were great. Thanks again for that.

maybe it's time for X12

There was remember?... and an X13, but they were XFL series. I think the links are still up at
corestylers place.....X13 was interesting, it was the "cyto continous blend" idea all through it....
had problems implementing it via SM, but may bring it back.....now it's FS.....might be ok...

It's a Trog's thingy I believe... Here you go:

Yeh, got that code, but this set up different to anything i got....cool....thanks mate..

It's a Trog's thingy I believe... Here you go:

Everthing seems to be a trog "thingy"....sneaky bugger is everywhere...here's the proof of that...

SUPERGREEN IS ALIVE. RESURECTED FROM THE DEAD BY TROG'S RUBY COUNTER.
Here is the exact same test unit from yesterday....this time with all Green counters replaced by Trog.
Every seq is spot on here.

X11 2.01 Seq System_test_Ruby Counters.fsm

(864.47 KiB) Downloaded 1055 times

I remembered the huge gains i got from Trogs Ruby counter during the v3 PPQ Timer experiment.
So it only made sense. Test unit is 100 000 parts.....gremlin has been isolated
But I'm pretty sure if i went through all the timers and seq systems i uploaded, and replace them
all with ruby counters.......that would be the end of story.

So if anyone's using any of my stuff, it looks like the general tip is to always use Trog's counter.

@tektoog
Do your experiment again...you can see the difference trogs counter makes.....
the sound remains same, but watch the Clock Display, i left green counters in this module...
watch em freeze up while trog counter keeps the engine running....unreal


So where do we go from here....
Do we accept this Supergreen theory?
Can anyone come up with a better explanation?

At the moment, I'm just gonna blame Trog and Malc......
EDIT....
Malc = everyone at DSPR.
EDIT AGAIN:
(note in fsm remote is still connected to start button....so press"k", to start/stop at any time....)

[RJHollins]

I don't know ... but sure hope we get a TROG sighting !

[billv]

Maybe i offended him by not implementing his counter straight away in my stuff.
For me it's just "one experiment at a time"...there were no ruby counters in 2.0 update.
Would have really compromised the investigation had I started using it.

[RJHollins]

you do know how sensitive the TROG's are

let's hope he can 'overlook' your transgression

[billv]

..ahh..bummer...did some tests and got some errors here and there...not consistant...

Damn....stuck inside the X11 again.....

.....yes i know tester............still thinking..........

[billv]

Na..I give up......
No way i can "cowboy" this one to the finish line, even with tester helping out.
This gremlin is hiding deep in "guru-land"...
@SUPPORT
Why does X11 2.0 nail it when it theory it shouldn't?

we got ..."friction" theory..... "boeing 747" theory ........."sucking" theory........

[tester]

It's not about what "we can accept" it's about asking right questions to the guru's. For example, if you impose on MyCo your supergreen theory, you probably will end up with his "heee?", and yours "have a nice day" again. And he is right. "Supergreen" is a metaphor (1+1~2), not a "rigid fact" (1+1=2). Gurus may not understand the metaphors (~ ?! #$%. = !!!). I'm (not a guru) on the other hand resistant to concepts (no matter how right or not they are), because I know how to deal with "magic boxes" in general, even if I don't know what's inside.

So I don't know what's inside you rmagic box, but to avoid crashes with gurus, I would ask questions like these now.

1) Can others verify your results on their machines, and to what degree?
(i.e. in what circumstances it works, in what circumstances it doesn't; like with dragging the schematic around the workspace, or how many/often errors in comparison to earlier test design).

2) What (in their opinion) causes the quasi-stability, if they encounter it? And to what degree it may be expected?
(open question vs rigid statement; I still use my "entanglement triggers" descriptor/metaphor, but I don't use it so often asking questions about what is going on).

3) Can this be (in their opinion) used/controlled by purpose?
(what to pay attention to?).

And don't forget about your initial conditions. Sample/stream accurate or certain (what kind of) degree of accuracy?