Trigger Divide Is Broken

oddson · 2 Jul 2009

Try this:

Although it does show that there are less than four times as many Tick100s as Tick25s.

Tom7777 · 2 Jul 2009

Thanks, I know you can divide the values once converted as a workaround though.

The example is to show that the module is broken and needs fixing. Not only is the ticks offset as said but if you try what i said about replacing the module they pass through as if it was 100 still untill you save and re-load the osm, if you try it hopefully you can see what i mean as it does it every time i test.

oddson · 2 Jul 2009

I think the problem is that you have two gates (trigger switches) for the triggers so a different number of triggers can get through to each counter (perhaps this is the bug).

My file puts a single gate on the ticker100 so that the same number of ticks reach the divide as the second counter. When this is done you get the expected results (I did see one example that was off by one but that could be because the gate let a trigger through the first but not the second link as it closes[?]).

I put the divide on the other side not as a 'workaround' but to show the results are consistent.

I'm saying I don't think it's the trigger divide where the problem is.

BTW- looks like there are 3:1 Ticker100s to Ticker25s... strange.

Tom7777 · 2 Jul 2009

Not trying to be rude but you are wrong it is the trigger divide however the other modules coulde be broken also possibly.

I noticed the problem to start with via the trigger divide only, the thing i noticed was that it was animating far to quickly. I then tracked it down to the trigger divide and it was passing all 100 triggers. So i found it was broken by this and it was only later i used the trigger switches and counters to demonstrate this so i could show it side by side with the tick 25 in the osm example.

After saving i checked again because in the past problems sometimes go on re-load so it's hard to prove it happens. What it did though then after saving was at first it looked like it corrected the problem however it would then divide the triggers yet the amount was offset. In anycase this is a bug that shows another through the example so now thers 2 bugs.

If you do what i said and delete then replace the trigger divide with one from the toolbox without saving it will show you it passing all 100 triggers. Since it shouldn't require a save to work this is a bug alone but as you say the triggers amount is messed up also. Without the trigger gates though it runs the triggers when the osm loads which slows down loading and is why i added them in.

Edit -

Just to check i deleted the trigger gates and it still happens, the trigger amount is offset stiil. If i delete the divider and replace it with a toolbox one it passes all 100 and matches the tick 100 triggers.

oddson · 2 Jul 2009

Gottcha... and I can now replicate.

Sorry about the confusion. 😇

I wasn't reading your post carefully enough but when I opened and ran yours it gave slightly odd results but not apparently from the divide. (But you did say it's fine on a saved file...)

The bug appears to be in reading the attached integer value. When you connect it up it reads as '1' and passes everything. Clicking the input doesn't fix it but changing the integer does seem to as does an explicit trigger received at this input.

My theory that the trigger switch was not firing quickly enough seems to have been outright wrong as well.

Meanwhile I've tried to figure out the actual rate of fire on the two types of tickers...

I get about 21.33 off the Ticker 25 and consistently and exactly 64 off the Ticker100.

Here's the measure tool I've used:

aliasant · 2 Jul 2009

oddson wrote: I get about 21.33 off the Ticker 25 and consistently and exactly 64 off the Ticker100.

Here's the measure tool I've used:

I sent a trigger counter to mals last week and hes on it. First he tested on one computer and got 98 ticks from the 100. Then he tried on his laptop and got the 64. Same as me and many others.

oddson · 2 Jul 2009

Did he say: 'don't worry about it the new version with a proper event mechanism will be out soon'? 😉

Tom7777 · 2 Jul 2009

Np oddson and thanks for the testing tool. 🙂

As you say when you connect the int it seems it doesn't make the connection at first. After testing it seems it starts the divide when you change the int so it needs to be updated to receive the int when connected. The triggers amount after divide needs fixing also and it seems the counter is broken also if what aliasant says happens. I think the divided amount is definately wrong though and it's not the counter as it would match the tick25 only give the wrong value still. Hopefully malc will fix these modules to work correctly. 🙂

oddson · 2 Jul 2009

To verify it's an updating issue all you need to do is disconnect the integer, change it's value and reconnect. It will continue to divide based on the previous value ignoring the change until it gets an actual trigger through the integer input.

Tom7777 · 2 Jul 2009

oddson wrote: To verify it's an updating issue all you need to do is disconnect the integer, change it's value and reconnect. It will continue to divide based on the previous value ignoring the change until it gets an actual trigger through the integer input.

Yes correct, when the int is active though the trigger amount is still offset from the tick25 however and as 100/4 = 25 one would expect if the tick100 is divided by 4 it would match the tick25 yet it does not at the moment.

Edit -

I notice if you change the divide value from 4 to 3 it will match the tick 25, it does seem slightly off on pausing the values though usually by 1 but sometimes by 2 or more. It should use a value of 4 however but maybe it's that way to round the value to trigger amounts or something but it seems odd so it's possibly just a bug on the value input also as well as the missing trigger to activate when you connect the int input.