Why would clicking off "Record Enable" on a Cubase MIDI track cause a JUCE Synthesiser to crap out? Desperate for ideas

#1

For the past month or so, my primary JUCE synthesiser (which I learned JUCE to build) has been in good working order from a functionality standpoint. I have been very, very happy with it.

However, I have been increasingly frustrated by an abnormal behavior I can’t explain or understand. I have narrowed down the exact operation that is causing the problem, which I will describe here.

I am using Cubase 10 as my DAW and the synth as VST3.

The synth displays an abnormal behavior whenever a MIDI track feeding it has its “Record Enable” button clicked off. Ie. In this screencap, “MIDI 01 (D)” is a MIDI track feeding “C Guit A L” which is my JUCE synthesiser as a Track Instrument. By default, Cubase enables recording on any MIDI track you select. But if I deactivate this red button, either by manually clicking it, or clicking to another MIDI track instead, there is a significant chance that my Synthesiser will crap out and no longer be able to process any MIDI after doing so. This abnormal behavior can be triggered during playback or when the project is stopped.

I can then typically restore function to the synth by powering it on/off in the Synth Rack (works 95% of the time) or by resetting its parameter tree with a “reset” button build into the synth.

If I trigger this abnormal behavior during playback, the synth will continue to render the existing MIDI note without Note Off as long as playback continues. (ie. The last playing notes will hang until they naturally decay.) However, no further MIDI is processed (it is silent to new notes until ‘reset’ as above). This makes me wonder if there is something specifically in the MIDI handling that is going awry, as it can clearly still output audio after the glitch occurs - it just can’t process new MIDI data.

Is there anything that should be happening inside the synthesiser when the “Record Enable” button is clicked off? Is there any way I can figure out what is happening when this button is clicked off?

My understanding is that when Record Enable is red (on), the synthesiser is getting MIDI both from the recorded track data and from any MIDI inputs that are live within Cubase. When you click it “off”, Cubase turns off the MIDI routing from external devices to the synth, and only the recorded track data continues to be fed to the synth. There is a momentary “lag” when you do this and playback hangs momentarily whenever you click it off.

My best idea is that possibly during the Cubase delay when playback “hangs” from doing this, something is being disrupted in the MIDI buffer and it is being corrupted. I have locked my entire void AudioPlugInAudioProcessor::processBlock in pluginProcessor.cpp with const ScopedLock renderLock(lock); as its first line. Wouldn’t that protect it against this sort of problem? Is there anything else I should try locking to see if it fixes it?

I need to solve this as now although my synth sounds great, I cannot practically use it in projects. Instances constantly crap out even just from me clicking around the project from MIDI track to MIDI track, and then I must constantly audit which instances are still running or not and keep disabling/enabling them in the Synth Rack to try to bring them back. It’s become impossible.

This is the only abnormal behavior I can observe in the synth after weeks of playing with it and this is the only way I can trigger it.

I would greatly appreciate any thoughts or ideas on what this might represent or what I could try next. Thanks.

0 Likes

#2

That’s because Cubase has a feature called “ASIO Guard” which means it calls tracks that are not armed for recording with a much larger buffer size.

Once you arm the track for recording it lowers it back to your set buffer size.

Your bug is probably related to how you deal with buffer size changes in your synth.

1 Like

#3

Thanks so much eyalamir! That makes sense and it appears you are 100% right as to the cause. I disabled ASIO Guard and the problem stopped. However, playback is not as good this way of course unless I increase the buffer to compensate.

So the problem is happening due to ASIO Guard increasing the buffer size when de-arming tracks.

I am uncertain where this should be compensated for in my design. I am using a pretty standard JUCE Synthesiser implementation.

I am guessing it should be done somewhere in PluginProcessor.cpp as that is the highest level part of the buffer handling that I have access to without digging into deep JUCE stuff.

Perhaps here somehow:

void AudioPlugInAudioProcessor::processBlock (AudioBuffer<float>& buffer, MidiBuffer& midiMessages)
{
	const ScopedLock renderLock(lock);

    ScopedNoDenormals noDenormals;

	
	buffer.clear();
	mySynth.renderNextBlockCustom(buffer, midiMessages, 0, buffer.getNumSamples());

}

But I still can’t imagine why there is a problem. How can a buffer size increase disrupt it? Ie. The buffer is cleared every time it is accessed, and the number of samples is checked and used for rendering every time. I haven’t changed anything in terms of how the synth handles buffers in any more detailed fashion.

My mySynth.renderNextBlockCustom just looks like this:

void renderNextBlockCustom(AudioBuffer<float>& outputAudio,
		const MidiBuffer& inputMidi,
		int startSample,
		int numSamples)
	{
		Synthesiser::renderNextBlock(outputAudio, inputMidi, startSample, numSamples);

		//MONOCOMP
		if (monoCompOnOff) {
			monoComp.renderMono(outputAudio, startSample, numSamples);
		}

		//DISTORTION
		if (monoDistOnOff) {
			monoDistortion.renderNextBlockMonoStartSample(outputAudio, startSample, numSamples);
		}
		//DELAY
		if (delayOnOff) {
			monoDelay.renderNextBlockMono(outputAudio, delayTime, delayFeedback, delayPrePostMix, delayDWMix);
		}
	}

Even with those custom effects off, the same problem happens.

If I build the synth in Standalone, I can easily increase or decrease the buffer size with no problems.

So it seems to be something unique to ASIO Guard and how it’s triggering these buffer size changes or interacting with my synth during the buffer increases from de-arming tracks.

Is there anything you could speculate on that might suggest a pathway for finding a solution or what I could try?

Thanks again.

0 Likes

#4

I imagine the problem is not in the part of code that you showed, that part seemed correct.

The problem is that somewhere in the internals of your synth you might keep track of the buffer size, or expect it to be something else.

Make sure that anything you do that has something to do with the buffer size, such as the sizes of array, etc, is re-adjusted on prepareToPlay.

I’d say your compressor and delay might be a good place to start… But maybe even something in your actual synth does that.

0 Likes

#5

Hey,

So interesting update. I spent today trying to provoke the issue in my various synths under various conditions. It turns out I can only provoke this problem when two things are true:

  1. I am using a very heavy duty synth of mine requiring a major CPU usage thread.
  2. It is also in a very heavy project using >50% CPU total.

I cannot provoke it in any circumstance using a very simple test synth (based on same architecture as big synths but minimal) or in simple projects using only 1-2 synths (even using my heavy synths here it is fine).

I have also noticed this has happened once or twice in my big projects with instances of Guitar Rig where they “fail” and can no longer put through audio.

Given that it only happens with my biggest synths, in my biggest projects, and that Guitar Rig has seemed to have fallen to the same dysfunction at least a few times, I am inclined to believe this may be more a Cubase/resource related problem with ASIO Guard than an obvious design problem on my end.

Would that be a reasonable conclusion to draw?

I’m not releasing anything for commercial use anyway - this is just for me. So I’m thinking for now I’m just going to leave ASIO Guard off. Perhaps it is simply not well suited for the types of synths/projects I am doing and that is creating the glitches.

Maybe I could improve this with some type of better synth design. But at this point, if there’s no problem in the low resource projects, then I doubt it’s anything obvious.

Thanks for the help again. At least I can keep going now.

1 Like