Ok, yet another version hits the shelves! Changes are:

  • new class: MidiBuffer - an efficient array of midi messages for use in audio filters
  • new class: MidiKeyboardComponent - a UI comp that shows a piano keyboard and has lots of groovy features
  • additions to DragAndDropContainer to allow files to be dragged to external applications
  • fix to Array::move()
  • added a couple of accessor methods to TreeViewItem
  • changed the colour selector component to make the alpha-channel optional
  • fixed a layout bug with some tooltips
  • fixes to the AIFF file format handler
  • efficiency improvements to the Timer class
  • add a Component::visibilityChanged() callback method
  • added file and line info to the internal exception handling code
  • linux window focus bugfix

And also the latest audio plugin wrapper stuff, for which you’ll need to get juce 1.21.

In the wrapper, I’ve now tested AUs much more thoroughly, on all the hosts I’ve had available and they seem to work pretty well…

Also, I’ve beefed up the demo plugin with a midi keyboard component that can send and receive midi events.


no breakages with existing code?

things have gone critical here getting the demo together. MidiBuffer sounds sweet.

The only thing that might break your code is that the audio plugin process method now takes a midibuffer instead of an array. It’s not a massive change unless you do a lot of midi event manipulation.

we have not done the plugin version yet so that’s not a problem. working on the standalone only. the plug version is just a toy/proof of concept. any improvements in the midi functionality are very welcome as we plan £%&£$£!^&$£%$£ able &*£%%^*£&(&%"%& to midi as a freebee! maybee!

God I hate NDAs!

That’s OK, because ********* ** **** ** squishy **** and then ***** *** *** very moist ***** *** **** *** Rod Stewart. Also, the ***** *** orange chocolate digestive ***** *** ** **** embarrassing!!!

Anyway, I’ll get around to compiling this stuff in a while and post an update on the plug bug thread.



I’ve just tried 1.21 and JAP 1.4, now it works on Logic Pro 7.

Composited window problem on AUVal was fixed! Wow! :smiley:

It works on Digital Performer 4.6 but there are some problem during resizing and redrawing problem with collapsing (mimizing) window.

I think the best way is not using window group, composited HIView instead. (I know there still be a lot of old architecture based VST/AU hosts though…)

To avoid warnings by using deprecated APIs (almost all QD utility APIs…) too.

What do you think about it?

And probably we need “parameter description” to cover AU specification. Defining on/off or indexed parameters as kAudioUnitParameterUnit_Generic causes problem when using control surfaces like microKONTROL and LogicControl. Defining the structure like:

typedef struct tagParamDesc { int iUnit; float fMin; float fMax; float fDefault; } SParamDesc;
and add methods to AudioFilterBase to retrieve the info.

And small suggestion for JAP demo AU plugin, why don’t you use
kAudioUnitType_MusicEffect instead of kAudioUnitType_Effect for its component type to receive MIDI messages?

Sorry for a lot of comments everytime, I’m very interested in this cool library. :smiley:

Best regards,
Masanao Hayashi
Korg Inc.

Does Digital Performer use AUs or VSTs? For AUs now, it doesn’t use a window group - it renders directly onto the host’s window. VSTs are still done with a window group. Don’t think I can bend the Juce architecture far enough for it to render to a HIView though.

Yeah, I was waiting until AUs were done before I decided how to beef up the parameter handling, because I wanted to make sure I chose a format that worked for VST and AUs. I’ll look into it soon.

Yes, good point about the AU type. I think I’d set it up that way at one point, must have changed it for testing purposes and forgotten to put it back. It should probably be a MusicEffect, like you say.

I’m so sorry, I thought it still uses window group. :oops:

Digital Performer supports AUs, not VSTs. DP uses window group for AU plugins. (I checked it by QuartzDebug.) The important problem should be fixed is, when I collapse the plugin window, the plugin area of the window is filled with white color and when I restore the window, it is still white, not redrawn.


Best regards,
Masanao Hayashi
Korg Inc.

Hey Jules, the demo plugin’s type is still kAudioUnitType_Effect and not kAudioUnitType_MusicEffect.
Simply changing it to kAudioUnitType_MusicEffect (https://github.com/yairchu/JUCE/commit/96c0b419b75d91a8f6a7a33918530a936a45644a) makes it work as a MIDI controlled effect in Logic, and also doesn’t seem to break Logic sessions using the demo plugin as an effect even though its type changed.

It would also be nice if plugins which want MIDI inputs would default to being kAudioUnitType_MusicEffect (https://github.com/yairchu/JUCE/commit/afef714782cdb339a80c1264fe75ea6661db429d)

Cheers! Yair

But it does seem to break AU Lab sessions :frowning:
I hope most hosts behave like Logic and not like AU Lab (because I want to add MIDI controls to an existing plugin), I guess we’ll find out…

I can’t really see the need to change that in the introjucer - if you need to tweak that string, you can do so by changing it in your project settings, right? I’d rather make the introjucer use a safe value by default, and let you override it yourself if you want.

Currently it’s one more step that developers need to do to add MIDI controls to their plugins.
Also, if they mostly test on PT or a VST host, they might not notice that they’re missing this step for AU… So they may only discover they’re missing something at a late stage.
This value seems safe to me.

But you just said it makes AU Lab fail…

Here’s how AU Lab fails:

[] Create a plugin with the default type[/]
[] Create a session in AU Lab using this plugin and save this session[/]
[] Close AU Lab[/]
[] Change the plugin’s type to kAudioUnitType_MusicEffect (or any other type)[/]
[] Open AU Lab and load the previously saved session. It would not succeed loading it because it can’t find the plugin (it expects it to have the previous type)[/][/list]

So this only affect backwards compatibility (although any existing MIDI controlled effect should already have the kAudioUnitType_MusicEffect AU type, so I don’t expect this change to really break anything)
Cheers, Yair

Ah… Ok, in that case, it does make sense, thanks!