what's wrong? delta~, sah~ and turning on the dac

Feb 23, 2011 at 7:04pm

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:

– Pasted Max Patch, click to expand. –
Feb 24, 2011 at 11:20am

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.

Feb 24, 2011 at 12:07pm

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:


– Pasted Max Patch, click to expand. –
Feb 24, 2011 at 12:48pm

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.

Feb 24, 2011 at 1:11pm

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!

Feb 24, 2011 at 5:35pm

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.

– Pasted Max Patch, click to expand. –
Feb 24, 2011 at 8:36pm

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.



You must be logged in to reply to this topic.