SuperVP Cross Issue in Ableton Live M4L Device

srs · July 26, 2020, 4:49pm

Hi

There seems to be an issue with using the supervp.cross object within a Max for Live device.

When there is no audio on one of the input channels (either via the fader/mute button control or simply a section of silence in the audio), a unexpected buzzing feedback sound appears that does not occur when using the object in Max standalone with the exact same audio and parameters. It is unclear if this is an Ableton issue or something specifically about supervp.cross but either way the object is not currently fully compatible with Max for Live.

Is this a known issue for which there is a workaround or is Max for Live not supported by SuperVP for Max?

Here is a link to a Max for Live device which is just an exact copy of the supervp.cross helpfile with the only change being that the supervp.cross object’s inputs are connected to the plugin~ object:

To recreate the problem, insert this device on an Audio track and then send two stereo channels of audio to it via 3/4 and 5/6 in the ‘Audio To’ menu:
Screenshot 2020-07-26 at 17.37.23

Then mute one of the clips or channels, pull the fader down to zero or play a section which includes silence while moving the left-right balance faders.

Is there any help out there for such a specific issue like this?

schwarz · July 29, 2020, 8:57am

Hi, thanks for the effort to make a clear test case. It is supposed to work in M4L, but for some other external I had already noticed a different order of init vs. audio between Max and M4L. I’ll look into this after the holidays next week.
Bye

schwarz · August 6, 2020, 10:07am

Hi Paul, can you please post your Live set? It would save me from figuring out how to redo all the routings. Also, did you try the same thing in a Max patch and does it give different results, and if so can you post that patch, please?
Cheers!

srs · August 6, 2020, 11:43am

Here’s a link to the Live set:

The standalone Max patch is just the helpfile but with the supervp.cross inputs connected to an [adc~ 3 4 5 6]

https://www.dropbox.com/s/otnqt6qwo1m3f9i/supervp.cross~%20[ext%20inputs].maxhelp?dl=0

To compare results, route the two Live channels to ‘Ext Out’ 3/4 and 5/6 via your audio interface loopback or patchbay

There are the left-right balanced settings:

schwarz · August 6, 2020, 12:22pm

Thanks, that’s great!
I don’t hear a difference between Max and Live with the same settings.

srs · August 6, 2020, 12:26pm

Did you mute one of the source tracks in Live as per the video I sent?

There isn’t a difference that can be heard until you mute the Live track or drag the fader to [-inf dB]

schwarz · August 6, 2020, 12:28pm

sure, mute in Live and pause in Max, i.e. both receive a zero signal to the right, the output sounds the same to me (kind of frozen version of the left input).

srs · August 6, 2020, 12:38pm

There shouldn’t be a ‘pause’ in the Max patch if you are routing audio into the patch via [adc~ 3 4 5 6] - are using the original helpfile and playing audio via the [p play] method?

There also isn’t a ‘frozen’ version of the input that is heard when routing audio via [adc~] in the Max patch. Muting one channel that is being sent into Max standalone just sounds like only hearing the remaining input channel without any artefacts.

Are you hearin the buzzing/feedback sound? Is that what you mean by a ‘frozen version’ ?

schwarz · August 6, 2020, 1:01pm

I think you need to record the output for clarification. I am hearing the same thing as in your demo video in Live and in Max.
Did you check your Max audio settings?

srs · August 6, 2020, 1:06pm

Here are videos demonstrating the difference:

I have been using it in standalone for years and it’s been completely fine. The sound that is produced in the Live version is what is problematic as it occurs even when there is silence in the audio file on one of the source channels.

Are you saying that the buzzing sound heard in the Live video is meant to be there and is what you are hearing?

Or are you hearing the same audio out that is heard in the Standalone video?

smalllotus · August 6, 2020, 1:21pm

Hi,

the links towards you project is dead…

I use to patch for Max for Live, and there’s some difference between Max and M4L… I currently find some weakness in it…

