JUCE

In short, you can't use our version of Juce to build your externals. You need to use jgraphics as demonstrated in the SDK's examples. If you want to build externals with juice component you'll have to link it and include your Juce version.

I was more interested in trying to use JUCE to build my own VST external.

@Emmanuel, yes - wasn't thinking about using your version. What I was wondering was whether I can write all my stuff on Windows using Visual Studio, link in your libraries and a version of Juce and then just transport that onto a Mac and build the complete job lot on Xcode.

Obv this is possible, but wanted to know whether anyone had tried this and had experience of it? On the surface this seems a good solution for developing cross-platform externals, but there doesn't seem to be any noise about it so maybe I've got something wrong...

It's definitely possible to use juce to create your own gui components and insert them into Max. I do that a lot (developing many Ircam external objects, cross-platform).

This is relatively easy. Basically, you render your juce component into a juce::Graphics (cf Component::paintEntireComponent) Then you retrieve the raw bitmap data from the graphics context (cf Image::BitmapData::getPixelPointer) You create a Max image surface from the bitmap data (cf jgraphics_image_surface_create_for_data) Then you paint the image surface into the patcher (cf jgraphics_image_surface_draw)

This approach is not very efficient (you do all the job twice), but there are some alternatives.

This works for VST too.

I have most of those IRCAM externals, they're quite excellent.

Is there any chance you could provide a trivial working example for a vst?

I'm not looking to write gui components - I just want to be able to write some externals in C++ and build them for Windows and Mac in the easiest way from the same source code...

@NICOLAS ---- Thanks so much for the reference. Much appreciated.

Hi, I'm reviving this old post because I was wondering if anyone had some examples to share in this area—I guess something circulated in private messages... My goal here would be being able to open a separate window containing a Juce component, bypassing the Max API as much as possible.

I guess it can be done, and I hope it's not too complicated, but any help is welcome!

Cheers, andrea

Hi, wow, was this really that long ago??!

I have apps that are built with JUCE, wrapped in an external and just launched from inside Max, i.e. totally standalone with doing all their own GUI etc., and communication via the external object in Max.

Sounds like that's what you're after?

Hi Lee,

so, if I understand correctly, your externals are just launchers for the external application, and the two talk to each other through some inter-app communication system, right? This is a viable option, and if you feel like giving me more info about it that would be great, but ideally I'd like to embed a Juce-based object directly in my external, and being able to show it in a window of its own—does it make sense? Do you have any experience with this? I have to say, I used Juce some years ago for a couple specific projects, but I haven't looked into it since, so I guess my terminology and understanding of the framework are a bit rusty...

Thanks, andrea

— I mean, your externals are just launchers plus, of course, they manage the communication with Max—but the bulk of the work is outsourced to the standalone app, isn't it? a

The two talk together via inlets and outlets, just like any other Max object. The window for display is owned by the JUCE object and just displayed as an OS window.

i'm not at computer at moment but can show an example later

That would be awesome, thank you!

From the peanut gallery, not trying to help or anything. There was something in the old McGill mailing list from a million years ago which I remember vaguely.

The Evolution of a Max Programmer.

1. Use Max simply to do simple things 2. Use Max to do horrendously large and complicated things 3. Realise that you are going to have to drop to C for some of your work so you start putting things in externals 4. Max is basically a runtime for your gigantic C project 5. Use Max simply to do simple things.

Haha pretty much. Although there must be some magic combination for a standalone application that can also tap into Max and Max for Live APIs in ways that lead to incredible flexibility for users to adapt the app's behavior to their needs.

Right now the case I am imagining is data/audio visualization which if nothing else is highly dependent on what individual track elements lend themselves most to foreground visualization, whether they were made with MIDI or audio loops, how much automation you can grab versus modulations baked into the audio, etc etc ;-)

@andrea, so here's an example

inputs and outputs are sent to the object as with any normal object for processing - the 2 windows are JUCE windows managed by the external

How about a source code example?

Hi, i'll try and get some time next week to put a simple example together.

Rather old... but HTH < https://github.com/frantic0/Jojo >.

Hi, nice - I think that should be enough for people to get the idea.

Lee, Fud, thank you so much! I'm going to look into it and let you know! @Andrew: lol... I guess I'm between state 4 and 5 right now... and there's something quite radical about to happen in bach in this sense... ;)

Cheers, andrea

juce is like ... with only monthly subscription, it isn't cheap, and in my opinion, not a good buy formula. i hope than max stay like a purchase and with their purpose. why it's free for education ??...

You can BUY a license for JUCE, you don't have to buy it as a monthly subscription. You can buy it as a perpetual license. That's what we did for our audio plugin host, Gig Performer.

Also, JUCE is free for personal use. We started that way and then bought a license when it became clear we were going to sell a product.

there are pure data like fork...

... e.g. < https://github.com/Spaghettis/Spaghettis >.

come as you are..:) m4l & launch are correct

https://help.ableton.com/hc/en-us/articles/206240184-Creating-your-own-Control-Surface-script