Strange issue with updating cached value and midi playback [resolved]

EDIT: Dont you always realize the answer to your question immediately after you post on the forum?
So it turns out it wasnt the update causing issues. It was what happened in my value tree listener code. I was listening for pattern changes, and when the pattern change occurs I generate a new midi sequence to reflect the pattern and add this to a midi clip. I guess this sequence generation was what was causing the issues, because I removed that and it works fine. Gonna have to find a way to efficiently generate the sequence.

I am building a basic step sequencer. I started off using the step clip but noticed that its meant to support 16 channels and I will probably need more than that so I rolled my own simple step sequence object. However I have noticed something weird whenever I try and update the BigInteger pattern.

My app listens for midi events and specific events are then forwarded on to components that are listeners via a callback message (everything then happens on the message thread). The pattern updates occur whenever the user presses a midi note while holding a modifier button. The midi note should still be heard even whenever the user is adding a note to the pattern (with live input monitoring on).

For the most part this works. However the act of updating the value tree property seems to interfere with the midi note playback. Maybe every 2nd or 3rd note doesnt sound when the key is pressed.

Here is the code that updates the value tree (via a juce::CachedValuejuce::String called pattern)

 void StepChannel::setPattern(juce::BigInteger& b)

    pattern.setValue(b.toString(2), nullptr);


The update works great and the pattern is updated, but for some reason its messing with the midi note playback. If I comment out the call to setValue, the midi notes are all heard correctly.

I cant understand what is happening for this value tree update to be interfering with the midi note input monitoring. Its been bugging me for weeks and I have yet to find a solution. I have tried not using a cached value and just a regular value tree property. Currently the value tree that holds the pattern is a child of the track state, so I have tried not making it a child of the track but that didnt work. Is the act of listening to the midi input causing some issue?

The midi listening code is based on the juce midi input tutorial, and the step sequence code is based on the step clip code.

I’m glad you’re making progress with this. Can I ask what the actual problem is now though? You mention “Gonna have to find a way to efficiently generate the sequence”, does StepClip::generateMidiSequence not do what you need?

Im actually not using the step clip. I was using it initially but I saw in the comments of the header that it only had 16 channels and I need 24. I also found it a bit complicated haha so I thought id start with something simple. Im just storing the patterns in a value tree and then just looping over them and adding them to a midi sequence

 void StepSequencerViewModel::generateMidiSequence()

        auto& sequence = midiClip->getSequence();

        for (int i = 0; i < getNumChannels(); i++)
            for (int j = 0; j < getNumNotesPerChannel(); j++)
                if (hasNoteAt(i, j))
                    sequence.addNote(i + 53, j, 1, 96, 1, nullptr);


I was doing this every time the pattern was updated and I guess this was affecting midi playback somehow. I changed it to generate only when the user navigates away from the screen (which is really the only time it needs to be regenerated anyways) and I dont have any problems anymore. I am curious why this affects the live input monitoring though.