Rename project?

[nick-thompson]

Someone sent me a link to this recently: https://blueprintjs.com/

Turns out "React" + "Blueprint" is already a thing... might be time to come up with a new name for this project!

[teotigraphix]

Blueprint++ ;-)

[nick-thompson]

Thinking about this again the past few days. When I think about the React ecosystem, there's a pretty consistent naming pattern for rendering backends: react-dom, react-native, react-art, react-native-desktop, react-native-windows, proton-native, etc.

In truth, Blueprint is just another rendering backend, it just happens to target native C++/JUCE to provide a react-based approach to writing audio apps/plugins. So perhaps we should follow the pattern?

Going down that road, I think the primary features of this particular rendering backend are:

• Cross-platform
• Native C++
• Audio-focused

The obvious name is react-juce, but the way blueprint is written there's nothing really tying us to JUCE itself. For example, we could very likely support targeting iPlug2 or JUCE. For that reason, I hesitate on react-juce and instead think we should lean towards the primary feature list up there.

A couple other name ideas:

• React XPN, react-xpn – React for Cross(X)-Platform Native
• React XPA, react-xpa – React for Cross(X)-Platform Audio
• React C++, react-cpp – React for C++
  • I don't love this one because it's not exactly generic C++ that we're targeting...

I'm curious to hear anyone's input!

[JoshMarler]

Heh. Yeah, tricky one.

Is there a real desire to support targets other than JUCE? I really like react-juce and that would have been my (pretty obvious) suggestion also.

Depends on where you want to draw the line with this framework I guess. Will Blueprint (or whatever it becomes) ever want to go beyond JUCE? If the purpose of the framework is something along the lines of "React based UI's for Cross Platform Audio Applications" is there a compelling reason for it not to exclusively target JUCE ?

I understand the reasons one might wish to target other cross-platform audio frameworks but do we reeeeaaaaly want to?

Could be a brave new world of:

  createViewInstance(viewType, props, parentInstance) {                                                                                                                                                            
    const id = __ReactJuceNative__.createViewInstance(viewType);                                                                                                                                                   
    const instance = new ViewInstance(id, viewType, props);                                                                                                                                                        

    __viewRegistry[id] = instance;                                                                                                                                                                                 
    return instance;                                                                                                                                                                                               
  }, 

Of course that's my own selfish desire because I don't use anything else :-) I just want JUCE to get super powers.

[nick-thompson]

Good question :)

In the short term, yea we'll be pretty much exclusively targeting JUCE, and if we're successful with this project it will in large part be due to seamless compatibility with JUCE. But in the long term, the path to supporting another backend system like iPlug2 I think is actually quite feasible, so my gut feeling is to stay open to that possibility.

For example, I could imagine something as simple as this, as far as the user is concerned:

ReactApplicationRoot<Backends::iPlug2> appRoot;
ReactApplicationRoot<Backends::JUCE> appRoot;

I have another long term vision which is to be able to ship a Blueprint frontend to the web (think write 1 React application, then run it in the browser or run it natively in a daw plugin). All of these things are way far off, but my initial thought is to leave the door open for it, both in how we write code currently (unless it adds too much complexity), and, I suppose, in how we name it. Is that crazy? 😁 I'm definitely open to discussion

[JoshMarler]

Nope. Can't argue with that Nick, writing a browser based UI for the world of WebAssembly/WebAudio/SOUL and the like is certainly compelling. Who knows what the future will bring.

With that in mind .... What about react-xpaudio ? Or does that suggest there is some JS audio layer ...

Feels more explicit than xpa ?

[nick-thompson]

With that in mind .... What about react-xpaudio ? Or does that suggest there is some JS audio layer ...

Yea I like that, react-xpaudio. I've had that exact same thought about the js audio layer implication.. maybe it's no problem?

[JoshMarler]

There are only 2 hard things in computer science ...

I rather like the name react-xpaudio. For me it's no issue .... heh. Big red disclaimer in the API docs?

[nick-thompson]

I'm with you on that! Let's let this sit for a few days in case anybody else sees this thread and wants to chime in.

After that, we'll use this issue to track the work that needs to be done to carry out the rename 🚀

[nick-thompson]

Okayyy https://github.com/nick-thompson/blueprint/pull/216 has just gone in, which means the only changes left here are primarily in the documentation and the repo name itself. Almost there!

[nick-thompson]

Wow, done, finally! Long live react-juce