AudioProcessorGraph help needed

General JUCE discussion
1

Guys, I’m using the AudioProcessorGraph in my latest code, but I came up with some problems. I’m pretty sure I’m doing something wrong, and I’m VERY sure its something stupid. :oops: :mrgreen:

Now, to activate the graph, I use the following code:

void FilterComponent::prepareToPlay (double sampleRate, int samplesPerBlock) { graph.setPlayConfigDetails (getNumInputChannels(), getNumOutputChannels(), sampleRate, samplesPerBlock); graph.prepareToPlay (sampleRate, samplesPerBlock); }

Which works correctly, pretty much all hosts that I tested this out it runs the way I want. BUT, recently, I just discovered that LIVE 8 doesn’t like when I call “graph.prepareToPlay (sampleRate, samplesPerBlock);” - if I leave this out, it works on LIVE 8, but not on any other host I tested. And it gets worse, the error only happens when I re-call a LIVE set. If I start a blank one and add Wusik Station to it, it works. (grrrr)

So I wonder, what I’m doing wrong?

I just did a small test, with an empty graph, using Juce AudioProcessorGraph, and using the initiation above, nothing else. And it crashes on LIVE when loading a LIVE set that has Wusik Station on it. I didn’t even load anything else, just an empty VST with AudioProcessorGraph inside. :shock:

Any clues?

Thanks in advance. 8)

2

No one? :frowning:

3

Which version of Live 8 are you using ? I mean Live 8.x.y …
Live 8 can be very buggy when it comes down from VSTs . You can check out this thread for more information : http://forum.ableton.com/viewtopic.php?f=2&t=25171

4

Its Live 8.0.9. But sadly, I don’t think its a Live issue, but a Juce issue, as there are other hosts with the same problem related to the graph…

5

Sounds like it’s maybe a problem with the order - perhaps at the point you’re calling this, it doesn’t yet know the number of channels… I’d suggest running it in the debugger and having a look at the numbers it’s using to see if they’re sensible.

6

Got it, tested, its not that. I’m starting to think its something related to the Editor. I will run some more tests.

Live seems to create the editor right at the start, even if its closed or hidden… strange.

7

I will try to work with the default juce example of a plugin, adding a graph to it and see what happens. Just to clear something I made wrong up. :oops:

8

Ok, I just took the Juce Plugin example, clean, and just added a Graph and tested with Live, and it crashes. Here’s detailed info about what happens:

Startup Live, here I used the Demonstration version 8.0.9 with a 30 day full saving licensing, which is free. I added Juce Test plugin, all good, saved the live scene, started a new scene, loaded up the previous
scene and it crashed.

So its simple to reproduce the problem: create a new project, add the Juce Test alone, nothing else, save, re-load, crash.

Now, here’s what I did in the Juce Plugin VST example. (Windows 32 bits XP 2)

[code]void DemoJuceFilter::prepareToPlay (double sampleRate, int samplesPerBlock)
{
// do your pre-playback setup stuff here…
graph.setPlayConfigDetails (getNumInputChannels(), getNumOutputChannels(), sampleRate, samplesPerBlock);
graph.prepareToPlay (sampleRate, samplesPerBlock);

keyboardState.reset();

}[/code]

[code]void DemoJuceFilter::releaseResources()
{
// when playback stops, you can use this as an opportunity to free up any
// spare memory, etc.

graph.releaseResources();

}[/code]

[code]void DemoJuceFilter::processBlock (AudioSampleBuffer& buffer,
MidiBuffer& midiMessages)
{
// for each of our input channels, we’ll attenuate its level by the
// amount that our volume parameter is set to.

for (int channel = 0; channel < getNumInputChannels(); ++channel)
{
    buffer.applyGain (channel, 0, buffer.getNumSamples(), gain);
}

// in case we have more outputs than inputs, we'll clear any output
// channels that didn't contain input data, (because these aren't
// guaranteed to be empty - they may contain garbage).
for (int i = getNumInputChannels(); i < getNumOutputChannels(); ++i)
{
    buffer.clear (i, 0, buffer.getNumSamples());
}

// if any midi messages come in, use them to update the keyboard state object. This
// object sends notification to the UI component about key up/down changes
keyboardState.processNextMidiBuffer (midiMessages,
                                     0, buffer.getNumSamples(),
                                     true);

// have a go at getting the current time from the host, and if it's changed, tell
// our UI to update itself.
AudioPlayHead::CurrentPositionInfo pos;

if (getPlayHead() != 0 && getPlayHead()->getCurrentPosition (pos))
{
    if (memcmp (&pos, &lastPosInfo, sizeof (pos)) != 0)
    {
        lastPosInfo = pos;
        sendChangeMessage (this);
    }
}
else
{
    zeromem (&lastPosInfo, sizeof (lastPosInfo));
    lastPosInfo.timeSigNumerator = 4;
    lastPosInfo.timeSigDenominator = 4;
    lastPosInfo.bpm = 120;
}

graph.processBlock(buffer,midiMessages);

}[/code]

And in the headers file, of course, I added “AudioProcessorGraph graph;”

That’s pretty much it.

So, what I’m doing wrong?

The code above works on all other hosts but LIVE.

9

It appears to be the following call:

void AudioProcessorGraph::buildRenderingSequence()

I’m trying to understand that code, but I’m having some trouble with that. :oops:

In any event, any help would be great, as this is the only thing that’s holding me down on releasing Wusik Station V6. :shock:

10

…

11

Scratch what I said above. Here’s the REAL solution for now, at least until I understand things better.

In the call: void AudioProcessorGraph::buildRenderingSequence()

if I remove MessageManagerLock mml; everything works them, on Live and other hosts.

So my question is, what does MessageManagerLock does, and why its crashing with Live?

For now I will leave this out, as it seems that everything works without it. :mrgreen: 8)

12

Ah, the good old “I don’t understand what this thing does, but removing it seems to help” approach! Nobody’s ever got into trouble like that before!..

The lock stops the UI thread from being able to edit the nodes while the audio thread is busy using them. Thinking about it, a better approach would be to use a critical section instead of a MM lock, but that’d involve adding code to lock all the methods that manipulate the nodes or connections.

13

Ahhh, but why its crashing, since I don’t do any UI stuff with my graph. :wink: All I know is that by removing it no problems seems to appear. In any event, for me, it did solve the problem.

14

In the event it solved the problem for you, other problems may arise for others. “Hacks” are not “Fixes”, especially when regarding threads :slight_smile:

15

The MM lock must be doing something that interferes with the way the host works - not surprising, as an MM lock is a very complex task, involving message posting and lots of locks. It’d certainly be better if it was done with normal critical sections.

16

So, what’s the final solution for this problem?

17

No solution yet? :cry:

18

Sorry, haven’t looked at it…