linuxaudio.org

--90e6ba613854c6133704a9ac807b

Content-Type: text/plain; charset=ISO-8859-1
On Wed, Aug 3, 2011 at 10:27 AM,  wrote:
> People are working on the problem though but as time and money are short

quoted text
> 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 :)
--90e6ba613854c6133704a9ac807b

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
On Wed, Aug 3, 2011 at 10:27 AM,  <psh=

irkey@boosthardware.com> wrote:
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<=

br>

low on the list of priorities for most devs who want to scratch their own

itch not someone else's.Which provides featur=

es that are very technically advanced & cool, and probably don't lo=

ok like NI's newest synth. I don't see a problem there, the "p=

roblem" 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 di=

scussing.
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 us=

ers will even know about, but that pushes technology to the limit. That&#39=

;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 g=

etting recognition for.
Another angle to look at this is from "dev talent" vs "c=

hallenging work". Ie: if a huge talented DSP programmer is to "sp=

end" (read waste) thier time creating fancy UI's, then "dev-t=

alent" > "challenging work", so the productiveness of the=

 whole isn't maximized.
In the same way if "challenging work" > "dev-talent&q=

uot; we have the same situation, where productiveness isnt maxed, as the de=

v will have to read docs / tutorials / ask for help. Of course this does le=

ad to learning, and after learning understanding & then "dev"=

 > "challenge" again.
Example: I'm comfortable using Cairo, and if somebody hands me a Gtk::D=

rawingArea, 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=20

write a synth engine would be a case of "challenge" > "de=

v". To get=20

the job done right in as little time, I'd need to work together with=20

somebody who knows LV2 dsp stuff well, but not much Cairo.I'm i=

nterested 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 :)
--90e6ba613854c6133704a9ac807b--