When livecoding with some data types, values remain in ports and can't be removed (until the composition is stopped)

Steps causing the bug to occur

  1. Create an audio composition with either Mix Audio node or supplied Multiply Audio Node
  2. Feed more than one audio cable into the Mix or Multiply node
  3. Drag out the input list to allow blank ports
  4. Run composition- and in realtime move the audio cables to other list inputs
  5. Audio buffer is not cleared from last input and retains data, causing signal to be either added (if using Mix) or multiplied (using Multiply)

How did the result differ from what you expected?

I expect the Audio buffer to not be retained from a previous cable connection. I believe this is an issue with the Audio Type, within the node “awm.audio.multiply” I am checking each channel with the function: VuoAudioSamples_isPopulated(). Thus VuoAudioSamples_isPopulated must be retuning true for those phantom channels.

Have you found a workaround?

Only workaround is to quit composition loader- and restart it.

Other notes

  • Vuo version: 1.2.0
  • macOS version: OS X 10.9

Notes: contained in zip is composition & awm.audio.multiply.

AudioBufferRetainIssue.zip (5.17 KB)

Screen Shot 2015-12-28 at 4.15.08 pm.png

This is a small movie outlining the problem. You can see that it is running the node at c. 100 FPS. No audio intentionally within this recording.

Just created this node to check a list of audio inputs and if they are populated. This also exhibits same behaviour. Screen shot below. It can clearly be seen that two audio cables are connected - yet the node thinks they are all connected. Composition was obviously running throughout test.

Using vuo.audio.populated exhibits same behaviour when live coding and removing cables. When you remove the audio inlet cable even when refreshing the node it still returns true, only way to ‘reset’ to false is to quit composition and restart.

Audio is populated list.zip (12.1 KB)

Screen Shot 2015-12-28 at 4.27.23 pm.png

As of Vuo 1.2, all data types leave their value in the input port when you disconnect a cable during livecoding, so this has a wider scope than just VuoAudioSamples. I updated the title to reflect that.

For some data types, such as VuoReal, it seems desirable and intuitive to leave the latest value in the port — for example, if you’re feeding time into Ripple Image’s Phase port, when you disconnect the cable, it stops at the latest phase, instead of resetting back to the default Phase=0.

However, for other data types, such as VuoAudioSamples (and VuoLayer and VuoSceneObject, for example), it’s confusing and undesirable, as you noted. I’ll see if we can tweak the livecoding cable disconnection code to reset port values to empty for data types like those.

Thanks @smokris!

I don’t know how vuoaudiosamples_ispopulated() works without clearing the buffer data when disconnected. I found that it only works when first run (which may work to test for audio stream from device) but then wouldn’t work again if that connection was changed? Is that the current role of the function- as a once only test for audio device input? The only other way around it is to hardcode a lookup table within effected nodes but that is getting messy. Otherwise is there a better function to test for cable connection? I don’t want this to be solved only to cause more issues in future. Maybe fixing within node not port type is better?

Maybe we need a universal vuoclearinput() and simply place that after the node has executed? That way many nodes can utilize this feature and it won’t break any current functionality unless custom coded into node. (And then we have choice to switch it off if you want to do cheap wave-table like circuit bending without a custom node). This may be useful even for non-audio nodes in future.

Sorry for triple posting but maybe a simple vuoiscableconnected(bool) function is all we need to check for cable connection everywhere? And based on its value we can choose what to do? I doubt it would cause extra overhead in calculations.

Just read about checking for event bool. Maybe this is better.

VuoAudioSamples_isPopulated() just performs a simple samples.sampleCount > 0 check on a given VuoAudioSamples structure. The default value in the port has samples.sampleCount == 0, but sample buffers generated by, say, Make Audio Wave have a nonzero (currently 512) sampleCount. When you remove the cable, the last sample buffer stays in the port (which is what this bug report will fix).

There isn’t currently a way for a C node to determine whether a cable is connected to a port. (Though we do already support Port Actions — the ability to determine whether an event hit a particular port, and react differently based on that, like the Count node does.)

Great @smokris. So if you are able to make audio buffer clear on cable disconnect- then we can use VuoAudioSamples_isPopulated() to test for cable connection? Because if we use a VuoList_VuoAudioSamples then simply expanding the list makes the node think there are inputs currently.

if you are able to make audio buffer clear on cable disconnect- then we can use VuoAudioSamples_isPopulated() to test for cable connection?

VuoAudioSamples_isPopulated() tells you whether there are audio samples in an audio buffer.

But it doesn’t precisely tell you if a cable is connected. For example, you could have a cable connected, and a sample buffer with zero samples could come through that cable, in which case VuoAudioSamples_isPopulated() would return false. That’s the case both now, and after this bug report is resolved.

It’s analogous to strings in C:

  1. const char *z = NULL; means there is no string present in variable z
  2. const char *z = ""; means there is a string present and it has no characters in it

Like the C example, Vuo treats nonexistent values as being distinct from existent-but-empty values. In Vuo you often see situation #2 — for example, if your node has a list drawer with 5 ports, your node will always see 5 list items (even if some list ports aren’t connected). Some of the list items may have no contents, depending on the data they’ve received, but the list items will always be present.

I was really trying to say “test for cable connection as well as sample presence”. Which is how I am currently using it for multiply audio node. Both need to be true as we are multiplying the buffers so 0 * 1 = 0, so a dead buffer = no sound - that’s why it’s so important. (And why it works when composition is first run but not after cable adjustments).

So hopefully it will work as anticipated when rectified.