snapshot~ has some delay when banged

[Borey345]

I cannot attach a patch, but it is quite simple.

The first dac~ channel gives 5, as expected, but the second gives 2, which means, snapshot~ bang does not output a value prior to the right bang.

Would be nice, if you have some workaround suggestions.

[dromer]

How does this behave in Pd?

And just to understand the context: which generator are you using?

[dromer]

Btw considering how signal v control connections work I don't think one could expect any different behavior. Basically the control message coming out of snapshot~ is scheduled for the next audio cycle, but the bang to 2 message is still scheduled for the current one. So these messages can never arrive in the order that you expect.

Probably the only way to correct this is to wire this differently. Perhaps like this:

Or a bit simpler:

You're still going to be one audio cycle "late", but at least your calculation will work correctly.

[Borey345]

How does this behave in Pd?

In Pd the it works just like the left chain connected to the first dac~ inlet: first the right inlet of the [+~] is updated then, it is calculated to 5. I am not sure, because I came to this simple patch from a larger patch where I discovered it. I'll recheck tomorrow..

And just to understand the context: which generator are you using?

I generate C++ code, then compile in VS2019.

[Borey345]

Btw considering how signal v control connections work I don't think one could expect any different behavior. Basically the control message coming out of snapshot~ is scheduled for the next audio cycle, but the bang to 2 message is still scheduled for the current one. So these messages can never arrive in the order that you expect.

Probably the only way to correct this is to wire this differently. Perhaps like this:

Or a bit simpler:

You're still going to be one audio cycle "late", but at least your calculation will work correctly.

Thanks, I will try this, but my patch is just a simple test patch, I came up to it from more serious one, where the issue occured. Anyways, I probably can try to apply this approach.

[Borey345]

Btw considering how signal v control connections work I don't think one could expect any different behavior. Basically the control message coming out of snapshot~ is scheduled for the next audio cycle, but the bang to 2 message is still scheduled for the current one. So these messages can never arrive in the order that you expect.

Just rechecked: it evaluates to 5 in Pd, which means snapshot result is propagated before the '2' message. In Heavy, it evaluates to 2.

[dromer]

Interesting, I would've expected the same behavior in Pd. However I'm not too familiar with it's execution flow.

As said: due to how signal and control objects are evaluated in Heavy the output message of this object is scheduled for the next audio cycle, which will be later than the 2 message:

https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/generators/ir2c/static/HvSignalSample.c#L43-L47

It is not possible to change this behavior, but you can try the other patch suggestion to get the order of control messages aligned.

[dromer]

Hmmm, I'm now running a quick test and I'm not getting any output from snapshot~ which is strange :thinking:

I'm sure that I've used it before, albeit not done any extensive testing. This will need some closer investigation to understand why it is not outputting any values at all ..

[Borey345]

This is strange. I do have an output from snapshot~.

I managed to workaround the delay issue. But the workaround is kind of ugly. I had to even introduce a small signal delay line to make it work.

Anyways, right-to-left calculation with trigger~ is a very basic Pd concept, so I guess this issue needs to be addressed somehow.

BTW, I just found out that log 10 gives natural logarithm in Heavy. In Pd it is logarithm of base 10. It can be easily worked around, but still I suggest to create an issue about it later..

[dromer]

trigger~ does not exist :)

The control-flow execution is correct, but as I said snapshot~ output happens on the next block. This cannot be changed.

[edit: ok my bad I run into this issue sometimes: my test didn't have a dac/adc object which then doesn't evaluate the signal rate objects. so my test was flawed and it does more or less work]

[Borey345]

trigger~ does not exist :)

Sorry, I mean t b b thing, without ~.

The control-flow execution is correct

I would agree with you, if it worked the same as in Pd. But it is not.

[dromer]

I would agree with you, if it worked the same as in Pd. But it is not.

This depends on your definition of "it". snapshot~ is not a control object, so it doesn't behave like one.

Lets call this a "feature" and not a "bug".

Pd emulation will never be 100% and since the object works as intended I will close the ticket. Thank you for testing and reporting. Will try to add this to the known limitations.