antwan

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.

Here's an patch displaying the problem, the sah~ _should_ output a value _only_ as the count~ crosses to exceed 10000:

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.

Here's an patch displaying the problem, the sah~ _should_ output a value _only_ as the count~ crosses to exceed 10000:


whats-wrong-delta-sah-and-turning-on-the-dac

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.

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.


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:

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 :) 

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.

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 ~ or

We'll see if C74 can confirm what's up. But thanks for your insights spectro!

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 ~ or 

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.

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~.

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