Site navigation

Big new project: audio plugin host

General JUCE discussion
#1

Ok chaps, I’ve just checked in a pile of exciting new code that I’ve been tinkering with for a while - it’s a set of classes for loading and hosting plugins (just VSTs so far, but the architecture’s in place to support multiple formats).

To test it, it’s done as a quick mini-host app that lets you splat a few VSTs on the screen and join them up.

Interesting points to note are that the host shares the same AudioFilterBase class that’s used when you’re writing plugins, so in theory you could compile a juce-based plugin directly into this hosting code and the two bits would match.

I’ve also done some really neat classes for managing the list of known plugins, and scanning for new ones, handling all the tricky cases of plugins crashing, (probably better than any proper host does it currently).

Yes, I know kraken beat me to it with his (much more feature-rich) JOST host, but that’s linux, and I wanted to build something to take advantage of my experience getting VSTs running on the Mac and win32. Might be interesting to merge some of kraken’s plugin format code into this eventually, as he’s got similar classes for handling LADSPA and DSSI.

This is a very early version, so there are loads of things missing/unfinished. If you want to have a play around, what I’d be interested in hearing about are any VST compatibility problems you might hit (and preferably a description of how to fix them!) What I don’t want to hear are any requests for extra host functionality, because that’s absolutely not my focus yet - I wrote the host code in just one day, as a testbed, and that’s the sort of stage it’s currently at!

#2

This looks very interesting. I gave it a quick try on the mac and I noticed a few drawing issues with some plugins that I’ve been struggling to get working correctly in my host. I took a quick look at the code and noticed that a HiView is always used for the plugin window. Is there any plan to support pre vst 2.4 plugins?

In future, if it supported AU, RTAS & DX plugins, that would be very useful to me.

Anyway, I’ll be interested to see how this develops. I’ve got some projects ideas that this could be very useful for.

#3

It does handle all kinds of non-HIView plugins too, either the ones which draw directly onto the window, or those that pop up their own window. The troublesome ones are the ones where they’ve done a hack job of it and made assumptions. Hopefully with this being open-source, there’s a chance that the authors of the dodgy plugins could be persuaded to have a look themselves and sort it out.

AU and DX in the future - probably (any volunteers to write them?) RTAS - no chance, that’d be illegal, I’m afraid (and too damn hard anyway).

yes, I can think of one obvious place that this could be useful.

#4

EXCITING! :wink:

I got it to compile and run after downloading and installing the vstsdk. It loads my plugins just fine. But how does it work? I connected the audio inputs to the inputs of the effect and the outputs of the effect to the Audio Output. I tried playing the piano but nothing … connecting the audio inputs directly to the audio outputs does not help either.

#5

Did you connect the midi input too?

#6

yes i did, to the plugin midi input, i also got a crash when i changed the buffer size in the audio preferences. I do not see any midi input options in the preferences either.

#7

Well it’s work in progress… I’ll be checking in some updates soon.

#8

Just my luck to be on holiday when all this exciting stuff is happening!!! :slight_smile:

Really looking forward to help you sort this out!!

Pete

#9

Hi Jules,

Wondering if you had any more info on how this is going? :slight_smile:

FWIW, I’m looking forward to the time when our apps/plugins can host VST or AU synths. That would help deal with the grotty MIDI plugin support in Logic! :slight_smile:

Pete

#10

I’ve been doing some other stuff this week, so haven’t added anything new.

AU support is on my agenda - (it actually doesn’t look too difficult, certainly easier than doing VSTs). Might get the current version out as a proper release first though, and should probably add some transport functionality too.

#11

Awesome. :slight_smile:

#12

Sounds great! Looking forward to a first release with AU support.

#13

nice stuff Jules, indeed. jost and your host have a lot of things in common (looking at the code), and we basically wrote the same thing twice.
In some parts i see clearly your wizard touch, and the overall complexity is generally low.

For example the Plugin Format/Instance classes make things easier to add and maintain; also the plugin scanning, sorting classes does very good the job (probably i’ll take some ideas from that, even if i generally prefer the idea of bookmarking what i need instead of adding tons of stuff without even remember what plugins you have).

Other things are quite less complex and modular (but that’s not a critic, since i know well this has been concepted in a day): especially the Graph part is there only for serving the need of the plugins: in my vision, i have divided the “core” from the “framework”, so i still have a simple filter graph that will let me attach plugins togheter, but i have also a set of components that let me use the Graph visually for any other purpose (even not audio), written in the form of any other juce control but external to the “audio plugin” world.

anyway i think something should be done with this and jost, someone should work on this and improve it constantly (as i’m trying to do).
hey Jules, again you done it :slight_smile: i hope we will end doing the same things over again :smiley: better to work in two on different part of the same thing…

what about divide the pure hosting part from the “complete host application” ? this way i can share the same codebase, while still build a different host following my own new ideas and stuff…

Anyway, i’ll try to give help on this.

#14

Thanks! One thing I’m going to do next is to move the AudioFilterBase class into juce itself (and probably change its name to something like “AudioProcessor”), so that it’s a core part of the library’s audio classes. This could then turn into a more powerful replacement for the AudioNode classes, where all the existing node types are implemented as these new objects and can be tied together and played as a graph.

Later I might move the actual plugin loader code into the main juce tree too, but will get a new release out before I worry about that. I’m working on some other stuff this week, but hopefully will get back to this soon.

#15

that is one of the things i would like to see soon. the pure processing node should be standardized. you don’t have to worry about the classtype of a “AudioNode” (an internal/externally loaded plugin, and audio source, a positionable mixer), and make a wrapper for letting it to be used in your signal flow classes cause they are different: you just create some nodes that process data in blocks, and wire them togheter. some of them can respond to changes in transport (like a sequencer module), some others won’t do anything on a transport change (like a delay plugin) but you can still interconnect them together-

in my vision, juce should contains these kind of utilities:

  1. a specialized graph container for audio nodes with different input/output types (audio/midi/spectrum/…) with all the utilities to reorder the graph, connect nodes, calculate the processing order, etc.
  2. a set of node classes in the form of (AudioFilterBase + PositionableAudioSource) = AudioProcessor
  3. a set of classes for scanning, bookmarking, sorting, loading and indexing one or more “unspecified” format of files, which then can be specialized to let it load plugins.

what about make an AudioProcessor a PositionableAudioSource (or maybe standardize the other way round) ? so we can mix resamplers, sample players , plugins, mixers and so on and attach them in a graph controlled by the TransportAudioSource ?

that is the way i would concept a pure flexible set of audio classes.

take your time, it’s always a pleasure to look at your efforts :slight_smile:

#16

This looks really interesting.

#17

I finally got around to checking this out…
I’m on a pretty fresh Windows XP machine, with no VSTs other than a free bundle (the MDA suite) and the plugs that ship with Tracktion2.

A bit surprisingly, the Mackie plugins don’t load…
Process::getProcedureEntryPoint (hModule, “main”)
is returning 0…

Am I missing something obvious? Is the host designed to only load a certain version of VST (ie. 2.4 & > ) or ?

(MDA plugs seem to load fine)

Thanks.

#18

The mackie plugins only work in Tracktion

#19

Ahhh, gotcha.

Thanks.

#20

any chance to get my linux changes (and project files) checked in ?

i’ve just deleted all and done a clean checkout of the repository, so you’ll the only one that have them (or maybe in my sent mail folder…)