From the original SynthMaker forum (2004–2014), with its members’ names and dates.
McBarGig ·
Guys, There is a chance I'm doing something wrong, but I don't think so... I have 2 integers, one subtracting from the other..like 5-5, should equal zero right? 5+5 should equal 10 right? Wrong I get numbers all over the place...?
This is in public Release version 1.1.7...
In the above example adding 156 + 156 I get an answer of 968 Subtracting 156-156 I get an answer of 656
Here is the OSM...What am I missing? Is this a bug?
aliasant ·
lol
I made some changes to it to try to simplify it and I think this is better as a clue to this weirdness. Test it. It also provides a temp solution sort of but clearly a bug that needs to be reported .. by the finder 🙂 After you hit the trigger you will see the correct sum in the last readout but the weird one only needs a tick to be corrected. Click once on the input of the faulty readout and it will update itself to the right numbers.
trogluddite ·
There's a 'Misbehaving Triggers' thread in the bugs forum - might be worth reporting it there, there seem to be quite a few people having problems with this kind of thing lately.
MichaelBenjamin ·
yes that happened with me too. somehow the green path gets some trigger hiccup and it stops propagating and shows odd values, so i had to manually trigger again to get the right values.
infuzion ·
1) Time uses a Window's call to grab the CPU timer, & this system call is flaky IIRC. 2) The examples above prove SM long-standing issue with green-timer issues. Known for... the last 5 years? 3) Trigger-order might have something to do with this. Remember that SM can only do one thing at a time, though the audio stream may (?) process on a different thread than green. So I'm guessing two Time primitives can not be connected together for this reason. That is a bummer, since my advanced wireless Heartbeat-trigger system uses Time, & may cause issues. 4) I'm also thinking that Window's multitasking (switching processes) might have an influence on when & how Time & green paths gets used (similar to #2). 5) aliasant, using inline Float & Int etc is flaky. Please don't use. 6) Testing aliasant's OSM made SM lockup/crash after hitting the Trigger a few times fast.
aliasant ·
I did test replacing the time prims with the rsndom prims instead and got the same results but maybe that is because the random primitives uses windows time as a seed?
About it crashing ..... I had that with a tick counter i made that used several time prims to valculate the time difference between seversl ticks. It crashed when feeding to many ticks to more the 1 time prim so i had to scrap that idea.
infuzion ·
aliasant wrote: I did test replacing the time prims with the rsndom prims instead and got the same results but maybe that is because the random primitives uses windows time as a seed?
I'm thinking if the Window's time() is the issue, then yes.
trogluddite ·
Here it is even simpler - just S+H from an integer box, so no windows timer issues. Put a new number into the integer, press the trigger - wrong answer still, until you press the trigger a second time.
If you watch the trigger counter connected to the subtract, you see only one trigger received for each press - so presumably whichever subtract input gets a trigger first is OK, but the trigger to the second input gets lost. I'm guessing that this is because ultimately both triggers begin from the same place; but I would have expected the trigger to be split into two triggers - one travelling down each path, to make sure that both subtract inputs are always updated.
Seems there is definitely a problem here with triggers that take multiple paths between the same start and end points. Simple enough to see in this example, but could be a very hard situation to track down in a bigger schematic.
You can make it work properly if you use the R&D Trigger Thread to explicitly create a trigger for the second subtract input - the subtract then receives two triggers and updates correctly. BTW, I'm not suggesting that this is a good work around! - the Trigger Thread comes with dire warnings about stability, and it does make the output boxes flicker alarmingly on my system!
Tzarls ·
I changed your schematic a bit, and now it works as it should - well, kind of.
Still, there´s something not working right inside SM.
oddson ·
I don't think fixing it is the issue... it's the fact that it's broken in the first place.
Here's another.
This was going to be my answer to storing only the start index of concatenated samples and calculating the end and length values form the i+1th entry (would have still needed a case for i=n but that's not the point here).
The index value has to get 'kicked' to trigger the integer subtraction primitive to produce the expected result.
The problem didn't resolve for me with a reload nor a reboot.
infuzion ·
I hope this pic sheds some light:
Malc, please fix this bug ASAP; McBarGig is becoming allergic to stew. 😉
Tzarls ·
oddson wrote: I don't think fixing it is the issue... it's the fact that it's broken in the first place.
But I wasn´t trying to fix it. I was just trying out some other combinations to try to find an explanation. Isn´t it weird that the S&H gets the right result from the "subtraction" primitive, but that same primitive (sub) won´t show the right result at it´s output? This isn´t (just) a triggering problem....
McBarGig ·
Infuzion...LOL
Yes I am becoming sick of stew...and... Casseroles, which turn out to be baked stew!
🙂
McBarGig ·
No Tzarls, I am beginning to think its specifically because its my code! 🙂 Ever see a Puppy chase its tail...That seems to be my new adopted development technique..! haha
I just wanna get to where things work so I can concentrate on other stuff like speeding up the preset loading, Volume balancing, etc. I can't really do any of that. To a certain degree I cannot rely on getting the right numbers..without that you have nothing as everything is a calculation, from something simple all the way to tube code...So, for sure this type of error, should probably be getting a high priority in the to do list, and, I'm sure that Malc will place it on the list accordingly..
When I came across this issue I was testing techniques for calculating time from click to click. For something like a Tap Delay...I just wanted to see how accurate the above technique was...Obviously not very, even if it was working...However, for such a function it really does not need to be extremely accurate...give or take 50-100ms... The user is only looking for a "ball park" delay time anyways, if they want spot on accuracy, type the number in, or use a knob...
So, anyone got any ideas that work for doing this?
infuzion ·
McBarGig wrote: To a certain degree I cannot rely on getting the right numbers..without that you have nothing as everything is a calculation, from something simple all the way to tube code...So, for sure this type of error, should probably be getting a high priority in the to do list, and, I'm sure that Malc will place it on the list accordingly..
Math.... is that what DSP is all about?!? Dang I wish someone told me that 5 years ago; I hate math! But I guess if one is to do math, it should be precise. Or else we should call it guessing, not math. Is anyone email Malc about this? His lack of responding is getting me worried. 😕
McBarGig wrote: When I came across this issue I was testing techniques for calculating time from click to click. For something like a Tap Delay...I just wanted to see how accurate the above technique was...Obviously not very, even if it was working...However, for such a function it really does not need to be extremely accurate...give or take 50-100ms...
You never opened my Christmas present! /cry (actually someone else wrote the timed timer part IIRC)
McBarGig ·
Yeah thats right...The Christmas wreath...Nice work BTW...🙂
trogluddite ·
Tzarls wrote: This isn´t (just) a triggering problem...
Not so sure about that - I think the triggers are the place to look. In the 'working(kind of)' schematic, the final S+H (the 'kicker') will always get the right value because it will send a 'reverse' trigger back to the subtract, causing it to update its answer - the readout for the subtract isn't on that line, so you don't see the answer appear there. You can test this by putting a trigger blocker on each of the subtract primitive's inputs - the 'kicker' S+H will still get the right answer whenever it receives a trigger. As oddson says, having a work around isn't good enough - in a large schematic, the faulty triggers could be taking complex paths via several modules before reaching the point where it all goes wrong - apart from making de-bugging awkward, it's potentially very confusing for new users, who then end up posting broken schematics for us to all try and fix.
trogluddite ·
Posted another example to show how the S+H affects the problem - I've put it on the 'Misbehaving Triggers' thread as that has a more obvious name when doing bug searches. Misbehaving Triggers
McBarGig ·
Trog...
it's potentially very confusing for new users, who then end up posting broken schematics for us to all try and fix.
Not just that, but have them release faulty schematics as well...Then what happens? All the work that has been done to Try and make SM a more acceptable as a plugin platform becomes junk...All the ANTI-SM Nazis will have a field day...
In terms of Large schematics, this issue will have you running in circles. We've lost at least 12 days(cumulated) on this trigger issue. Malc has been great in providing a work around, but it still is an issue where we may not be able to get the work around to function. So, we're now at a point of just removing entire sections of our Schematic when they stop working, for whatever reason. In terms of development, this is as serious an issue as we have ever come across and one that could make us move to native development a little faster than originally planned. Native development also has its pitfalls, but in that case you are in total control, here our hands are somewhat tied...There really is nothing we can do about this...
infuzion ·
McBarGig wrote: ...this is as serious an issue as we have ever come across and one that could make us move to native development a little faster than originally planned. Native development also has its pitfalls, but in that case you are in total control, here our hands are somewhat tied...There really is nothing we can do about this...
*cough* open source *cough*
McBarGig ·
What release Shred as open source? hmm, I believe in the open source movement, but not that much...🙂
infuzion ·
McBarGig wrote: What release Shred as open source? hmm, I believe in the open source movement, but not that much...🙂
The link in my post lead to releasing Sythmaker as open source. Get some sleep! 😀
McBarGig ·
haha dude you know me too well, Yes I have been working for close to 14 hours today...Its 1) My freaking Birthday. 2) Mothers day. 3) I can't really get anything else done until this fix is complete...So, yeah I should get some sleep...🙂
attic ·
Any news on this? 🙁
McBarGig ·
I could have sworn I posted the fix to this here...hMM...weird.. Anyways here it is..
Hope that helps
infuzion ·
McBarGig wrote: I could have sworn I posted the fix to this here...Anyways here it is..
Using the Int Loop as a trigger delay is a neat idea! But your OSM still outputs the wrong result for the Float Subtract, though a 2nd trigger is quickly sent to output the correct data. To always send the correct result, a S&H is needed just before your output.
Tzarls ·
But when using the S&H at the output, there´s no need for the "new ID" module.
McBarGig ·
haha are we going in circles or is it just me...🙂
Infuzion, That Idea was Malc's..
infuzion ·
Tzarls wrote: But when using the S&H at the output, there´s no need for the "new ID" module.
Indeed, so it seems that S&H is the best solution, if the S&H works that is.
attic ·
I was worried about this one, but it seems to work. Thanks for posting that. 🙂
BertAnt ·
i think it's not a major bug, in fact i don't think it's a bug at all... i inserted trigger blocker before one of the input in subtract / add primitives, and it works as it should...
the reason i put the trigger blocker at the bottom, is for preventing add/subtract sending out results before both values arrive, and the bottom input of the add/subtract primitives received value first before the upper input..
the problem without trigger blocker is, both S/H is sending out trigger, and since those aren't happening at the same time, the add/subtract produce two results, and the one that got displayed on int primitive is only the first one, i guess it's because the limitation of display rate 😕
so i think, what happened is, when trigger is pressed, the add /subtract primitives are adding/subtracting the output of S/H from the top Time primitive, with the previous value of the bottom S/H first (because the current value from the bottom S/H hasn't arrived yet), then sending the result out to the int primitive (which got displayed), and only after that, the second S/H from the bottom Time primitive send another value that triggers the adding / subtracting with the top S/H, and once again the add/subtract produce results, which are the correct ones, but not got displayed on the int primitive 🙁
hope it helps 🙂
McBarGig ·
Nice work around...
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker