Bug or feature?

[fabb]

i posted this in the general forum, but now i'm not sure anymore if this is a bug afterall. if it's a feature, please explain me how and why it works this way.

look at this picture:

countyman4.png (9.18 KiB) Viewed 682 times

shouldn't the output be 1 after pressing the button? pay careful attention to the connection order on the left side!

first the counter is reset and then incremented. this means that the output of the counter first changes to 0 and sends a trigger out and second is incremeted and sends a trigger out. (and the couter really sends out 2 triggers in this case, i tried it out).
but that would mean that for a very short amount of time the integer sampler would sample a 0 and then on the second trigger it would sample a 1. but it doesn't. that's what's odd.

as far as i have understood when there are two outgoing connections of an output (like in the first example the trigger), at first the one without a black ring is processed and triggers domino-like (or waterfall like to speak in the words of the manual) through the whole schematic until it dies and THEN the second outgoing connection starts its own domino-trigger-rage.
is this not the case?

greetings,
fabb

[MyCo]

Hi!, it's a bug and it only happens with the integer sample&hold, look at the attachments.

[fabb]

thank you for confirming! i already felt like an idiot as noone believed me in the general forum.
good to know a workaround for this, better have a conversion in between than a wrong value.

so there also seems to be a problem with the "trigger switch" component:

countyman.png (12.11 KiB) Viewed 654 times

the second trigger should pass through.

[fabb]

can you think of a workaround for the second issue? i'd really need this (pass triggers from the counter on only when it didn't jump to 0).

[oddson]

Good spot Fabb... the integer sample and hold is outputting only once when it receive two 'simultaneous' triggers.

...can you think of a workaround for the second issue? i'd really need this (pass triggers from the counter on only when it didn't jump to 0).

Is there a specific reason the reset needs to go first? It seems to work when the reset is on the second trigger output.

[fabb]

yes there is! i posted this in the help forum to let this threat uncluttered: http://synthmaker.co.uk/forum/viewtopic.php?f=12&t=6099

[fabb]

the problem seems to be bigger than thought. it also happens with all green "compare" components.
one of the two triggers is always lost on the way.

[MyCo]

that's bad, but maybe it is an internal optimization of SynthMaker. Something like the redraw limiter, so it ignores multiple triggers in a short time period. I would think of something like that, because if you have 1000 calculations in green, and send 2 triggers in 1 milisecond it would cause 2000 calculations in 1 milisecond and probably freeze S|M.

But that's just a guess, so maybe Malc could tell us if it's realy a bug or an unknown limitation

[fabb]

yeah, would be good to hear from the devs (as they're no deafs ).

i tried with most of the green components which have any green ins and outs and it's fine with many of those. even with ones like text load it works fine. btw: a redraw limiter in between even lets both triggers pass!
but most of the "math" category and many of the "flow" category won't do (and all of "compare").

the ones it doesn't work with (included the ones from above):

buggyones.png (76.17 KiB) Viewed 528 times

it's strange it works with component like "ascii to string" but not with "int to hex".

and a funny thing:

funny.png (27.68 KiB) Viewed 525 times

feeding an int/float/string switch witch a doubletrigger will only let through one. but letting it switch twice by connecting the counters output to both inputs lets through all 4 triggers fine! ???

[fabb]

+ i tried to do a workaround for the problem stated in the other threat. i tried it with the "int transition" component. same problem here, swallows the second trigger, too.

[malc]

Hi fabb,

The way that the triggered data system works leaves it susceptible to infinite loops. If you have a component send out a trigger that eventually returns to itself then this can go on forever and the software will lock up.

We have two mechanisms for preventing infinite loops from occurring. The first is the frozen links system where if the software detects an infinite loop it 'freezes' that section of schematic out. These are seen as transparent red dotted links.

The second mechansim is the one you're seeing. Some components have a check to see if the same trigger has been to that component already. If it has they ignore it. The Int Sample and Hold has this. In the vast majority of cases this would work just fine but you've spotted a scenario where you don't get the behaviour you want.

I need to think of a good way round this. Changing the Int Sample and Hold to work like the other S&H components would work but it might break something else. There are certainly some quick workarounds but I need to think them through.

Thanks for flagging this,

Malc.

[fabb]

thanks for responding, malc.

actually i'd just need the trigger switch to not behave like this and i would be glad.

[fabb]

the problem is, directly connected the trigger switch works fine in the one example i need it now. but when i 'really' use it and the incoming sysex-answer triggers the incrementing of the counter it strangely doesn't.
i thought that the two triggers are too close to each other, but directly connected it works?? sending the midi message and receiving the acknowledge should add a bit of latency, no?
maybe you can clear up what's going wrong here: