SynthMakerMo ·
Hi, it seems "OR" is not sending update trigger, using fast switch:
Edit: This is with SM v2.0.3. Seems fine in v1.1.7.
Slow OR *SOLVED*
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
Confirmed; the OR gets the 1st trigger it seems using a trigger counter, but not the 2nd.
aliasant ·
Confirmed here too. Da%n
I was hoping triggers was working ok now...
Tzarls ·
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.
aliasant ·
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.
Yes. Something like that. I just had a similar thing here: Light Trails
trogluddite ·
Seems that the Switch is OK because the triggers arrive at different inputs, but the OR isn't because they arrive at the same input. I still haven't put my main machine on SM2.03 yet, because I got worried when I saw that the trigger system had been changed - but it seems I have some similar problems with some control logic in a couple of schematics when tried on SM2.03 on my backup PC. Trouble is that this I'm using xome BIG sequential logic, and I'm not even close to being able to pinpoint the source of the problems yet.
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 ·
trogluddite wrote: S
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!)
hehehe I know how you feel but I truly think this is for the better... at lest once we / they got it working. As it is now it takes a many many hours of scrathing heads and bal..... before you understand that it isnt your fault or your bug but triggers not behaving.. and then more scratching before you realise how to work around it... and then a few hours later it happens again and the circus starts all over again.
Wouldnt it be nicer if triggers behaved?. Ialready think its working better but I hate that I have to fix things I have already fixed just because they aint buggy anymore.
It'll be worth it. One day In a future far far away....
trogluddite ·
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'.
aliasant ·
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'.
My worst problems are complex green stuff that works 7/10 times. Definetly not predictable unless that is what you predict.. If the future triggers behave the same 10/10 times Im ok with occasional ugly fixes. It will at least be much much quicker to spot and fix. Like this last one I fixed. That took about 1.5 minutes to find and fix because it behaved the same everytime.
About the amount of error reports, and posts in the forum.. I dont think everyone reports their problems.
They might not understand that this is something that can be fixed and that it isnt their programming error. They might find the problems so erratic that they just skip it, moves on, finds another way to do the same, commits suicide or at least a big hammer in the LCD screen they now used to have.
Mo ·
Found a 1ms Trigger Delay as a workaround for now. BTW it would be nice to have old function back. Will send a mail to support soon, if it's not done already?
DigitalWhiteByte ·
I do not seem that the bug is in the primitive Boolean Or, why it works by adding a simple trig, apparently does not update the Boolean primitive. 🙁
infuzion ·
aliasant wrote: I don't think everyone reports their problems.
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.
sunsynth ·
DWB i noticed it 2 in my actual project:
The boolean isn't updated or has a missing redraw in it...
Please report this directly 2 malc!
trogluddite ·
Malc has mailed me Re: the 2.03 trigger changes - see post HERE. Note that the Int Switch HAS been changed in SM2.03.
Wrote something here? To have a post removed or your name hidden, write to [email protected].