Pointer/Reference syntax issue? Why is this giving me a read access violation?

General JUCE discussion
21

I’m glad to hear you’re making some progress, and it’s also good to see that you are open to trying different approaches. Hopefully this is teaching you a lot about C++/Juce and getting you to think a bit differently about the general architecture of your code. It’s always good to constantly be reevaluating your own decisions as a programmer.

Cool! So my suggestion would be to test each of these on their own. In your synth app, with the threading going on and so much else happening, it’s hard to isolate and determine if there are any bugs specifically with your audio or MIDI FIFOs.
I would recommend that you make two simple JUCE apps/plugins, one that does nothing in processBlock except add to/read from the audio FIFO, and the other that does the same for your MIDI FIFO. If your FIFOs are well written, then you should be able to set an arbitrary latency/delay for the readout, and it should pass the audio/MIDI cleanly through perpetually. Open your tester apps/plugins and start sending some audio/MIDI through, and make sure that the output is exactly the same as the input, just delayed, and that it works smoothly forever. If you find any bugs, fix those before going back to working on the multithreaded synth as a whole.

Once you’ve debugged your audio & Midi FIFOs and you’re confident that they’re working reliably, then you can more confidently start to debug the rest of your synth.

22

A few notes about your current synth code, while I’m at it:

in your ThreadInherited class, why is the inputNewSample method called that? What it’s inputting is a MIDI message…

In your processBlock, there’s a much easier way to iterate through the events in a MIDI buffer:

// INPUT MIDI TO CUSTOM THREAD
std::for_each (midiMessages.cbegin(),
               midiMessages.cend(),
               [&] (const juce::MidiMessageMetadata& meta) { testThread.inputNewSample (meta.getMessage().withTimestamp(meta.samplePosition)); });
23

I assumed that you meant you had created an AudioFIFO class and a MIDIFifo class, but now that I’m looking at your code a bit more, I can see you’ve just implemented the logic directly in your thread class, using a regular juce Audio & Midi buffer.

I would suggest abstracting this logic into some classes. It will be much easier to test, and your thread class’s code will be much cleaner & simpler.

For an example of how you can build an Audio & Midi FIFO class, you can reference mine:

24

IMHO, it would be better to use an AbstractFifo-based fifo. This also gives you thread safety and single-producer-single-consumer functionality:

template<typename T, int Capacity>
struct Fifo {
    int getNumAvailable() const { return fifo.getNumReady(); }
    int getCapacity() const { return Capacity; }
    bool push(const T& t) {
         auto write = fifo.write(1);
         if( write.blockSize1 > 0 ) {
              buffer[write.startIndex1] = t;
              return true;
         }
         return false;
    }

    bool pull(T& t) {
        auto read = fifo.read(1);
        if( read.blockSize1 > 0 ) {
            t = buffer[read.startIndex1];
            return true;
        }
        return false;
    }
private:
    std::array<T, Capacity> buffer;
    juce::AbstractFifo fifo {Capacity};
};

You can add a prepare() function if you need it to hold something other than samples, such as AudioBuffers.

It’s also a lot simpler to use one instance per channel of audio. The big thing is thread safety, though.

1 Like
25

Yeah, the classes I posted were just as an example for the kind of interface a FIFO class should have.

In my own projects, I always use those classes as SPSC, with the producer & consumer operating on the same thread. I totally agree with something like the AbstractFIFO if you need the producer & consumer on different threads.