"Supergreen" theory

[tester]

check the mystery

The mystery at the moment seems to be the X11.
An awefull big task to identify exactly what's responsible.

@biliv - step by step.

1) Add some looped wave or stream based pulse generator, that you can combine with X11 output (L+R mixed or L and R separately).
2) Create automated/looped behavior in X11, something that will allow you to compare things going out from X11 with stream based reference output.

In other words make a fixed test design.
Then you can place schematic, export exe, export plugin - whatever.
But first step would allow to observe the "mystery part" in action, on various PCs.

After that - we can try to identify what is responsible for unexpected results.

*

By the way. I noticed something that could be usable. Mono to graph. When I found that little fellow with lissajous curves - channels were made with separate m2graph primitives, and it was out of sync when displayed. But when I used dual channel mono to graph instead (so only one trigger goes in, but two synced arrays go out) - graph became synced.

[RJHollins]

basically you understand the trigger / event system, but your assumption is wrong.

Think of it this way:
Any green connection line in a Schematic, is a delay line. And the delay of any of these delay lines is completely random.

So if you manage to send a precise timed trigger from Ruby into a green output, this output can be in sync. But the connection of this output to another input adds a random delay. So nomatter what is connected, it's automatically out of Sync.

Yes ... have indeed read the 2nd post. In fact, I look forward to reading many of MyCo's postings from here to SM as there is often much for me to learn from them. Unlike some, I don't pretend to read a single post and think I know everything.

Too bad some feel that their 'quip' remarks make them feel important ... when in reality they are basically ignore.

Thanks to the few who actually share useful knowledge and information. It is much appreciated.

I also miss TROG's post. I hope everything is alright with him.
Sincerely.

[MegaHurtz]

First of all MH - you are trolling too much. People know your activity on SM forum. Are you sure these forums are for you? If you don't cool down your engines, one day, rather sooner than later - someone will decide to take effective actions in regards to you. Don't blame others if you are removed from both boards then.

[billv]

I think that's why malc is not answering Myco call either.

Who said that?

You mentioned at one point you were waiting on malc's reply.......didn't see any news....so I just
pre-sumed he was busy or something.....
So any news...???......

anyone noticed Trog has been in his cave for a while

Good thing for us he's got bits of his brain splattered all over the forum.
So he's always accessible.......

@biliv - step by step.

(Note:...havn't "started anything here yet, and the attempts may be have to be "on a backburner"
for a few weeks, I got a new menu starting next week, and new menu's are notorious for killing
personal time(lots of paperwork) so not really confident on getting through all that very quicky.)
Still thinking about it about your first idea.......and now this next one...more to think about...

1) Add some looped wave or stream based pulse generator, that you can combine with X11 output (L+R mixed or L and R separately).
2) Create automated/looped behavior in X11, something that will allow you to compare things going out from X11 with stream based reference output.

In other words make a fixed test design.

Today i had another thought...might be better to work via subtraction...
Idea was to pull the whole Seq Module out, slap a vsti on....if it still rings true....
that eliminates about 750,000 parts in one hit.....(rough guess)
Then just pull out piece by piece untill the timing fails...... should reveal "threshold" point or 'sucking"
So it may be quicker to track this sucker down than we originaly thought....

[tester]

Whatever you do connecting to "combiner" part (whether this is adding or substracting) - keep in mind that you need a fixed reference signal (maybe some sort of ramp?). You can't connect two dynamic parts with each other and compare them this way.

Second - you can move out the sequencer, but first - check if the sequencer alone (without other parts) - produces that stability too. These 1000000 parts - use the same "hearts", even if on schematic they seem to be independent. Anyway that would be the procedure and logic behind.

[billv]

because method was so quick...couln't resist having a quick go...

The X11 is a "car" now...the engine needs a Chassis and wheels to run spot on...

Pulled the seq/time system out of the 2.01 update...Here's the test unit.
(The interface is what i wanted, but time has not allowed the full re-build, so it's still very messy inside..)

X11 2.01 Seq System_test.fsm

(852.44 KiB) Downloaded 913 times

Results....

ARP SEQ -PASS
DRONE SEQ -N/A
USER/HOST -N/A
USER/ARP -N/A
WAVE SEQ -FAIL
DRAW SEQ -FAIL
SCALE SEQ -FAIL
4 NOTE SEQ -FAIL
Then i loaded the full X11Synth (2.01)....
ARP SEQ -PASS
DRONE SEQ -N/A
USER/HOST -N/A
USER/ARP -N/A
WAVE SEQ -PASS
DRAW SEQ -PASS
SCALE SEQ --PASS
4 NOTE SEQ -PASS
Spot on everywhere.....

So now were back in the s**t again......staring at 1 million grey areas.

Could it be just the way it's designed..............

And we know that Myco speaks the truth in these matters, stating the laws/rules/regulations of FS.
But the X11, is making a joke of that truth, the same truth and "Standards" that we need to build well.

@Myco
Nothing's changed bro.........I'm still holding that royal flush baby.....

[billv]

@Myco

But I'll still throw you some "chips" and some "irish whiskey"...

SUPERGREEN IS DEAD.

Theory was based around the timer..blah blah....

I think you were better off with Supergreen , at least we had it "isolated"!!!

Now your in the same prison me, surrounded by a million parts, with no method of escape.

Welcome back to the X series development....

[tester]

Good to see the first step after us, isn't it?

Okay, following the procedure - I would now think - how to split the concept of X11 into sub-concepts. It does not matters that the whole X11 is made of 1000000 pieces. What matters is, that the X11 is made of few interconneted modules/concepts. Probably, at least one of these modules - creates the mystery by itself or by interactions with the rest of the schematic. I said "probably", because we don't know yet if this is one concept or a mixture of concepts that makes this. Something is reordering the heart to beat regularly. Maybe it's the hierarchical architecture plus total amount of triggers wandering around, and maybe it is something tiny but very specific, that reinforces the FS engine to take that road.

I would start now with making the test design on a whole X11. Very simple but effective step. Check if this works on your machine, and give others so they can confirm it or not.

Then I would start with disconnecting concepts, one by one. First - just by removing the whole large parts, and after finding some reference (if it will be found that way) - I would start disconnect sub-parts by type. I think the types can be described as: ruby windows, tick receivers, active streams, large array processings, and (for some reason) gui related live calculations. Last spot on the list would be these millions of tiny live calculations. And maybe a quick answer to the question - is there anything that accumulates a large amount of triggers and tries to release them as fast as possible (or blocks sub-triggers from other parts to be released).

But as I said - step by step. Make the whole X11 test design, and put inside some instructions on procedure (what to watch for, where to see the results; disable from main view unnecessary visuals, no need to remove them). Meanwhile - try to describe point by point - main operational parts inside. Also an easy step.

[tektoog]

Hey,
I don't know what this is worth...
2 short videos that shows how SM and FS rely on windows timers:
First one, just grabbed your test module in FS and dragged around the workspace: it throws the timing off.
Second, a PPQ to ramp module, (ASM 2 mono) so sample accurate, same exercise: timing stays ok.

Timing OFF.rar

(1.84 MiB) Downloaded 912 times

Timing OK.rar

(1.56 MiB) Downloaded 865 times

[tester]

Yes, dragging modules around the workspace will kill (delay?) green triggers. As far I remember, on exported schematic similar thing could happen. I had there a randomized sound flow based on green triggering, and each time I did something (but I don't remember details, it was more than 1 year ago) - sound was stopping to flow, until I finished.