Getting MidiOutput from AudioProcessorGraph

[oxxyyd]

@jrlanglois

Write an AudioProcessor to handle this, and put an instance of it in the graph with the final MIDI result connected to it?

As suggested by mrBlasto above? Guess I could, but isn’t that the role for AudioProcessorGraph::AudioGraphIOProcessor (AudioProcessorGraph::AudioGraphIOProcessor::midiOutputNode)? If not what’s it there for? In the same was as you use

AudioprocessorGraph you use AudioProcessorGraph::AudioGraphIOProcessor (AudioProcessorGraph::AudioGraphIOProcessor::audioOutputNode)

to get the auodio out?

The topic suggests that this should work now, but apparently it doesn’t without further fixing. I think the missing point is that you still need to shuffle the midi events to the output with a call to

myDeviceManager->getDefaultMidiOutput()->sendBlockOfMessages()

but where do you put that call?

[jrlanglois]

Guess I could, but isn’t that the role for AudioProcessorGraph::AudioGraphIOProcessor (AudioProcessorGraph::AudioGraphIOProcessor::midiOutputNode)?

You would think, yes… Sadly, it has little purpose. But even if it worked, it doesn’t provide a flexible means of dealing with MIDI externally from the graph itself.

The topic suggests that this should work now, but apparently it doesn’t without further fixing.

There’s nothing to truly fix from the graph’s stand-point, in my opinion.

myDeviceManager->getDefaultMidiOutput()->sendBlockOfMessages()

This could be easily wrapped in a custom processor to have the result MIDI outputted to your desired MIDI device.

My answer, like the original one, is a swift and flexible solution, if you think about it.

[oxxyyd]

I think AudioProcessorPlayer should be updated with

if (!incomingMidi.isEmpty())
midiOutput->sendBlockOfMessages(incomingMidi, Time::getMillisecondCounter(), sampleRate);

after the line

processor->processBlock (buffer, incomingMidi);

Then it will play the midi all the way to the output.

midiOutput could be made an optional parameter to AudioProcessorPlayer()

[jrlanglois]

OMFG that’s horrendous on so many levels! Talk about a damned hack to get what you need working for your particular scenario up and running asap.

For starters, not only would you limit the AudioProcessorPlayer to one MIDI device (if there’s even one available), you’ve not given a means to tell which device MIDI gets sent to!

Also, AudioProcessorPlayer is an AudioIODeviceCallback and MidiInputCallback… Where’s the interface for MIDI output in those base-class’ exactly? (Why would one not exist already?)

(Just a quick note: there’s nothing wrong with hashing quick solutions for doing small things in your own projects - but you’re talking about a library that many people use… The code you’ve given ain’t generic in terms of design by any means)

Trust me, I have been in your exact position before for this MIDI output/graph stuff (I didn’t just fall off the turnip truck). Again, the reiterated solution I gave is the best one. Dismiss it if you wish, but only do it once you’ve tried it out. The code to achieve it is much easier than you think.

[oxxyyd]

OMFG! Horrendous! On so many levels! Damned hack! My particular scenario!?

I post my thoughts in a polite way in friendly forum and this is your reaction. Man you really know your Master suppression techniques! What’s your problem?

For starters, not only would you limit the AudioProcessorPlayer to one MIDI device (if there’s even one available), you’ve not given a means to tell which device MIDI gets sent to!

setMidiOutput(MidiOutpit *midiOutput)

This could be easily wrapped in a custom processor to have the result MIDI outputted to your desired MIDI device.

(Just a quick note: there’s nothing wrong with hashing quick solutions for doing small things in your own projects - but you’re talking about a library that many people use… The code you’ve given ain’t generic in terms of design by any means)

Oh I’ve spoiled the genericness for that many? By adding a single private member to a class? Sure they must be upset, no inheritance, can’t use it as a building block for their own creations anymore. “We won’t use it anymore! It’s not generic!” Instead they get - MidiOut! Without having to code a single wrapped custom processor. OMFG! Horrendous!

your particular scenario

Man, you even manage to my make my wish to have Midi out handled by the library look dubious. If you think this is a particular scenario - then I guess it’s particular for many. After all, this is a library known for its use in Audio applications. You make it sound that if you want something as odd as Midi out, you should code your own stuff. I see no harm in adding code to a library for things that is common for many users, not even for such particular scenarios as Midi out!

Trust me, I have been in your exact position before for this MIDI output/graph stuff (I didn’t just fall off the turnip truck). Again, the reiterated solution I gave is the best one. Dismiss it if you wish, but only do it once you’ve tried it out. The code to achieve it is much easier than you think.

Man you’ve really come a long way - You didn’t fall off the turnip truck and you have reiterated solutions you know is the best ones. But believe me - you don’t know what I think.