linuxaudio.org

--14dae9ccd4ec12c19b04b8f038d9

Content-Type: text/plain; charset=ISO-8859-1
2012/2/14 Sebastian Moors 
> Nick Lanham wrote:

quoted text
>

>> Firstly, yes, at some point I would like to have kit editing/creation

>> available from the GUI.  This is non-trivial however, and a bit down the

>> road.

>>

>> To your second point, I agree that it's non-optimal to have to fire up

>> hydrogen to make minor changes to kits and the like.  However, I still

>> think DrMr improves the situation, as it sits nicely in your host, saves

>> all your parameters, and doesn't require any external routing.  Of course

>> if you're fine with setting up all the external routing and kit loading

>> etc, you should just avoid DrMr all together, hydrogen is more fully

>> featured and almost certainly more stable anyway, but the whole point of me

>> writing DrMr was that I got sick of having to set up both my host and

>> hydrogen for every track i wanted to open.

>>

>> But yes, kit customization is in the pipeline, although behind getting

>> the core solid and stable.

>>

>

> Hm, i'm sceptic about this point... This code duplication seems to be

> quite an overhead. If you go into every detail of drumkit management, you

> end up with re-writing a lot of hydrogen classes in plain C. Is that really

> worth the effort?

>

> Why not improve the drumkit editing abilities of hydrogen? Or create a

> dedicated drumkit editor on top of hydrogen's codebase (imho, hydrogen is

> not really user-friendly enough when it comes to kit-creation...) ?

> - Sebastian

>

>

i must say that i agree with Sebastian (yes, i am biased ;-)  You might end

up rewriting a part hydrogen.  Maybe not at first, but gradually the number

of feature requests will go up and you might end up doing duplicate work.

There is nothing wrong with that of course, but it just doesnt seem like

the most efficient way to go.

On the other hand i am also _very_ much a fan of the plugin model rather

than individual apps that are glued together using some type of session

manager...

I'm no programmer, and i do realize that it takes more than a one-liner to

but -allow me to dream for a second- would it not be great if we could

combine the effort that goes into various apps that all do more-or-less the

same thing ?

grtz

Thijs

>

quoted text
> ______________________________**_________________

> Linux-audio-dev mailing list

> Linux-audio-dev@lists.**linuxaudio.org

> http://lists.linuxaudio.org/**listinfo/linux-audio-dev

>

-- 
follow me on my Audio & Linux blog  !
--14dae9ccd4ec12c19b04b8f038d9

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

Content-Transfer-Encoding: quoted-printable
2012/2/14 Sebastian Moors <mauser@smoors.de>=
Nick Lanham wrote:
Firstly, yes, at some point I would like to have kit editing/creation avail=

able from the GUI. =A0This is non-trivial however, and a bit down the road.=
To your second point, I agree that it's non-optimal to have to fire up =

hydrogen to make minor changes to kits and the like. =A0However, I still th=

ink DrMr improves the situation, as it sits nicely in your host, saves all =

your parameters, and doesn't require any external routing. =A0Of course=

 if you're fine with setting up all the external routing and kit loadin=

g etc, you should just avoid DrMr all together, hydrogen is more fully feat=

ured and almost certainly more stable anyway, but the whole point of me wri=

ting DrMr was that I got sick of having to set up both my host and hydrogen=

 for every track i wanted to open.
But yes, kit customization is in the pipeline, although behind getting the =

core solid and stable.
Hm, i'm sceptic about this point... This code duplication seems to be q=

uite an overhead. If you go into every detail of drumkit management, you en=

d up with re-writing a lot of hydrogen classes in plain C. Is that really w=

orth the effort?
Why not improve the drumkit editing abilities of hydrogen? Or create a dedi=

cated drumkit editor on top of hydrogen's codebase (imho, hydrogen is n=

ot really user-friendly enough when it comes to kit-creation...) ?
- Sebastian=

i must say that i agree with Se=

bastian (yes, i am biased ;-) =A0You might end up rewriting a part hydrogen=

. =A0Maybe not at first, but gradually the number of feature requests will =

go up and you might end up doing duplicate work. There is nothing wrong wit=

h that of course, but it just doesnt seem like the most efficient way to go=

.
On the other hand i am also _very_ much a fan of the plugin model rath=

er than individual apps that are glued together using some type of session =

manager...I'm no programmer, and i do realize that it takes =

more than a one-liner to but -allow me to dream for a second- would it not =

be great if we could combine the effort that goes into various apps that al=

l do more-or-less the same thing ?
grtzThijs=A0
_______________________________________________

Linux-audio-dev mailing list

L=

inux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- =

follow me on my=A0Audio & Linux blog !
--14dae9ccd4ec12c19b04b8f038d9--