On Thu, Jul 22, 2010 at 11:53 AM, Johnny Ferguson
<address@hidden> wrote:
On 07/22/2010 05:19 AM, rosea grammostola wrote:
<mailto:
address@hidden>> wrote:
On 07/21/2010 05:24 PM, Bernardo Barros wrote:
> They can still make money with GPL. Yes, they are not going to do
that.
<rant>
I think it's far too easy to make a statement like "They can still
make money with GPL" especially in light of the fact that there
ISN'T a GPL equivalent to FL.
I think you're right when you state this. The best example is Ardour,
they can make a living, but it's not easy. There is LMMS btw.
Ardour is not a proper DAW in the modern sense. It doesn't let me (for example) drag a softsynth onto a track and start programming it with midi data. As a multitrack recorder, It works fine. I wouldn't call it a DAW though (at least not in the modern sense of the word).
Ardour 2 doesn't have MIDI editing functionality. Ardour 3 has, a beta release should be out soon.
Also, I'll just pretend you didn't say LMMS. Not that I'm ungrateful for their trying, but it's just not FL in any way, shape, or form. Developers need to stop creating low quality clones, and begin their projects with notions of what makes the programs they want to emulate so great in the first place. Again, both being an artist and being a programmer are heavy specializations. I'm not surprised that you don't find many hybrids posessing both skills who want to commit their efforts for little compensation.
I didn't say I like LMMS, I don't like it, cause it lacks proper JACK support for instance. I prefer Qtractor and Renoise in that scope.
I do know how to use JACK, but it's a bit of a pain to manage configurations. In a program like FL, configuration is saved as part of the project file, as far as I've seen with JACK, the usefulness of multiple programs being linked together is negated by the fact that the configuration has to be managed separately. And one may argue that the same thing is true of FL using rewire, but because FL does almost everything you could need, I find the argument irrelevant. This is in stark contrast with the "small, simple, modular" philosophy I find in linux audio software. While better in the long run, it has some shortcomings in the present.
That is: instead of loading one program and opening a single project file, I have to load up JACK, load up all the programs involved in the project, load all the project files for each program, then finally load the JACK configuration for everything else that's open.
If I'm wrong on this point, please let me know. I hope I'm wrong, but if I am, then I think JACK could use some better documentation. If I'm right, then JACK needs some kind of complementary application that has some notion of "project workspace". Within such a space various programs would be opened in a given manner and then linked when ready.
The closest I came to that was writing a bash script that would open up QSynth, call sleep for a few seconds, then load up jack and connect everything up to my midi keyboard. I don't want to write a bash script every time I start a new project. While I appreciate that functionality, I don't think that's what will make people prefer a system like JACK.
That's a fair argument. I'd actually never heard of QTractor, and I'll be checking it out in the next few days. Looks similar to sonar, and from screenshots I think I see some kind of JACK integration which looks intriguing.
I don't like the idea that the faults of JACK are that people aren't willing to learn some kind of specialized rocket science though. JACK on a conceptual level is quite simple, but if it requires more than a day of study to use effectively, it's probably too complicated. I'd argue that it is JACK that needs to learn to work with musicians, not the other way around.
Granted, it's fun for fooling around with, but as it lacks a sense of "project awareness" (as far as I've seen), I've never used it for anything serious (except perhaps sample making via ZynAddSubFX and JACK-Rack)