4 Aug
2011
4 Aug
'11
2:31 p.m.
On Wed, Aug 3, 2011 at 10:27 AM,
<pshirkey(a)boosthardware.com> wrote:
In this regard my "cause" is composite. Which is really attempting to
provide a platform for the kind of work you are interested in. There are
other options too of course.
--
Patrick Shirkey
Boost Hardware Ltd
People are working on the problem though but as
time and money are short
these days it is not progressing very fast at the moment and in general
is
low on the list of priorities for most devs who want to scratch their
own
itch not someone else's.
Which provides features that are very technically advanced & cool, and
probably don't look like NI's newest synth. I don't see a problem there,
the
"problem" arises when somebody who *IS* used to seeing the pretty flashy
lights & dials looks at it and goes "eww". But if that's the dev's
problem
or the users problem is something I feel is worth discussing.
If the dev is looking for funding from the userbase, its obvious to say
that
the dev should work on features that the userbase want. If that's a flashy
UI to a 3x Osc, lets go do that. There might be far more advanced features
that the dev is capable of doing, that perhaps only 20% of the users will
even know about, but that pushes technology to the limit. That's what a
dev
wants to work on, because its new, and a challenge, but *not* what users
will provide funding for. This is not a good trait for the big picture, as
pushing technology is what the linux audio scene is currently getting
recognition for.
Another angle to look at this is from "dev talent" vs "challenging
work".
Ie: if a huge talented DSP programmer is to "spend" (read waste) thier
time
creating fancy UI's, then "dev-talent" > "challenging work",
so the
productiveness of the whole isn't maximized.
In the same way if "challenging work" > "dev-talent" we have the
same
situation, where productiveness isnt maxed, as the dev will have to read
docs / tutorials / ask for help. Of course this does lead to learning, and
after learning understanding & then "dev" > "challenge"
again.
Example: I'm comfortable using Cairo, and if somebody hands me a
Gtk::DrawingArea, I'll throw a Synth UI together without too much pain.
With
that in mind, I've never written a LV2 plugin, and for me to write a synth
engine would be a case of "challenge" > "dev". To get the job done
right
in
as little time, I'd need to work together with somebody who knows LV2 dsp
stuff well, but not much Cairo.
I'm interested in opinions from community to see if it is plausible /
possible / other to collaborate (more than we already are)?
Cheers, -Harry
PS: I concidered moving to a new topic.. but then thought nah :)