its a simple fix, you have to throttle the data
i.e. send some of the data, wait a while , send some more
also, the api, has a call which tells you how much space is left on the queue, you should not be sending data when it says its full .. actually id back off a bit, before that to give some headroom.
the reason is simple... midi data is not sent in the audio thread (for obvious reasons), therefore it has to be stored/queued - this takes memory (aka ring buffer), which has to be 'finite' , we could allow more , but then you'd have less space for your patch
(the amount i chose was a compromise, for large messages and midi 'bursts', and the fact that in 'normal' operation there usually is only one or two messages 'in flight')
in my experience (when i did this for the Push1) the issue is, when you want to initialise a grids leds, you send a load of messages in one go... way more than you would in normal midi use.
as i say, the easy solution is send at a rate where the queue does not build up too fast,
don't worry, this is fast enough, that in practice, as a user of the grid, you won't even see this.
for the push 1 , i had to not only initialise all pads, but buttons and the LCD, and even though i throttled the data, it still 'appeared' to be instantaneously initialised.