Tzarls wrote:Maybe it has to do with the trigger ID thing..... since the same trigger gets to the switch, it must be blocking the second just because it has the same ID the first one had.
Why couldn't they have left it alone? It took a lot of hard work (and forum posts), from many people, to nail the workarounds for the previous trigger system's "quirks". Do we really have to go through all that again?
The green triggers are always going to require a few compromises, so why not stick with the compromises we know how to deal with, so that our hard earned knowledge remains useful. (I'd make an exception for the 'Holy Grail' of sample accurate triggers, of course!)
aliasant wrote:Wouldnt it be nicer if triggers behaved?
trogluddite wrote:aliasant wrote:Wouldnt it be nicer if triggers behaved?
I agree with your sentiment - and I've had a tiring week at work, so maybe I'm extra pessimistic - but I'm not convinced that the trigger system will ever behave intuitively under all circumstances. But 'intuitively' is not the same thing as 'predictably' - for a while now, complaints about trigger problems have been quite rare, and most posted schematics with trigger issues have been solved quickly. Besides which, most trigger issues I see reported are trigger order problems (i.e. programming errors) rather than bugs.
I just don't think that the improvements (I haven't noticed any yet) are big enough to be worth sacrificing back-compatability for. Of course, right now I'm pissed that I have some big broken schematics - but I can't help also wondering how many schematics posted on the forum (for everyone to use and learn from) will also get broken. You yourself described your fix in the other post as 'ugly'.
I only report 1/3 of the bugs I find anymore, sometimes directly to support@SM. I found the toolbox bug over a year ago, but I'd prefer for Malc to work on SSE3&4.aliasant wrote:I don't think everyone reports their problems.
Users browsing this forum: No registered users and 1 guest