what's wrong? delta~, sah~ and turning on the dac
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:
----------begin_max5_patcher---------- 510.3ocyVF0aaBCDG+Y3SgkelUw4XfvdXR6ywT0DAba7DXGAFsrVU9rO6ivB KJkRiJrkGL12cb7+94KFd12itSeTzPIel7Mhm2y9ddnImAuSq8nUYGyKyZvv nJwO069AMn2kQbzflajO1QfAy5VSovX90AQepctUYkTx8mB3AsxnxpP2zuVK s9N44PlIeuT832qE4l96da5cgAjnP2HeiajYm+mbIKvrXU0mRoixei7IL+.y dK8lUsURkUYXo.mM1q2dqNiu366FBlKSZq1Ip6dqpOfPenTmYNigJcAFC6Vv RJBDFOwcIIcJt.gQuGxLHGqtcKCGG0HTwtET8JsOY66VxlGFfW3gSQoH3MfT ttTW2m1v61xR3QPfc1lXdRXraVDGfD6LXzC3pj8Cnm65f7KcVYrLjDXNRPfD Dha1NEJ4vszusXToPTZx5VJr.HV3brCiOIVXKdGFrBcXPn82xRS.auhgon4F 1+UMY45VkYQOEKEwQ+A9uFTXw+afh3ohr7todcEd5AaaLVCQCiWqFRnyWqgi zJlKZoTc4mzfxwY+uKfFcac9v9y.7HmkTgnwHUYFoVMJH2qIFEzdYQg.8OP3 JYwAsTYNIBx8WEmenZx8WgUTSW73ttl3qql3yRSq6dW5LjzE6uKNlf41hCql lhlilvug8lAkcwK9+FvrdPuO -----------end_max5_patcher-----------
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:
----------begin_max5_patcher---------- 466.3ocyV9saBBCEF+Z3onoWqFJXAcY2rmiEyREpZWfVBsl4eh9rO3ffNiif NQ2Mkv4T376742g5VaK7T0JtFidA8NxxZqskEDpHf0g6svIrUgwLMrMrj+kZ 5m3dkoL7UFH7q6Q8cFPqhOSIMRVBGx8VlfEWkQszDyMl0o7xph0h4x7znIG1 PJyDtPHm+QFOzTtGBYz.mdnfwEqCgUWmAN0OhHBpSNW8ICOEAsXCTFha9yTF VtLQHyI.5F2iAK4BhRJBty1tXoWKkEcnJkuG2POLB31ufDDwyo9xk5h.b6o0 4FnkuIhE1DsACAQlRAEud8Rr52wr9KFtHdrgsuS8aTOnuG1jeidM1Mxcyt8K hR5BlVksG4LvsSUF2x4wFUlmzfX9aXJOq1Xjnh3mVfqWN5gvyhULSi5R.XUH igKT+lzEupBl+9gYhZE41EJ26mERyVzQSUGzHe3SedAMoQtOIuykkjv0gw7N bnxq7LABLN4Sa73s6qv.k.GKjm+e..JKh+S0RqVlEV0YUG2hNRZDWaDRlQnj mrobYCQp2yBQTDGRWAchHJUIjlCLflbwe5ZKRzVPzYX20H0FQJ3eGQzGJQjV ZjdbD41Bh79CDkeyN6uA446ngC -----------end_max5_patcher-----------
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.
----------begin_max5_patcher---------- 459.3ocuUErTCCBD8bxWACmqc.JlT8l+DdwwwAIXEGBjIPFq1o8a2.IQi0TS ris4PBrrr668XWxl3H3il0BKDbM3NPTzl3nnfIugn14Qvb1ZthYCtAsbSgXG bVyRblhyMUZmeMRqwBli+rTu5gRA20D6qRlilAHjk9O3EnO+.tucS5pbSkSI bgzfZsJyBI073KWfSge4pT24Iwaaabr+0rIxAs305H1ENmXsqgZJYlXG.Avn 5G3XrAmDXyUz.0NLWvCvkjtn+jQ6rx2EAGwy63cy1cuUHZxHzJWoYJ3movuO MKOrL7VQYFSyFTeV7OpOxU6.3Q0kTh+MM4HjE5YSVv+exRlP4X6FubAEJWnG Q4BkLntPlttvMJSYyZn4KIozKwypGsHglhR7itjhwo0iv8v02DyaJk0A7DKk bVgqprtG7oPO3unoDb+dPLBOhpNzEJiTrcRqkxEVKak3mJfRvJm.uIgqPWjF lr7uTLQ9q8XGQ2U+KkC6Fpj58+OSfcd6eWlrlpRdWt6p9AeQvLg0I0Lmzn64 j+F0dN8rLKSn6evmKyJLRsqEDf6G7PapXZuzc.LkddwDcBXZOw7Tiooc1cVg zoFQ0S1F+A.+DRBp -----------end_max5_patcher-----------
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.
Forums > MaxMSP