incorrect trigger behavior, possible a bug

[tester]

Okay, thanks.

On my side - I will check later whether trigger separation by a time event - depends on time or on the type of separation itself. It may provide some cue on how to make the after load a little bit more after. My guess is, that afterload is executed before anything (interactive) else, like filepaths in this example. I don't recall where, but I had some similar situation inside the schematic, where two triggers had to be sent (non-afterload), and it did not worked directly (via link order), but worked after time based separation.

I've met Synthedit less than a month before Synthmaker, and said "good bye" to it after a week of struggling or so. With no any knowedge nor experience, SM was a risky choice, but I guess the right one. I don't know if with Max I would be able to do my projects, but who knows - maybe on the far far future, doing my apps also for Mac? I'm curious whether they would work faster than here.

[nix]

Bangs(ticks)
in MAX fire at a maximum 22050hz in my experience.
I hardly use MAX, although I own it.
There is no way to make VSTs with the current version,
and .exes are messy.
There are many support files required by the MAX Runtime.
By all means try it though.
It is pretty amazing.
One major advantage is that u can build an .exe that loads VSTs.
So build your modules in FS,
then build the DAW in MAX is an option I have considered.
Cheers

[tester]

So long as I can proceed with FS, and getting acceptable results - I guess I will only talk that "maybe some day I will try it". But - thanks

[tester]

It looks that I was right. Separation via trigger order produces entangled triggers while time-based separation - produces separate sets of triggers, i.e. they can enclose entangled triggers or interactive events (like file path loading). If you can confirm it Troggie, then I guess it's a small contribution to your manual on triggers.

[tester]

Testing it on my heavy projects, I can confirm, that trigger separation via time events - helps (used 1ms period on the timer to test it). So anywhere, where trigger logic is involved, and there might be a problem with order of behaviors - my time-based solution seems be appropriate.

On my example I see it this way. Afterload triggers meant to be sent before other events happen (like loading filepaths). But if you connect the afterload to timer, then inaccurate green timing will simply wait until logic-based behaviors are done.

[trogluddite]

trigger logic is involved, and there might be a problem with order of behaviors - my time-based solution seems be appropriate.

In the case of your startup problem it's appropriate, as events are out of order that we have no control over. (needs a fix from the dev's, really). But I wouldn't advise it as a regular workaround - the best thing to do usually is to fix the trigger logic. I have yet to see any sequential logic problem that couldn't be fixed by correct trigger ordering, sample and holds, or trigger blockers.
Other trigger events can be fired and execute while a timer is waiting, and there's no reliable way to know how long that will be - anything under about 10-20ms is pretty much guaranteed to be considerably longer than the time specified. There can also be problems if too many Windows timers end up running in parallel - and if you re-trigger a timer while it's already running, you can even end up never getting an output.
So using timers as a hack can easily break things, and in ways that are often much harder to fix than the original bug that you started out with. In this case, it is a good fix only because it is the only fix.
Trigger problems can be complex, but they are rational and predictable - Windows timers behave randomly - and random bugs are ultimately much harder to diagnose and fix.

[tektoog]

In the case of your startup problem it's appropriate, as events are out of order that we have no control over. (needs a fix from the dev's, really).

Yeah, I'd really like to see a prim like a kind of selector where you input your triggers, and whatever the triggers sequence at this point, this component would act like a filter and reorder the triggers' impulse with the order the links are plugged into this "trigger order selector".
It would be also nice to have to option to select/deselect how many triggers could be sent at the same time...
I think Jay posted a ruby version of that already...

[tester]

I selected 1ms long event, to check something. Timing will be always 1ms or more, but 1ms is always more than entangled (no-time) pack of rtiggers. It's not about the accuracy of timing, it's about de-entanglement of triggers. I used my time-based solution in very large projects (a lot of startup triggers), and everything works fine.

[trogluddite]

Triggers do not get "entangled"! and there is no such thing as "no time" anything!

They happen in the order you make them and propagate in the order that links are encountered - if they are not where you expect them to be and in the order that you expect, then it is the expectation that is wrong, not the triggers. Unless the developers have fiendishly included random number generators inside the trigger engine, it could not be any other way - just a rational, predictable algorithm like any other piece of programming.

The only way to deal with them effectively is the principle of "unit testing" - don't wait until a schematic is huge and has complex feedback loops. Get the trigger counters out early at the "building block module" stage, and check every condition for triggers that you don't want, and what order they enter/exit the module. Then build up, safe in the knowledge that you truly understand each building block.
The best way to fix bugs, is simply not to create them in the first place by working methodically, and not introducing "unknown factors" into the schematic. Hence my advice not to use timers except in the most exceptional circumstances - they can introduce a classic case of a well-known problem called a "race condition" - and like all races, the favourite may win most of the time, and when circumstances are ideal, but you just never know when a rank outsider will come out of nowhere.

This file load problem is a very special, singular case - the primitive is buggy in that it is not initialised properly at the time that the trigger system is started. Just a programming error - it offers no mystical insights into the workings of the trigger system.

[tester]

From what I could see, observing the behaviours of my projects - in green cases - triggers involved in pure trigger order/logic are entangled (no-time = no visible time events involved; by no-time I'm also refering to your "handshake" metaphor for hidden events), while triggers separated by green time events - seem to behave more freely - in regards to entangled packs for example. I don't know if you follow what I'm telling here (guess you cant diggest the word I use - "entanglement"; I use it context of quatum physics - entangled triggers seem to depend on each other in similar way). But no matter what you say - for me it has practical implications in terms of working solutions. I'm not going to wait until environment designers decide to correct certain issues. Plus - I don't remember where - but I had similar problem with triggers somewhere else (not related to filepath system), and solved it in the same way, and it works. I'm making my life easier.