We built an Adobe Illustrator to JUCE transpiler

Hello fellow JUCE devs! I want to share something that we’ve built - we think some of you might find it interesting.

We’re calling it the GINnJUCE transpiler. It’s a transpiler that will convert Adobe Illustrator mockups into customizable JUCE::Component code.

In short, it will convert sketches like this:

Into code that looks like this:

So far it’s been a life saver for EQIP. When we first started off using JUCE, we spent weeks trying to learn the GUI classes just to implement our minimalistic design in code. Now that we’re using GINnJUCE, we’re able to manufacture complex GUIs on a daily basis, speeding up our rapid prototyping process. The code that it generates is human-readable and fully customizable, so by adding just a few lines of code we’re able to connect our GUI components to our audio engine. We’ve been able to adjust our GUI to our beta testers’ suggestions at lightning pace.

Just to be clear - the generated code isn’t intended to be a finished product, it’s simply a jumping-off point! For example, if you want your GUI to be responsive to window size you’ll need to modify the resized() function for the generated Components.

We’ve decided to offer GINnJUCE to other developers. If you or your organization is interested in purchasing a license, please don’t hesitate to comment here or send me a private message. If you’re not interested in purchasing a license, we’re also offering our services - send us a mockup and we’ll generate the code for you.

Current features:

  • Generates headers and cpp files for each Group in Illustrator
  • Creates a hierarchical Component structure for nested Groups
  • Generates Paths, Text, Images, and Paths with image FillTypes

Planned features:

  • GUI for setting up ChangeBroadcasters and ChangeListeners
  • Allowing for multiple constructors
  • Gradient fills for Paths

This looks like it could be game changer! Thanks for sharing…

1 Like

So, does this remove the need for the whole “SVG import” thing ProJucer has? Export SVGs from Illustrator/vector graphics program, import into ProJucer, copy generated C++ into your project…

Interesting approach. But it is really only drawing code. What happens to the Components functionality? You will rewrite them, just to get automatic drawing code generation?

This code has potential, if the drawing code wouldn’t go into dumb components, but rather create a LookAndFeel, that get’s populated with the drawing code?

I wouldn’t give up the Components functionality like the glue between processing and gui, like the ValueTreeState::Attachments etc.

But keep us updated, I am curious, where you are heading :slight_smile:
Thanks for sharing

1 Like

Right now it doesn’t support SVGs in your Illustrator document, but that’s definitely something we have our eyes on. There are 15 types of items you can place in an illustrator document, and for now we’e implemented transpilation of the most useful types: text, images, shapes, etc.

Hey daniel! Thanks for the feedback - You bring up a good point about improving the output by creating a LookAndFeel that handles the drawing code. If you don’t mind, I’d like to message you to get your thoughts about it - I want to make sure that our generated code is as useful to the community as possible.

But yeah, we’re definitely designing this tool so that the GUI can be separated from processing. We’re planning on setting up each component as a ChangeBroadcaster that modifies a ValueTree

Sure, anytime, I’m very curious. I love the plan to have the designers with their tools closer in the production process.
As you might or might not know, I created a layout engine almost two years ago, available on github (ffLayouts). It takes care of the placement and is defined via XML. I didn’t finish the editor, so you still have to write XML.
If you think you want to mix the placement engine with your drawing/design engine, let me know. I would love to contribute this to get a more user friendly approach out of it.

That’s understandable, but again, you cut your code off from any development that JUCE did for the components. I wouldn’t underestimate that.
The user would then have to write the glue between this ValueTree and the AudioProcessorValueTree, that already exists as Attachments, etc.

If you find a way to add the information, what component the designer is designing, you could generate the LokAndFeelMethods in the component.

e.g. to have a Slider designed, create these methods: Slider::LookAndFeelMethods and you are set to have an Illustrator designed Slider to be used like any other slider in the code.

But what I like about your approach, that the designer can populate the non interactive space very easily. Also that you can create Mockups in illustrator and turn it into real code very easily, that’s definitely the future!

Hi Adam,

Can you explain the approach how you have achieved this, Or if the source code is available on git to refer please point to that.