On 07/22/2010 06:57 AM, rosea grammostola wrote:
On Thu, Jul 22, 2010 at 11:53 AM, Johnny Ferguson <hyperfle...@gmail.com
<mailto:hyperfle...@gmail.com>> wrote:
On 07/22/2010 05:19 AM, rosea grammostola wrote:
On Thu, Jul 22, 2010 at 9:59 AM, Johnny Ferguson
<hyperfle...@gmail.com <mailto:hyperfle...@gmail.com>
<mailto:hyperfle...@gmail.com <mailto:hyperfle...@gmail.com>>>
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.
soon. It's always "soon" :P. Though I would be interested to see it in
action. From what I remember, it's been a long time coming for the MIDI.
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.
You're right, all though the JACK and modular infrastructure gives you
very many creative and technical possibilities, the main drawback is
session management. You can make your bash scripts and there are some
other scripting tools made for that, but it is not ideal (for everybody)...
BUT there are developments here: check www.ladish.org
<http://www.ladish.org> for instance.
There is also Jacksession now, integrated in JACK:
http://trac.jackaudio.org/wiki/WalkThrough/Dev/JackSession
http://svn.fuzzle.org/jsweeper/trunk/
Thanks for the links, I'll be sure to give them a look when I get some
free time. Good to know the problem has been acknowledged.
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)
I see this from a different perspective. The commercial apps do
everything to get and keep customers as much as possible. That means
also, make it easy!
I don't mean easy in the sense that the program does the work for you, I
mean easy in the sense that you can be efficient in your work while
maintaining functionality and control.
I'm not saying a good program will make you brilliant with FM synthesis
in a day, or teach you the meaning of ADSR, or compression, or stereo
separation, etc., but something like linking modules together should be
easy (even if you don't understand how they work). And once its easy to
link your modules together, it should be easy to make the connection
states persistent (because we all have to close the program eventually).
Maybe FL Studio and all those
'make-a-hit-in-one-day-apps' focus more on commercial goals... Ardour
doesn't compromise on this, they have very good reasons to use JACK the
way it is now, it gives people so much flexibility and possibilities.
Also they made a tool for professionals, so they assume users know at
least a little bit about audio. If you think its worth to invest a bit
in audio engineering when working with a DAW, Ardour and JACK might not
be the tool for you...
I really hate the term "audio engineering". It ascribes more brilliance
to these people than is warranted. I fail to see how my understanding of
audio directly influences the capability of Ardour. I find more often
than not I know what I want to do with Ardour, but it makes it
needlessly complicated (for example, loading in a clip whose sample rate
does not match the project rate, where other programs handle this
conversion automatically, or at least ask you what to do).
If we say that a DAW is nothing more than an 8-track recorder with a
load of buttons, I'll concede the point, but I think such a view is
slightly antiquated. DAWs are expected to be tools of creativity, and I
think the design of Ardour fails to appreciate or reflect this.
You have to dive into Linux audio deeply to understand it's
possibilities. It's not all perfect, not at all, but the developments
are relative new and there are nice tools for sure, especially when you
are able to find them and to use them. See www.openoctave.org
<http://www.openoctave.org> for instance, also an example of people who
work pretty professional with tools, which are not always very good
looking, but which are more powerful then you would expect at first sight.
And it is new, yes. I see great potential in it which could be why it
makes me so agitated having to wait :P
OpenOctave looks to have potential, but I'm waiting for the LV2 standard
to reach fruition before I say any sequencer on Linux is worth using.
Also there is the linuxsampler project, some great synths and plugins,
the Linux DSP plugins, Pianoteq for Linux, good possibilities to run
Windows VSTs with FST and DSSI-vst etc etc
\r
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
