Two requests

Hi Jules,

A couple of minor requests if I may for the next Juce update…? I’ve had to make these changes locally, it’d be good if you could do them at “Juce central” for future releases. :slight_smile:

  1. Patch juce_AudioDeviceManager.h to change from this:
#include "juce_MidiInput.h"

to this

#include "juce_MidiInput.h"
#include "juce_MidiOutput.h"
  1. Patch juce_AudioDeviceSelectorComponent.cpp to include support for (optional) selection of MIDI output device.

Neither are at all difficult to do, but it’ll save rework for me in every Juce update if you can do the above. Many thanks. :slight_smile:


BTW on the Mac I note that no MIDI output devices are shown by default, whereas I’d have hoped at least QTMI to be listed… :frowning:

MIDI was always a mess on Mac (remembering from the days when I first ported Koan to the Mac… ah, those nightmare days of yore!). I still shudder to think of it!


Ok, will do this when I get a chance. There’s probably a way of connecting up the QT midi renderer as a midi output, but I’ve never tried, TBH…

Hi Jules,

Just to note that this is proving essential as an approach to get MIDI data routed from an Audio Unit implementation. :slight_smile:

First-off, the user must enable their Mac’s IAC driver using the built-in “Audio MIDI Setup” application (normally this driver is disabled by default for some unknown reason!)

The Filter’s UI component needs to present the user with a list of available MIDI output devices (given the changes I outlined earlier in this thread, the IAC driver is listed automatically by Juce!). The MIDI effect AU needs to send its data via this output device/port. From an audio perspective, the AU “that is really a MIDI Effect” would otherwise simply pass-on silence, or passes-through the input audio data.

The MIDI data can then be rendered on another MIDI track in Logic by taking data from the MIDI input device presented as an IAC port. NB this approach would also allow a MIDI effect to be deployed as a VST on a Mac, even where the platform doesn’t support MIDI routing through VSTs (e.g. Cubase).

As an alternative rendering strategy, or if punters simply must play through Quick Time Musical Instruments :), punters don’t need to use the second MIDI track, but could instead use the free MidiPipe application by SubtleSoft, to route data from Midi In (presented as IAC Driver - Bus 1) and output through e.g. the DLS Synth.

Anyways, hoping this helps!


Wow - that’s a pretty convoluted way of getting the midi out… I guess it’s the only way though, with AUs not handling it.

The messy bit is how to handle the timing of the events that are being sent out. Your AU is geting callbacks with blocks of data at fairly jittery intervals, so it’ll have to be running a separate thread that’s buffering the output events and sending them to the midi output with a delay.

Yes, horrible isn’t it. :frowning:

Is that really how other plugins do it?

I can’t see any other way. :slight_smile:

The Audio Unit format doesn’t support MIDI Event generation from an Audio Unit plugin (as you know).

IAC is the built-in mechanism for routing MIDI events on the Mac.

So putting two and two together… :slight_smile: makes the proverbial four.

Anyways… clearly, I’m going to have to put this code in to our plugin implementation. It’d be good if this were actually in the base Juce Audio Unit adaptor implementation (where the filter specialisation had first enabled this by requesting of that base implementation to route emitted MIDI events through a named MIDI Output port/device), but until that time, I’ll just have to do that myself!

I should say that without Juce, this would be a complete world of hurt. :slight_smile: Juce certainly makes all this a lot easier!

I should probably write a MidiOutputThread class that you can shove events into. That’d help.

No kidding mate. :slight_smile:

I’ve been trying to avoid doing one of those for about 2 years. Will bump it up the list a bit…

Great stuff! I’ll be doing my own in the interim. Needs as must!!

Hi all,

Just thought I’d mention that to write the code that opens a named MIDI device, creates a GUI component with slider (controlling a metronome) and stop/start buttons, as well as creating a couple of threads to prepare and consume MIDI events managed by a critical section, only took a few hours work.

Tell your friends: doing “stuff” with Juce really is as easy as it gets. :slight_smile:

BTW, to do all this for Mac or Windows separately took me ageswhen I first did this sort of stuff (errr… 15+ years ago!). Sure, I know a lot more now than I did back then, but I keep finding that Juce is making things that should be easy, easy. If you see what I mean. :slight_smile:

Nice one Jules!


Pete - just an FYI that I’ve checked in some changes to MidiOutput that give it a background thread, so you can give it a queue of events to be sent out at specified timestamps… Probably very handy for your AU midi out endeavours.

(oh, and was it you that asked about focus order in the jucer? I’ve also just added an option for that, via a new method Component::setExplicitFocusOrder()).

Hi Jules,

Nice one Jules, I’ll take a look. The generative music product is coming on nicely now BTW. Thanks in no small part to Juce! :slight_smile:

Aha - nice one!!! Critical stuff for me, so I can’t wait to grab it and try it!!

I have a couple of focus-related problems right now in that I’m using the TableListBox to arrange components for editing various properties (saved a lot of time that, not having to write my own from scratch - nice one!).

The first issue is that I’d like ideally to have up/down cursor keys to move focus between components up/down from component to component within a column (where the components weren’t otherwise using the cursor up/down keys for their own ends). I wasn’t sure about the easiest way to handle this…?

On a related note, I need to ensure that as the user tabs-around between components, the tabbed-to component is moved automatically fully into view by having the TableListBox adjust its scrollbar position automatically to bring the focused cell fully into view.

Any bright ideas? :slight_smile:


Ok, I’ll have a think about the cursor keys…

As for the table, I guess you’d just catch the cell’s focusGained() callback and then use ListBox::scrollToEnsureRowIsOnscreen to make sure it’s showing.

Hi Jules,

Got you!

Sounds, however, like I need a new method:


?! Hoping this makes sense,


Try this:

[code]void TableListBox::scrollToEnsureColumnIsOnscreen (const int columnId)
ScrollBar* const scrollbar = getHorizontalScrollBar();

if (scrollbar != 0)
    const Rectangle pos (header->getColumnPosition (header->getIndexOfColumnId (columnId, true)));

    double x = scrollbar->getCurrentRangeStart();
    double w = scrollbar->getCurrentRangeSize();

    if (pos.getX() < x)
        x = pos.getX();
    else if (pos.getRight() > x + w)
        x += jmax (0.0, pos.getRight() - (x + w));

    scrollbar->setCurrentRangeStart (x);


Blimey Jules, you don’t hang about do you. :slight_smile:

BTW, as it doesn’t make sense while navigating a table for a column to not remain fully visible when the user moves there, are you going to put this auto-keep-cell-focused code into the core TableListBox implementation?

Toodle pip!


Well the core tablelistbox stuff doesn’t really have its own concept of where the user ‘is’, so not sure where I’d add it to make it happen automatically.