Is the only place to output Midi from a plugin in processBlock?


#1

All the examples I’m finding of outputting Midi from a plugin seem to do it in processBlock where you’re given a MidiBuffer as one of your arguments and can put new messages into it.

Can I get at this buffer anywhere else? To send Midi out from anywhere else? (In VST)


#2

No, if you want the MIDI messages to go further down the host’s plugin processing chain.

In theory you might be able to open a hardware MIDI device to send messages into that, but it’s not really something you should build a product on. (It’s highly system and host dependent if that would work or not.)

Why do you think you should be able to do that somewhere than in processBlock?


#3

Well I partly wondered because the processBlock is on a very tight, fast thread which is executing a lot, and my Midi processing and events are being generated by something which is happening less frequently than that. So I thought it was overkill to go into processBlock for them.

Also, it’s a bit of a faff getting events being generated elsewhere (on a timer, in a child Component) back up the tree of Components into the Editor and then down into the Processor, in order to send them off.

There doesn’t seem to be a way of encapsulating Midi all in one place rather than have it spread everywhere.

However, if that’s the right and reliable place to do it, I’ll do it there. I really wanted to confirm that.

Cheers


#4

You might want to consider restructuring your code so that the MIDI data generation happens in the AudioProcessor. It’s generally a bad idea to do a lot of important work in the GUI parts, since the plugin is not even guaranteed to have a GUI around at all times. (When you hide the plugin GUI in a host, most of them will just destroy the whole GUI etc…)


#5

Hmmm …

What I have is a kind of playable “instrument” in that the user does things to in the UI and this generates Midi to be sent to other tracks.

I have an informal “model / view - controller” separation in my actual code. But there isn’t much “state”. So I’ve had the model object just created by and owned by the Editor.

Is that a bad idea architecturally? Intuitively I’m still a bit vague.


#6

To add one more detail:
the processBlock method is the only code, where you have time information. Everything in the GUI code and on the message thread can only rely on the wall clock. But you want to be able to record the midi, replay it or even render it in offline.
You still can call methods from inside the processBlock, but then all restrictions about not doing anything with nondeterministic duration apply to these functions as well.

Also: model and state are quite similar concepts (if not the same).


#7

OK.

Thanks. I see some refactoring is in order.