what's wrong? delta~, sah~ and turning on the dac
Hi everyone,
I’m in need of some help and fresh brains to figure this out:
I’m having trouble understanding why the sah~ in this patch outputs a value everytime I turn the dac on. I managed to trace it to the delta~ object (using capture~) which seems to output one samples worth of 1. before correctly outputting 0.
Thanks in advance for any insights!
Here’s an patch displaying the problem, the sah~ _should_ output a value _only_ as the count~ crosses to exceed 10000:
Not sure precisely where the problem lies, but in case you just want to test for the one condition only – as your patch is currently doing – you could replace the >~ 10000 and delta~ with ==~10000 and be done with it.
Hi spectro and thanks for chiming in!
True enough, in this particular case that would get us around the problem.
I was then going to say: "but what if we were looking for the 1. to 0. transition of a phasor~ instead?"
But then I thought I’d test it out and oddly this isn’t causing the same problem, so it would be really nice to understand what is causing this – it feels like some sort of bug, despite my badly coded first example. Any more thoughts, C74 or someone? I don’t tend to enjoy not understanding phenomenons like this :)
Here’s the phasor~ example that works just as I’d expect it to, with the delta~ used in a similar fashion:
Cheers,
antwan
It could well be a bug, (even in the >~ rather than delta~) perhaps. It would be good to know, but maybe there is some kind of wisdom in not expecting states of msp~ objects to behave as you might (reasonably) expect after the audio scheduler is stopped and resumed.
Indeed, we await if someone carrying that particular wisdom will surfice to guide us :)
One more test shows that it seems to specifically be related to the >~ or in fact also < ~ preceeding the delta~. So same phasor~ originated example but with either >~ or < ~ going into delta~ causes same problem.
We’ll see if C74 can confirm what’s up. But thanks for your insights spectro!
----------begin_max5_patcher----------
468.3ocwV98aBBCDG+Y3uhl9ryPADzk8x96XwrTgNsKPKgVy7GQ+aezCDcFj
fNQeoDt6f6y8s2QYqsEdlbESgQuh9.YYs01xBLYLXUcuENktJJgpfvvB1OxY
eiGT5RyVoAyusG4LbzAyeIEZAMkAtdOmSSN3QtTmvz50YrxjhU74hB2noUAj
Q0QK3h4elyhzkwPHiG5L.4G.qiLqtNCcpeDdLjmBrdg7GDT7MPZHtEOSoYwx
Ttnf.nXbOZrjKvJwXbmssYYPGUEUjLisG2RMLdhg6.CIHhmS8klphPb2o04F
nksIlF0Fsg9fH6SNp3l0lXMnmY8B8awrDMceu1uEVV29s0ucUsaj6V61EDkr
ETkL2LI50qJCIDzmVUF+myfXwaXFKutwHUFyNMAWubL.g+JQR0spKgdfrLAt
LJnMcodmo38CyD0JxsKTt2uVHEcQOMUUoQAvm97BaSibeR8NMKIQqiRXlgJ2
9QX7JOSf.iSAse718UXfTfS3hy+E.fRi8+pVJ4x7nCUV0PN5HnwLklKnZtTb
RLlijOInE73XF3+.zo73LIWnqX.MswstthzYoqYldrH0EhJ5sPjGFQcYeK7w
ts0QM5wQjaGHx6ePTwM6r+0+pL5p
-----------end_max5_patcher-----------
The issue here seems to be that when there’s a constant one at the input, upon audio start, this value is compared to a previous value of zero. One way of looking at it is that at the moment that audio starts there is no previous value, and therefor delta starts comparing against zero. Another view could be that the previous value was the last value before audio was turned off.
You’re right, that seems to be the core of the issue.
I was definitely expecting the latter behaviour, that is, expecting the last value before audio was turned off – just like a count~ or a phasor~ does. But now I notice there are more inconsistencies like this: for example phasor~ vs cycle~.
cycle~ always seems to start from the "beginning" as audio is switched on as opposed to phasor~ or count~.
So wow… don’t know what to make of it anymore. Perhaps just that it’s not necessarily a bug but a bunch of logical inconsistencies which makes it harder to predict how things are going to work when patching.
a