I know that someone already talked about Juce here… btw I honestly don’t know if possible at all: since I’ve discovered ChaoticDAW (that looks quite “familiar” to Ardour -> http://chaoticdaw.com/features.html) but isn’t unfortunally yet released as open source, I thinked that an OFFICIAL collaboration - at least - could certainly benefit both projects.
Juce website: http://www.rawmaterialsoftware.com/juce.php
@forart.it: i think you’re pretty confused about what developers do and how development works. first of all, yes, the separation of GUI and backend has been “best practice” in GUI development for more than 20 years. its not suprising that other DAWs do this, because lots of software works this way.
i never claimed that you could not build a cross-platform DAW with JUCE. that was never an issue. the question is: if you already HAVE a cross-platform DAW (like Ardour) what would you gain by “porting” it to JUCE? the answer is close to zero, on balance. any experienced developer will tell you that every toolkit has its own plusses and minuses, and that you can (almost) never switch to a different one without losing something in exchange for what you gain.
The functionality that a DAW needs in a “backend” library depend HUGELY on many basic assumptions about how the DAW will function and what it will do. The core internals of Abelton Live don’t look anything like Ardour’s, and neither of them look anything like SuperCollider internals either. You could probably find a way to force any of these 3 programs to do 90% or more of what you want, and yet they don’t share any basic design assumptions in common because their anticipated workflows and central capabilities are different.
You also seem to have the idea that there are a lot of developers out there who would work on such a thing and then use it in other projects. I can’t prove it, but I believe that you’re totally wrong about this. There are hardly any developers working on open source DAWs at all.
OK, I launched the discussion @ JUCE forums too: http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=9532
According to masshacker “you can certainly build a cross-platform daw with JUCE”.
…and here’s what Traverso website says about libraries:
Traverso consists of a number of libraries, most notably the audio backend, which abstracts the audio card and drivers (currently ALSA, PortAudio and Jack) away, and is a very re-usable implementation!
The core logic of Traverso is put into the core library, and is fully separated from the GUI by using the Qt signal/slot extension. Although the core library of Traverso isn’t API stable, it’s very easy to create a (GUI) frontend for it, since the core uses an ‘event’ based approach. The frontend only has to catch those events to update itself!
The validity of this framework has allready been proven by porting the TrackView ‘Canvas’ to the Qt GraphicsView framework, which was very easy, and basically a rewrite of the Canvas painting, without touching any core logic code!
If i’m not stupid at all, this means that many DAW-devs (Ardour’s too) already thinked to separate functions from GUI.
The idea is: why don’t put these functions into an “external” library - not necessarily Juce - to simplify their implementation and encourage their development?
OK, I try to be more clear: what about moving Ardour _functionalities_ (not gui) INTO Juce ?
JUCE is primarily a GUI toolkit, therefore, what would be the point in moving functionalities which are not GUI related into JUCE?
In my limited experience of working with bits of the ardour code, it seems very well separated into a ‘model, view, controller’ architecture, which means that ardour’s GUI, is already largely separated from the ‘other’ functionality. As Paul mentioned, porting the GUI code to another toolkit is a huge undertaking - the GUI may well be separated from e.g. the DSP etc but the GUI itself is often a far larger proportion of the actual application. (The same can be said of plugins… typically 10% of the time taken to port to another platform is the DSP, the rest is GUI code)
the only bits of JUCE we would use in the backend of Ardour are stuff that we already have JACK for. functionality like editing, streaming to disk, automation are not handled by JUCE in a way that makes it shareable across DAWs.
maybe its a noble dream to think of all DAWs sharing some common code-base, but its not going to happen. the basic data structures and data flow used by a program like Abelton Live are very different from the ones in use by Ardour, and they are also very different from what a program like PureData or Reaktor would use.
JUCE has a lot more to offer plugin authors than it does DAW host authors.
OK, I try to be more clear: what about moving Ardour functionalities (not gui) INTO Juce ?
In this way other projects can exploit and hopefully mantain/optimize/contribute to it .
What’s the benefit ?
Well, if one day all open daws will share the same function-library all will take advantage of its upgrades.
Of course, you can start your own side-project (or join other like Openlibraries -> http://sourceforge.net/projects/openlibraries/ for example), bus seems that Juce is becoming more and more popular, so…
If ChaoticDAW is written completely with Juce, what you are asking about is rewriting almost all of Ardour to ‘port’ it. That isn’t a port, that is a complete new piece of software.
There isn’t much collaboration that could go on there for many reasons, not the least of which is ChaoticDAW according to you isn’t open source. Even if it is released as open source the license used could prevent the use of much of Ardour’s code that links to GPL libs.
Ardour’s code being open source they are welcome to look at how things were done in Ardour, but may have to reimplement it in their own way depending on the license they pick.
@forart.it: more than 75% of Ardour’s code is in the GUI. switching to use any other GUI toolkit than the one we use is essentially equivalent to a complete rewrite. and what would be gained? our current toolkit runs on linux, os x and windows (as does Ardour). this all seems like a very strange idea.
Although this post is pretty old, I think that forart.it made a good suggestion.
And it seems that those who replied didnt’ well understand the JUCE concept. JUCE is not about building GUI. It’s about using a common C++ code that can subsequently run on multiple platforms, such as Mac, Linux, PC (windows), iOS, Android. So the very nice work that has been done for Armour could be implemented on tablets and other platforms.
Ain’t that worth a consideration ?
Actually you would be surprised how well some of those that replied do know Juce:) I would suggest you don’t understand exactly what was said in the replies, and how much work vs benefit would be involved in any of the above, vs the current solutions. Particularly when dealing with Non-GUI stuff, there is almost no benefit at all to ‘porting’ to Juce, and quite possibly some serious detractions, but at least a significant amount of work for no benefit.
In the GUI section, which is where a port to Juce would be most beneficial, you are literally talking about a rewrite. and since these posts I owuld venture a guess that we are closer to 90% of Ardour’s code being GUI related, but have not checked and pulled that number almost out of my arse:) So you literally are talking about a rewrite of Ardour at that point, and all that was said above still applies.
Oh and for the record, Ardour already runs on Mac, Linux, and Windows, in some fashion (How well is another topic) and would require a vastly different UI to focus on touch centered design workflows that you find on iOS and Android.