you device is correct, you dont use the two first inlets, then you can routing, so it’s ok

srs · August 6, 2020, 1:33pm

Hi - just fixed the link:

Are you also hearing the same difference between the Max and M4L setups that are in the two videos?

Diemo - I’ve tested this on multiple computers and checked Max’s audio settings. The issue seems to be specific to M4L, is there some reason that muting an audio channel could cause this issue?

schwarz · August 6, 2020, 1:57pm

Thanks for the clarification! I am hearing what is in the first video (in Live) for both Max and Live.
I tried different i/o vector and window sizes but didn’t get the behaviour in the second video. What are your standalone Max audio settings? Be aware that Live imposes its i/o vector size on M4L devices.
Next thing to check: which supervp are you using, and is it the same version in Max standalone vs. Live?

srs · August 6, 2020, 2:46pm

I’ve found something which might be a path towards a potential solution. When in Max standalone, if I delete one of the inputs going into the supervp.cross~ object then it produces the same buzzing sound that happens when muting or zeroing the audio going to the M4L device in Live:

So its seems as though in Live, muting the audio sent to the M4L device somehow disables the inputs to the supervp.cross~ object instead of just sending silence.

It is strange that you are experiencing this issue in Max standalone.

My settings in Max are below but it has been working fine (ie without the buzzing sound) since Max 7 and the 2015 version of supervp.cross~

I am currently using the latest version of supervp and it is that same across both Max and Live.

Is there anything that can be done within the coding of the supervp.cross~ external to prevent this issue or is this related to how Live interacts with M4L devices?

smalllotus · August 6, 2020, 2:50pm

Maybe you have found a real M4L bug… But I can help you more than @schwarz ! When you are in Live you use Live DSP status with Max… have a look at that

I’ve set presets and almost nothing else

supervp.cross-helpfile.amxd (90,3 Ko) …

srs · August 6, 2020, 3:52pm

Unfortunately changing the Driver to ‘Live’ in the Audio Status setting didn’t fix this issue.

I am now attempting an alternative approach using the devices described here:

Diemo - please do advise if you think this is an issue with M4L or the external itself?

schwarz · August 6, 2020, 3:57pm

there’s a workaround (more like a dirty trick):
add [noise~] -> [*~ 0.000001] to the 2nd pair of inlets

srs · August 6, 2020, 4:11pm

Thanks Diemo, that works!

What a completely unexpected solution… thank you so much for taking the time to help with this. I can now get back to making music!

If I come across anything using the ‘sends only’ approach described in the previous link I’ll post it here.

Do you think this is ultimately an issue with Live/M4L or is it something in the coding of the external itself?

schwarz · August 7, 2020, 7:47am

Great, Paul, I’m glad this helps you moving on.
Now what is still bothering is that supervp in Max works differently for you than here. Did you always use the adc~ to get audio into supervp?

Thanks

srs · August 7, 2020, 12:06pm

Yes, I’ve been using adc~ to get audio into supervp for years. Since the first time I used it which was the ‘SuperVPMaxMSP-2014-11-OSX-Max-6-7’ version. It’s been working fine across different audio interfaces and macOSX versions since then.

Using the adc~ method always involved routing audio via the audio interface’s ins and outs and a physical patchbay (via cables or normalled connections) so in a way, I’ve always had a bit of that noise floor in the signal.

If you are using internal loopbacks for both stereo inputs into the supervp.cross object, maybe that is what causes it. Perhaps the supervp.cross~ inputs can’t actually have zeroes because of the way the FFT algorithm works? Maybe it’s doing some sort of bin normalisation that is fine with a bit of floor noise but not with zeroes…

That’s the only thing I can think of with my limited knowledge of FFT…

Update:
I just tested the supervp.cross helpfile patch in Max standalone with [sig~ 0] and [sig~ 1] inputs and both produced the buzzing sound. Interestingly, having [sig~ 0.5] sounds the same as [sig~ 1]