[IDEA] What about a Juce "port" ?

7 replies [Last post]
forart.it
User offline. Last seen 1 year 40 weeks ago. Offline
Joined: 2006-09-01
Posts:

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

seablade
User offline. Last seen 4 hours 4 min ago. Offline
Joined: 2007-01-22
Posts:

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.

Seablade

paul
paul's picture
User offline. Last seen 8 hours 42 min ago. Offline
Joined: 2006-03-16
Posts:

@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.

forart.it
User offline. Last seen 1 year 40 weeks ago. Offline
Joined: 2006-09-01
Posts:

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...

linuxdsp
linuxdsp's picture
User offline. Last seen 2 days 9 hours ago. Offline
Joined: 2009-02-04
Posts:

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)

paul
paul's picture
User offline. Last seen 8 hours 42 min ago. Offline
Joined: 2006-03-16
Posts:

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.

forart.it
User offline. Last seen 1 year 40 weeks ago. Offline
Joined: 2006-09-01
Posts:

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?

paul
paul's picture
User offline. Last seen 8 hours 42 min ago. Offline
Joined: 2006-03-16
Posts:

@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.