MidiFilter template project

Oh, I didn’t even know they did a separate midi-effect api. Is it completely different from VST?

Yep, 'fraid so! :slight_smile:

For those who are interested - surely not only me! :slight_smile: - Jules has given me this tip about how I might start to get a “pure MIDI” plugin working as a e.g. DXi/MFC or VST Module Architecture MIDI Effect…

The best place to look is probably at the way it’s currently done for
VSTs - that’s in juce_VstWrapper.cpp. Not the most elegant or
well-commented thing I’ve ever written, but around line 950 you can see
where it attaches the juce window to the host’s parent window, and
there’s other code in there to keep it in the right place, etc. The rtas
and AU wrappers obviously have similar code in them to do the equivalent
thing.
<<<

I’ll be investigating this in a few days, I hope!

Have fun folks!

Pete

Has anybody tried building code using the VST Module Architecture SDK?

Somebody put in conflicting definitions of the PluginGUIEditor class in these two files, no doubt for comic effect:

C:\VSTModuleArchitectureSDK\public.sdk\source\common\plugguieditor.h

C:\vstsdk2.4\vstgui.sf\vstgui\plugguieditor.h

The upshot is that I’ve wasted ages trying to build, when I should have been building using the VST SDK 2.3 (which actually works) … avoid this problem if you can folks, learn from my painful mistakes! :frowning:

Pete

eesshh…

Feel for me - I’m suffering with this. :slight_smile:

Good news: am now at stage of having the plugin build, linked-in to Juce, and am trying to attach a Juce UI to the MIDI Effect…

I’ll post progress to this forum, I’m determined to crack it and (in due course) contribute the code back into the main Juce SDK…!

Nice one.

Hi Folks,

Right, I have a basic MIDI Effect plugin, with Juce GUI stuff displayed in the pop-up window.

However, the items in the Juce component don’t display quite right.

e.g. the Button shows, but the text within doesn’t; and the group box lines are drawn, but the text for the group box doesn’t display.

Any ideas as to the sort of thing I might have done wrong? I’m sure at least one of you (Jules?) will have seen something like this in the past and can give me a helpful pointer … I hope! :slight_smile:

Pete

Sounds very bizarre - for that to happen, there’d have to be something wrong with the internal font rendering, but that’s mostly done in software, and I can’t think why it would be affected by the fact that it’s a plugin. Is it just fonts? Any other clues? A screenshot?

Hi Jules, I can’t figure-out how to insert an image :slight_smile: so I’ll mail it to you. :slight_smile:

Probably some sort of memory corruption, I’d suppose…?

Hi all,

OK, after a good night’s sleep I’ve woken and got this sorted.

The problems where … yes noddy errors I know, but in the interests of sharing… :slight_smile:

  • I wa linking in both release and debug Juce libraries (I was tired, OK!)
    This meant that I was picking-up the release library by mistake,
    and therefore missing-out on a load of juce assertions, which
    (having linked-in the debug Juce library) let me figure out that…
  • … my calls to initialiseJuce_GUI etc. on library load/release were
    being missed. Easy fix!

All now displays nicely!

Question: how do I force my Juce-based plugin editor (win32 at the moment) to be resizeable? Can’t figure-out how to add resize-capability to the window at the moment, and couldn’t see anything obvious in Jules’ meta-tastic other plugin adaptor implementations. :slight_smile:

Pete

Glad you figured it out.

To make it resizable, you’d add a ResizableCornerComponent or ResizableBorderComponent to the plugin’s UI, like I do in the demo plugin. That’ll resize the component itself, but your wrapper code will need to respond to changes in the component’s size by doing whatever’s needed to its host window to keep them in sync. That can be a bit messy because hosts all handle resizing differently, but if you check out how the VST code does this, I’d expect pretty much the same thing to work in your case.

Nice one Jules, I’ll give that a try. :slight_smile:

Right, that was a pig to figure out … partially. Resizing now works using ResizableCornerComponent, but I can’t get the intial window size to be “whatever I want”, I currently have to force it to match the size defined in some internal XML data specific to the VST Module Architecture SDK.

Basically, the VST Module SDK allows plugins to be built as either VST GUI (with XML layout describing editor window size etc. … using an inteface called IViewFactory), or as a “write your own” UI (using IEditorFactory)

Unforunately :slight_smile: they have written the CMidiEffect class to rely on the IViewFactory. This doesn’t seem to be a big problem (in the CMidiEffect case, the initial size defined using simple XML bound-in to the DLL; whereas if I were able to build using IEditorFactory, I’d be able to use a method to define my default size dynamically).

Anyways: if I try to resize the component in my Editor component’s constructor, to the size I want (e.g. to match last window size) this doesn’t work right; my component area simply doesn’t end-up matching the host window component size (and I might not even see the ResizableCornerComponent if the .xml data makes the initial window too small).

But once the editor is created, and assuming I can see the ResizableCornerComponent (i.e. by making sure the component minimum bounds match those in the xml data), then the ResizableCornerComponent does work exactly right. This is confusing. Oh well!

Very puzzling! Only solution for now is to have the intial size in my editor component constructor, match the value that I know is in the XML data. :frowning:

Bah humbug. :slight_smile:

Pete

Maybe when it’s created, kick off a timer that will resize it a few milliseconds later? Or resize it the first time it gets painted?

Or is there a way of supplying the xml programatically? Then you could just set the appropriate values before giving it to the host?

Hi Jules,

Both good ideas, that I’d also considered … :slight_smile:

I’m cracking-on with DXi/MFX implementation, and will revisit the resizing in a few days. Thanks for the tips!!

FWIW, the new “core” adaptor files are going here:
VST Module Architecture SDK MIDI Effect adaptor:
juce\extras\audio plugins\wrapper\formats\VST_MIDI_Effect\juce_Vst_MIDI_Effect_Wrapper.cpp

DXi/MFX MIDI Effect adaptor:
juce\extras\audio plugins\wrapper\formats\DXi_MFX_Midi_Effect\juce_DXi_MFX_MIDI_Effect_Wrapper.cpp

There’re be some other files too.

I’ll get them to you in a few weeks when they’re all nice and tidy :slight_smile: … still lots of work for me to do on them.

Pete

Great. Don’t feel like it has to be perfect before you send me anything - I’m sad enough that I actually quite enjoy going through code and tidying it up…

Same here. :slight_smile:

Really?

Going through other peoples code[1] is the thing that most reminds me that I chose the wrong career path. :frowning:

[1] to be fair, in my case “other peoples code” normally means F77, way too many gotos, globals, and obscure data structures that exist purely to shave a single byte off of a 200 byte datablock, but even so…