13 Feb
2012
13 Feb
'12
5:21 p.m.
Hello all,
I've written a new sampler/drum machine lv2 plugin called DrMr. You can
find it here: https://github.com/nicklan/drmr
It's main reason to exist is to give a way for lv2 hosts to have a built
in drum synth that can save its entire state (i.e. no need to go out to
external tools and no need to save extra state). DrMr currently
supports the following:
- Control via midi
- Scan for and load hydrogen drum kits
- Multi-layer hydrogen kits (will pick layer based on that sample's
set gain)
- Kit is set via an LV2 control
- LV2 controls for gain on each sample
- LV2 controls for pan on each sample
- GTK ui that can select a kit and control gain/pan on each sample
There's more info in the README.md which you can see if you click the
above link. There are a couple of screenshots on the github wiki page.
I hope people find it useful, and as it's rather new code, bug reports
are of course very welcome.
Cheers,
Nick
13 Feb
13 Feb
5:26 p.m.
Awesome!! Been looking forever for something like this. I will check it out
later tonight, til' then (and regardless): Great stuff!
Thank you!
Regards,
On Mon, Feb 13, 2012 at 5:20 PM, Nick Lanham <nick(a)afternight.org> wrote:
Hello all,
I've written a new sampler/drum machine lv2 plugin called DrMr. You can
find it here: https://github.com/nicklan/**drmr<https://github.com/nicklan/drmr>
It's main reason to exist is to give a way for lv2 hosts to have a built
in drum synth that can save its entire state (i.e. no need to go out to
external tools and no need to save extra state). DrMr currently supports
the following:
- Control via midi
- Scan for and load hydrogen drum kits
- Multi-layer hydrogen kits (will pick layer based on that sample's set
gain)
- Kit is set via an LV2 control
- LV2 controls for gain on each sample
- LV2 controls for pan on each sample
- GTK ui that can select a kit and control gain/pan on each sample
There's more info in the README.md which you can see if you click the
above link. There are a couple of screenshots on the github wiki page.
I hope people find it useful, and as it's rather new code, bug reports are
of course very welcome.
Cheers,
Nick
______________________________**_________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.**linuxaudio.org<Linux-audio-dev@lists.linuxaudio.org>
http://lists.linuxaudio.org/**listinfo/linux-audio-dev<http://lists.linu…
5:46 p.m.
Of course I managed to leave a misplaced dependency in the Makefile.
It's fixed now, but if anyone is getting:
make: *** No rule to make target `drmr_ui.xml', needed by `drmr.lv2'. Stop.
When trying to build, just re-clone the repo.
-Nick
6:02 p.m.
Very nice plugin, I tested it in my host and works great in a small test
(will give it more attention later).
(Sad thing about no string-port or some other way to provide compatibility)
one suggestion though, please use in drmr.ttl:
a lv2:InstrumentPlugin, lv2:Plugin;
so that hosts can properly identify it as a instrument/synth, thanks!
On Mon, Feb 13, 2012 at 4:45 PM, Nick Lanham <nick(a)afternight.org> wrote:
Of course I managed to leave a misplaced dependency in
the Makefile. It's
fixed now, but if anyone is getting:
make: *** No rule to make target `drmr_ui.xml', needed by `drmr.lv2'. Stop.
When trying to build, just re-clone the repo.
-Nick
______________________________**_________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.**linuxaudio.org<Linux-audio-dev@lists.linuxaudio.org>
http://lists.linuxaudio.org/**listinfo/linux-audio-dev<http://lists.linu…
6:11 p.m.
Thanks! Glad you like it. Thanks for the suggestion too, I've updated
the .ttl file.
-Nick
On 02/13/2012 06:02 PM, Filipe Lopes wrote:
Very nice plugin, I tested it in my host and works
great in a small
test (will give it more attention later).
(Sad thing about no string-port or some other way to
provide compatibility)
one suggestion though, please use in drmr.ttl:
a lv2:InstrumentPlugin, lv2:Plugin;
so that hosts can properly identify it as a instrument/synth, thanks!
On Mon, Feb 13, 2012 at 4:45 PM, Nick Lanham <nick(a)afternight.org
<mailto:nick@afternight.org>> wrote:
Of course I managed to leave a misplaced dependency in the
Makefile. It's fixed now, but if anyone is getting:
make: *** No rule to make target `drmr_ui.xml', needed by
`drmr.lv2'. Stop.
When trying to build, just re-clone the repo.
-Nick
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
<mailto:Linux-audio-dev@lists.linuxaudio.org>
http://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
10:04 p.m.
On Mon, 2012-02-13 at 17:02 +0000, Filipe Lopes wrote:
Very nice plugin, I tested it in my host and works
great in a small
test (will give it more attention later).
(Sad thing about no string-port or some other way to
provide compatibility)
string-port (which is not implemented by much at all) isn't a very good
way to gain compatibility.
For the curious, plugin control beyond beyond floats is where the most
work has been going on lately and should be released soon, and is
working in LV2 svn as well as my simple test host jalv[1]. The relevant
stuff is the atom[2] and message[3] extensions. The example sampler
plugin[4] uses this to talk between the UI and plugin to load sample
files.
High level overview/rationale documentation is still nonexistent, but
particularly since there's a working example it should be pretty
figure-out-able.
This work, in conjunction with the state[5] extension, should remove all
need for control port kludges and plugins accessing the file system.
Cheers,
-dr
[1] http://svn.drobilla.net/lad/trunk/jalv/
[2] http://lv2plug.in/ns/ext/atom
[3] http://lv2plug.in/ns/ext/message
[4] http://lv2plug.in/repo/trunk/plugins/eg-sampler.lv2/
[5] http://lv2plug.in/ns/ext/state
14 Feb
14 Feb
12:52 p.m.
Good to hear that there's something in the pipeline to address this.
I'll certainly add support for it once it's stable and supported in the
major hosts.
BTW, trying to run the example sampler in qtractor and it segfaults (see
gdb output below). Not sure if qtractor is doing some wrong, or me, or
the plugin :)
The other thing I'd love to be able to do is somehow change the # of
control ports dynamically (so I can expose exactly the right # of
gain/pan ports for the # of samples). dynamic-manifest seems like a
promising way to do this, but I haven't seen a way to ask the host to
re-poll for a new manifest, so that makes it pretty much useless if you
ever want to change kits. Any thoughts on this?
Thanks!
-Nick
GDB Output:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3c2b708 in main_arena () from /lib/libc.so.6
(gdb) up
#1 0x00007fffe4681db9 in map_uri (plugin=0x294e540, uri=0x7fffe4682228
"http://lv2plug.in/plugins/eg-sampler#filename") at ../sampler.c:354
354 return plugin->map->map(plugin->map->handle, uri);
(gdb) print plugin
$1 = (Sampler *) 0x294e540
(gdb) print *plugin
$2 = {map = 0x7ffff3c2b718, samp = 0x29cd720, pending_samp = 0x29e6300,
pending_samp_mutex = {__data = {__lock = 0, __count = 0, __owner = 0,
__nusers = 1, __kind = 0, __spins = 0,
__list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats
12 times>, "\001", '\000' <repeats 26 times>, __align = 0},
pending_samp_cond = {__data = {__lock = 0, __futex = 1,
__total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex =
0x294e558, __nwaiters = 2, __broadcast_seq = 0},
__size = "\000\000\000\000\001\000\000\000\001", '\000' <repeats
23
times>, "X\345\224\002\000\000\000\000\002\000\000\000\000\000\000",
__align = 4294967296}, pending_sample_ready = 1,
output_port = 0x0, event_port = 0x0, uris = {midi_event = 0,
atom_message = 0, set_message = 0, state_path = 0, filename_key = 0},
play = false, frame = 43818880,
worker_thread = 140736974575360}
(gdb) print *(plugin->map)
$3 = {handle = 0x7ffff3c2b708, map = 0x7ffff3c2b708 <main_arena+264>}
(gdb) print (plugin->map->map)
$4 = (LV2_URID (*)(LV2_URID_Map_Handle, const char *)) 0x7ffff3c2b708
<main_arena+264>
(gdb) print *(plugin->map->map)
$5 = {LV2_URID (LV2_URID_Map_Handle, const char *)} 0x7ffff3c2b708
<main_arena+264>
On 02/13/2012 10:04 PM, David Robillard wrote:
On Mon, 2012-02-13 at 17:02 +0000, Filipe Lopes
wrote:
Very nice plugin, I tested it in my host and
works great in a small
test (will give it more attention later).
(Sad thing about no string-port or some other way to
provide compatibility)
string-port (which is not implemented by much at all)
isn't a very good
way to gain compatibility.
For the curious, plugin control beyond beyond floats is where the most
work has been going on lately and should be released soon, and is
working in LV2 svn as well as my simple test host jalv[1]. The relevant
stuff is the atom[2] and message[3] extensions. The example sampler
plugin[4] uses this to talk between the UI and plugin to load sample
files.
High level overview/rationale documentation is still nonexistent, but
particularly since there's a working example it should be pretty
figure-out-able.
This work, in conjunction with the state[5] extension, should remove all
need for control port kludges and plugins accessing the file system.
Cheers,
-dr
[1] http://svn.drobilla.net/lad/trunk/jalv/
[2] http://lv2plug.in/ns/ext/atom
[3] http://lv2plug.in/ns/ext/message
[4] http://lv2plug.in/repo/trunk/plugins/eg-sampler.lv2/
[5] http://lv2plug.in/ns/ext/state
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev 
5:24 p.m.
On 14.02.2012 11:52, Nick Lanham wrote:
Good to hear that there's something in the
pipeline to address this.
I'll certainly add support for it once it's stable and supported in
the major hosts.
BTW, trying to run the example sampler in qtractor and it segfaults
(see gdb output below). Not sure if qtractor is doing some wrong, or
me, or the plugin :)
lv2-urid is only supported in the current qtractor svn trunk.
previous qtractor releases (<=0.5.3) deals with old style lv2-uri-map
(and lv2-uri-unmap) which could be gently supported on the plugin side
as well, just for retro-compability.
ah the ever mutating lv2 specs ;)
cheers
--
rncbc aka Rui Nuno Capela
8:33 p.m.
On Tue, 2012-02-14 at 12:52 +0100, Nick Lanham wrote:
[...]
The other thing I'd love to be able to do is
somehow change the # of
control ports dynamically (so I can expose exactly the right # of
gain/pan ports for the # of samples). dynamic-manifest seems like a
promising way to do this, but I haven't seen a way to ask the host to
re-poll for a new manifest, so that makes it pretty much useless if you
ever want to change kits. Any thoughts on this?
Too many thoughts, as usual :)
Right, dynmanifest can't really do things like this for an instantiated
plugins, it's only a discovery time thing.
There are two ways to go about getting this: "dynamic ports" and doing
all control via messages (so we don't need a port for every control).
Dynamic ports we don't really have yet. There is dynparam, but this is
not widely supported. I don't particularly like it because it's not
very extensible, doesn't really mesh with the RDF data, adds too much
API, and has some other issues; but these mainly stem from it pre-dating
a lot of needed extensions and established best practises. Something
similar to / based on it with a more modern take could be alright.
That said... I am increasingly becoming convinced that ports are
particularly awful for control (if not everything). Among other
problems, they are too static, which is your problem. Doing everything
via messages (e.g. "set gain to 1.6") that all travel in/out one
designated port (as events) keeps things completely dynamic, and breaks
free of the whole "single float per run()" thing so we could have
time-stamped control ramps and such.
The actual data types, logistics, etc. of this are being hammered out as
we speak, but mainly intended for "load this file" type uses (i.e.
things we can't do at all, currently). Nothing yet for using it for
control parameters, basically what needs figuring out there is how to
describe controls, add/remove them, announce new ones, etc. I will
consider making another example plugin that tinkers with this stuff.
The real win of a message-based approach is that *everything* happens
via meaningful events (which travel via ports), which means it's all
serialisable and network transparent and all that - including creating
and/or inspecting new parameters. This means UIs can do it. This is
not true of an API-based approach like dynparams. In general I think it
is an extremely bad idea to have UI<->plugin or plugin<->plugin
communication limited by explicit host support; it holds everything
back.
If anyone has an ideas for a very simple (no samples and threads and
such) example plugin with a reasonable use for multiple parameters, do
tell. I thought a multi-point envelope would be a neat one, but there's
too much UI work there.
-dr
8:44 p.m.
If anyone has an ideas for a very simple (no samples
and threads and
such) example plugin with a reasonable use for multiple parameters, do
tell. I thought a multi-point envelope would be a neat one, but there's
too much UI work there.
How about a simple mixer with N input channels and N gain controls?
perhaps pan channels too. I guess mono or stereo output depending on
if you want to include pan.
-Paul
9:03 p.m.
On Tue, 2012-02-14 at 14:44 -0500, Paul Giblock wrote:
That also involves a configurable amount of *audio* inputs, which is a
different ball game, and I don't really want to go there right now.
-dr
If anyone has
an ideas for a very simple (no samples and threads and
such) example plugin with a reasonable use for multiple parameters, do
tell. I thought a multi-point envelope would be a neat one, but there's
too much UI work there.
How about a simple mixer with N input channels and N gain controls?
perhaps pan channels too. I guess mono or stereo output depending on
if you want to include pan.
15 Feb
15 Feb
12:28 p.m.
On 02/14/2012 08:33 PM, David Robillard wrote:
If anyone has an ideas for a very simple (no samples
and threads and
such) example plugin with a reasonable use for multiple parameters, do
tell. I thought a multi-point envelope would be a neat one, but there's
too much UI work there.
What about just a simple multiband eq, with a variable number of bands?
You wouldn't even need a UI as the host based sliders would be just fine.
-Nick
8:30 p.m.
On Wed, 2012-02-15 at 12:27 +0100, Nick Lanham wrote:
On 02/14/2012 08:33 PM, David Robillard wrote:
That's a good one, thanks.
-dr
If anyone has an ideas for a very simple (no
samples and threads and
such) example plugin with a reasonable use for multiple parameters, do
tell. I thought a multi-point envelope would be a neat one, but there's
too much UI work there.
What about just a simple multiband eq, with a variable number of bands?
You wouldn't even need a UI as the host based sliders would be just fine. 
13 Feb
13 Feb
9:18 p.m.
On 02/13/2012 05:20 PM, Nick Lanham wrote:
I've written a new sampler/drum machine lv2 plugin
called DrMr. You can
find it here: https://github.com/nicklan/drmr
Very nice, thanks!
I hope people find it useful, and as it's rather
new code, bug reports
are of course very welcome.
One thing I noticed: There's no tilde expansion in opendir(). If you
want to make the tilde paths for the drumkits work then you'll have to
use something like wordexp() or just substitute getenv("HOME") for the
tilde before passing the path to opendir().
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
9:59 p.m.
On 02/13/2012 05:20 PM, Nick Lanham wrote:
Hello all,
I've written a new sampler/drum machine lv2 plugin called DrMr. You can
find it here: https://github.com/nicklan/drmr
It's main reason to exist is to give a way for lv2 hosts to have a built
in drum synth that can save its entire state (i.e. no need to go out to
external tools and no need to save extra state). DrMr currently supports
the following:
- Control via midi
- Scan for and load hydrogen drum kits
- Multi-layer hydrogen kits (will pick layer based on that sample's set
gain)
- Kit is set via an LV2 control
- LV2 controls for gain on each sample
- LV2 controls for pan on each sample
- GTK ui that can select a kit and control gain/pan on each sample
There's more info in the README.md which you can see if you click the
above link. There are a couple of screenshots on the github wiki page.
I hope people find it useful, and as it's rather new code, bug reports
are of course very welcome.
Cheers,
Nick
Hello Nick,
Awesome news! Very little dependencies too so hopefully I can compile
this without much issues. One thing though about the Wiki which states
Qtractor doesn't support GTK UIs. This is not entirely true, QTractor
does support GTK UIs but you might have missed a configure option,
probably it's --enable-lv2-files which is not set by default (could be
wrong here though).
Best,
Jeremy
10:27 p.m.
On 02/13/2012 08:59 PM, Jeremy Jongepier wrote:
On 02/13/2012 05:20 PM, Nick Lanham wrote:
drmr works ok on both old slv2 and newer lilv qtractor flavors.
otoh. lv2-files is subordinated to the lv2-state extension and it is
currently fubar (even on svn trunk). it is not deemed necessary in
anyway for any plugin to work properly, afaict.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Hello all,
I've written a new sampler/drum machine lv2 plugin called DrMr. You can
find it here: https://github.com/nicklan/drmr
It's main reason to exist is to give a way for lv2 hosts to have a built
in drum synth that can save its entire state (i.e. no need to go out to
external tools and no need to save extra state). DrMr currently supports
the following:
- Control via midi
- Scan for and load hydrogen drum kits
- Multi-layer hydrogen kits (will pick layer based on that sample's set
gain)
- Kit is set via an LV2 control
- LV2 controls for gain on each sample
- LV2 controls for pan on each sample
- GTK ui that can select a kit and control gain/pan on each sample
There's more info in the README.md which you can see if you click the
above link. There are a couple of screenshots on the github wiki page.
I hope people find it useful, and as it's rather new code, bug reports
are of course very welcome.
Cheers,
Nick
Hello Nick,
Awesome news! Very little dependencies too so hopefully I can compile
this without much issues. One thing though about the Wiki which states
Qtractor doesn't support GTK UIs. This is not entirely true, QTractor
does support GTK UIs but you might have missed a configure option,
probably it's --enable-lv2-files which is not set by default (could be
wrong here though).
10:30 p.m.
On Mon, 2012-02-13 at 21:27 +0000, Rui Nuno Capela wrote:
drmr works ok on both old slv2 and newer lilv qtractor
flavors.
otoh. lv2-files is subordinated to the lv2-state extension and it is
currently fubar (even on svn trunk). it is not deemed necessary in
anyway for any plugin to work properly, afaict.
And certainly has nothing to do with UI support anyway.
There is no point in support for "persist" or "files" continuing to
exist anywhere, it should be removed.
-dr
10:39 p.m.
On 02/13/2012 10:30 PM, David Robillard wrote:
On Mon, 2012-02-13 at 21:27 +0000, Rui Nuno Capela
wrote:
Well, it was a actually a really wild guess, sorry for the noise.
Jeremy
drmr works ok on both old slv2 and newer lilv
qtractor flavors.
otoh. lv2-files is subordinated to the lv2-state extension and it is
currently fubar (even on svn trunk). it is not deemed necessary in
anyway for any plugin to work properly, afaict.
And certainly has nothing to do with UI support anyway.
There is no point in support for "persist" or "files" continuing to
exist anywhere, it should be removed.
-dr
10:48 p.m.
On 02/13/2012 09:30 PM, David Robillard wrote:
On Mon, 2012-02-13 at 21:27 +0000, Rui Nuno Capela
wrote:
hell, yes. someday i gotta tear out that lv2-persist (pure-)cruft from
the pile. someday ;)
however, the lv2-files thing pertains to a lv2-state feature. it is not
the stand-alone extension as it was in the lv2-persist days.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
drmr works ok on both old slv2 and newer lilv
qtractor flavors.
otoh. lv2-files is subordinated to the lv2-state extension and it is
currently fubar (even on svn trunk). it is not deemed necessary in
anyway for any plugin to work properly, afaict.
And certainly has nothing to do with UI support anyway.
There is no point in support for "persist" or "files" continuing to
exist anywhere, it should be removed.
11:06 p.m.
On Mon, 2012-02-13 at 21:48 +0000, Rui Nuno Capela wrote:
On 02/13/2012 09:30 PM, David Robillard wrote:
Fair enough. Qtractor should probably move to the new lilv API for this
anyway. I havn't tried that yet.
-dr
On Mon, 2012-02-13 at 21:27 +0000, Rui Nuno
Capela wrote:
hell, yes. someday i gotta tear out that lv2-persist (pure-)cruft from
the pile. someday ;)
however, the lv2-files thing pertains to a lv2-state feature. it is not
the stand-alone extension as it was in the lv2-persist days. drmr works ok on both old slv2 and newer lilv
qtractor flavors.
otoh. lv2-files is subordinated to the lv2-state extension and it is
currently fubar (even on svn trunk). it is not deemed necessary in
anyway for any plugin to work properly, afaict.
And certainly has nothing to do with UI support anyway.
There is no point in support for "persist" or "files" continuing to
exist anywhere, it should be removed.
14 Feb
14 Feb
10:54 a.m.
On 13.02.2012 22:06, David Robillard wrote:
On Mon, 2012-02-13 at 21:48 +0000, Rui Nuno Capela
wrote:
as said, you can build qtractor with either slv2 (default) or lilv.
you should build with ./configure --enable-lilv to override the default
slv2 precedence over lilv, in case both -dev packages are installed.
cheers
--
rncbc aka Rui Nuno Capela
On 02/13/2012 09:30 PM, David Robillard wrote:
to
Fair enough. Qtractor should probably move to the new lilv API for
this
anyway. I havn't tried that yet.
On Mon, 2012-02-13 at 21:27 +0000, Rui Nuno
Capela wrote:
> drmr works ok on both old slv2 and newer lilv qtractor flavors.
>
> otoh. lv2-files is subordinated to the lv2-state extension and it
is
> currently fubar (even on svn trunk). it is
not deemed necessary
in
anyway
for any plugin to work properly, afaict.
And certainly has nothing to do with UI support anyway.
There is no point in support for "persist" or "files" continuing
exist anywhere, it should be removed.
hell, yes. someday i gotta tear out that lv2-persist (pure-)cruft
from
the pile. someday ;)
however, the lv2-files thing pertains to a lv2-state feature. it is
not
the stand-alone extension as it was in the lv2-persist days.
7:48 p.m.
On Tue, 2012-02-14 at 09:54 +0000, rncbc wrote:
I meant the new part of the Lilv API which implements state
saving/restoration.
-dr
On 13.02.2012 22:06, David Robillard wrote:
[...]
Fair enough.
Qtractor should probably move to the new lilv API for
this
anyway. I havn't tried that yet.
as said, you can build qtractor with either slv2 (default) or lilv.
you should build with ./configure --enable-lilv to override the default
slv2 precedence over lilv, in case both -dev packages are installed.
8:21 a.m.
On 02/13/2012 05:20 PM, Nick Lanham wrote:
I hope people find it useful, and as it's rather
new code, bug reports are of course very welcome.
Two more nitpicks:
1. If the host's samplerate (as given by the LV2 instantiate() callback)
differs from the samplerate of the wave files, the samples sound wrong
(well, at least different from what you hear with the same drumkit in
hydrogen). To avoid that, you have to resample the waves on the fly when
loading them; libsamplerate does that kind of thing.
2. If you export a sequence from hydrogen as midi, you get midi notes
starting at C2 (36), whereas drmr's midi mapping uses the octave
starting at C4 (60). It's a minor thing, as you can easily transpose the
notes, e.g., in Qtractor after importing the midi from hydrogen, but it
would be more convenient if drmr used the same midi mapping as hydrogen
itself.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
10:58 a.m.
On Mon, Feb 13, 2012 at 8:20 PM, Nick Lanham wrote:
Hello all,
I've written a new sampler/drum machine lv2 plugin called DrMr. You can
find it here: https://github.com/nicklan/drmr
It's main reason to exist is to give a way for lv2 hosts to have a built in
drum synth that can save its entire state (i.e. no need to go out to
external tools and no need to save extra state). DrMr currently supports
the following:
- Control via midi
- Scan for and load hydrogen drum kits
- Multi-layer hydrogen kits (will pick layer based on that sample's set
gain)
- Kit is set via an LV2 control
- LV2 controls for gain on each sample
- LV2 controls for pan on each sample
- GTK ui that can select a kit and control gain/pan on each sample
There's more info in the README.md which you can see if you click the above
link. There are a couple of screenshots on the github wiki page.
I hope people find it useful, and as it's rather new code, bug reports are
of course very welcome.
That's a quite awesome thing even in its infancy. A small nitpick: it
would be nice reading user's drumkits directory, i.e.
~/.hydrogen/data/drumkits.
Other than that, do you have plans adding UI for basic management of
drumkits so that users would be able to add/remove instruments and
save drumkits?
Alexandre Prokoudine
http://libregraphicsworld.org
11:21 a.m.
On 02/14/2012 10:58 AM, Alexandre Prokoudine wrote:
That's a quite awesome thing even in its infancy.
A small nitpick: it
would be nice reading user's drumkits directory, i.e.
~/.hydrogen/data/drumkits.
That's a bug (see my previous post), but easy to fix. If anyone is
interested, I can post the necessary changes here.
Other than that, do you have plans adding UI for basic
management of
drumkits so that users would be able to add/remove instruments and
save drumkits?
You can easily do that in Hydrogen itself, so why bother?
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
12:24 p.m.
Thanks for all the feedback everyone.
I've just pushed a couple of updates to address a few problems people
had found:
- Convert samples as loaded to plugin rate. This adds a dependency on
libsamplerate.
- Expand ~ in paths properly using HOME environment variable. This
means your ~/.hydrogen/data/drumkits should get loaded.
- Changed the wiki to not state that qtractor doesn't support GtkUIs.
Sorry if that claim was wrong, I had remembered reading it somewhere,
and it doesn't on my system but that's just due to the flags I compiled
it with.
Also, I'm considering changing the root midi note from C4 to C2 to match
up with Hydrogen as per a suggestion from Albert. I haven't decided if
I should just change the code and leave it hard-coded as is, or expose a
control port to allow people to set that. Do people have a preference?
- Nick
On 02/14/2012 11:21 AM, Albert Graef wrote:
On 02/14/2012 10:58 AM, Alexandre Prokoudine wrote:
That's a quite awesome thing even in its
infancy. A small nitpick: it
would be nice reading user's drumkits directory, i.e.
~/.hydrogen/data/drumkits.
That's a bug (see my previous post), but easy to fix. If anyone is
interested, I can post the necessary changes here.
Other than that, do you have plans adding UI for
basic management of
drumkits so that users would be able to add/remove instruments and
save drumkits?
You can easily do that in Hydrogen itself, so why bother?
Albert
1:18 p.m.
On 02/14/2012 06:23 AM, Nick Lanham wrote:
... I'm considering changing the root midi note
from C4 to C2 to match
up with Hydrogen as per a suggestion from Albert. I haven't decided
if I should just change the code and leave it hard-coded as is, or
expose a control port to allow people to set that. Do people have a
preference?
I'd like to be able to set it.
Btw, I built and tested the plugin this morning with the latest rev of
Ardour3. I loaded a MIDI file of a Chopin piano piece and played it with
the GMKit via DrMr. Worked fine. :)
64-bit Arch, btw.
Best,
dp
3:57 p.m.
On 02/14/2012 01:18 PM, Dave Phillips wrote:
I'd like to be able to set it.
Done. Pushed
it as a control, and you can set it in the ui. This
changes the port indexes, so hopefully no one had a bunch of automation
already or you'll have to redo that.
Btw, I built and tested the plugin this morning with the latest rev of
Ardour3. I loaded a MIDI file of a Chopin piano piece and played it
with the GMKit via DrMr. Worked fine. :)
Glad it works for you!
64-bit Arch, btw.
That's what I'm building it on, so it should work there
:)
-Nick
2:23 p.m.
On Tue, Feb 14, 2012 at 2:21 PM, Albert Graef wrote:
Yeah, right. All I have to do is to launch Hydrogen and start doing
things with it. And since I have it running anyway, why not simply
route MIDI from Ardour to Hydrogen and make it play sounds? So why
bother inventing DrMr? :)
So here is a question. Let's say, you are working on a song and you
want to simply add a new percussion instrument, because you feel like
it would be a great idea. Do you seriously want to start a whole
separate application to do a very basic thing? In the middle of
creative process? Really? :)
Alexandre Prokoudine
http://libregraphicsworld.org
Other than
that, do you have plans adding UI for basic management of
drumkits so that users would be able to add/remove instruments and
save drumkits?
You can easily do that in Hydrogen itself, so why bother?
2:51 p.m.
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.
-Nick
On 02/14/2012 02:23 PM, Alexandre Prokoudine wrote:
On Tue, Feb 14, 2012 at 2:21 PM, Albert Graef wrote:
Yeah, right. All I have to do is to launch Hydrogen and start doing
things with it. And since I have it running anyway, why not simply
route MIDI from Ardour to Hydrogen and make it play sounds? So why
bother inventing DrMr? :)
So here is a question. Let's say, you are working on a song and you
want to simply add a new percussion instrument, because you feel like
it would be a great idea. Do you seriously want to start a whole
separate application to do a very basic thing? In the middle of
creative process? Really? :)
Alexandre Prokoudine
http://libregraphicsworld.org
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Other
than that, do you have plans adding UI for basic management of
drumkits so that users would be able to add/remove instruments and
save drumkits?
You can easily do that in Hydrogen itself, so why bother? 
3:22 p.m.
Nick Lanham wrote:
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
6:49 p.m.
2012/2/14 Sebastian Moors <mauser(a)smoors.de>
Nick Lanham wrote:
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
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
______________________________**_________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.**linuxaudio.org<Linux-audio-dev@lists.linuxaudio.org>
http://lists.linuxaudio.org/**listinfo/linux-audio-dev<http://lists.linu…
--
follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !
17 Feb
17 Feb
4:53 p.m.
On 02/14/2012 06:49 PM, thijs van severen wrote:
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
Yes, I'm very aware that I'm duplicating a certain amount of hydrogen
effort here. I'd love it if hydrogen had a nice api to plug it into a
module like this, and I know there's already an effort to turn hydrogen
into an lv2 plugin (composite). However, the sad fact is that at the
moment, there's nothing that fills the niche the DrMr is in (composite
is similar but has no real control interface). So yeah, a libhydrogen
would be great, with all the code to read hydrogen files and load up
drum kit data, and somehow play/process samples, and DrMr and Hydrogen
and anything else could share that, but I somehow don't see that coming
anytime soon (unless someone who knows the hydrogen codebase better than
I wants to tackle it). I'm also not convinced that something written as
a plugin has the same needs as something written as a stand-alone app,
so I really think the code would need to be well split/modularized,
rather than trying to wrap all of hydrogen up in an lv2.
In other news, DrMr has had a lot of fixes checked in recently, and (as
far as I can tell), is currently fairly stable. So, if you're using it
and seeing weird behavior please a) update, and b) let me know if it's
still happening after updating.
-Nick
6:01 p.m.
Nick Lanham wrote:
On 02/14/2012 06:49 PM, thijs van severen wrote:
Hi Nick!
You're always invited to discuss the technical details on the hydrogen
development list, as i think they don't really belong here.
We have already a very modular architecture, and i believe that it would
be possible to create a shared lib for the reading of drumkits without
big trouble. The playing/processing samples part is definitely more
complicated.
- 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
Yes, I'm very aware that I'm duplicating a certain amount of hydrogen
effort here. I'd love it if hydrogen had a nice api to plug it into a
module like this, and I know there's already an effort to turn
hydrogen into an lv2 plugin (composite). However, the sad fact is
that at the moment, there's nothing that fills the niche the DrMr is
in (composite is similar but has no real control interface). So yeah,
a libhydrogen would be great, with all the code to read hydrogen files
and load up drum kit data, and somehow play/process samples, and DrMr
and Hydrogen and anything else could share that, but I somehow don't
see that coming anytime soon (unless someone who knows the hydrogen
codebase better than I wants to tackle it).
8:53 p.m.
On 02/17/2012 06:01 PM, Sebastian Moors wrote:
We have already a very modular architecture, and i
believe that it would
be possible to create a shared lib for the reading of drumkits without
big trouble. The playing/processing samples part is definitely more
complicated.
I think that Nick has nailed the reading of the drumkits already. So we
should be concerned with the more advanced parts. Besides the drumkit
editing (which I can also do with Hydrogen itself), I think that it
would be nice if the non-destructive cutting and time stretching of
samples implemented by Hydrogen's new sample editor would be available
in DrMr.
However, when I save a drumkit in which I have edited the layers in this
way, Hydrogen doesn't seem to record those changes in the drumkit.
Apparently, those changes are only stored in the song files, at least
with the 0.9.5 and 0.9.6svn versions available at
https://launchpad.net/~kxstudio-team/+archive/hydrogen/ that I tried. Is
that by design, or are there plans to change this in the 0.9.6 version
of Hydrogen?
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
18 Feb
18 Feb
12:05 a.m.
Am Fri, 17 Feb 2012 20:53:29 +0100
schrieb Albert Graef <Dr.Graef(a)t-online.de>de>:
On 02/17/2012 06:01 PM, Sebastian Moors wrote:
hi albert,
if i designed the hydrogen-sample-editor the main concept was to make them non
destructive and bind all sample settings to h2 song-files. this follow strictly the new
hydrogen song concept since version 0.9.4. since 0.9.4 it is possible to
crate/modify/save
songs with instrument sets which can be independent from existing sound-libraries
(drumkits). imo, this is one of the biggest improvements for song creation in hydrogen.
in this case it make really no sense to save the results of sample editing directly into
the corresponding drumkit. more... this will destroy the no destructive load function. an
example here is, if you create a song X with sample(instrument) X which holds non
destructive changing via sample editor. what happens if you have changed this
sample(intrument) X for example some days later when you are working on song Y? you will
definitely destroy song X.
how ever, i am thinking about two improvements on the sampleditor which will go into
the direction you suggest.
improvements:
* export sample-editor results as an audiofile
* quick create new instrument button. this will simple create an new h2 instrument which
include the resulting sample. my idea is, simple arrange the new instrument directly
below the instrument that you currently modifying. the problem here is that you have
to store the resulting audio file. currently i have no idea where i store this files.
---8<---
(:the following is a bit offtopic but important for me to say. because imo, DrMr and
hydrogen are complete different tools which follow different composing ideas:)
---8<---
but this improvements cannot reconstruct the main goal from the sample editor rubberband
implementation. i mean the instrument-layer-rubberband-batch-processor-function. :) long
word. maybe you know this function. if you have enabled the batch processor, hydrogen
recalculate at tempo changing on the fly for all samples which are modified with
rubberband. this allows users to change tempo for example via jacktransport.
if you work with loop-samples (i do this a lot) hydrogen's samples(loops) all time
fit
into your beat. so it is possible to trigger the loop-instruments via midi triggers.
good for people which play live sessions.
currently all my further plans for the sample-editor goes into this live useability.
in moment hydrogen has two faces. first face is the simple and intuitive to use drum
machine sequencer which allows users to create drum tracks with only a few mouse clicks
without any experience.
but second face is a nice live tool which holds many nice functions in the background.
this features are mostly arranged in the background to keep the simple to use interface
as it is.
i think the future of hydrogen is more or less the way in direction live tool. also it
has a good useability to practice guitar, bass or whatever instruments. but it have no
future as an composing tool to crate(produce) static songs via an daw. here users need
plugins like DrMr. and so i think the future for DrMr cannot be an to closed
orientation on hydrogen drumkits and his structure and functions. imo, it's a good
idea to simply support h2 drumkits. but better is to follow an more modern and way of
sampling drums. and this need at least an other instrument structure of layering than
hydrogen instruments follow. DrMr is on the beginning. so everything is possible.
greetings wolke
We have already a very modular architecture, and
i believe that it would
be possible to create a shared lib for the reading of drumkits without
big trouble. The playing/processing samples part is definitely more
complicated.
I think that Nick has nailed the reading of the drumkits already. So we
should be concerned with the more advanced parts. Besides the drumkit
editing (which I can also do with Hydrogen itself), I think that it
would be nice if the non-destructive cutting and time stretching of
samples implemented by Hydrogen's new sample editor would be available
in DrMr.
However, when I save a drumkit in which I have edited the layers in this
way, Hydrogen doesn't seem to record those changes in the drumkit.
Apparently, those changes are only stored in the song files, at least
with the 0.9.5 and 0.9.6svn versions available at
https://launchpad.net/~kxstudio-team/+archive/hydrogen/ that I tried. Is
that by design, or are there plans to change this in the 0.9.6 version
of Hydrogen?
Albert
2:10 p.m.
On 02/18/2012 12:05 AM, m.wolkstein(a)gmx.de wrote:
if i designed the hydrogen-sample-editor the main
concept was to make them non
destructive and bind all sample settings to h2 song-files.
Ok, so it's by design. That's what I wanted to know, thanks for
clarifying this. I can also understand the rationale behind this.
* export sample-editor results as an audiofile
That would be very convenient.
* quick create new instrument button. this will
simple create an new h2 instrument which
include the resulting sample. my idea is, simple arrange the new instrument directly
below the instrument that you currently modifying. the problem here is that you have
to store the resulting audio file. currently i have no idea where i store this files.
That would be even more convenient. But if I have the first option above
then I can easily create the new instrument myself. Anyway, an obvious
default for the filenames would be ~/.hydrogen/data/samples/%s-%d.%s,
where %s.%s is the basename of the original sample, and %d is some
serial number to make the filename unique so that you don't overwrite
any existing files.
but this improvements cannot reconstruct the main goal
from the sample editor rubberband
implementation. i mean the instrument-layer-rubberband-batch-processor-function. :)
Yes, that's a very nice feature. But DrMr could support this in the
future as well, as soon as hosts adopt the LV2 Time extension which is
still in the making. So I'm not sure that I buy your argument that the
two are for totally different use cases. :)
What's special about Hydrogen, however, is its user interface. People
like it exactly because it's so dead-easy to use for the purpose that it
has been designed for. And now we can use Hydrogen to create the
drumkits and patterns that we need, and then employ DrMr to port them
over to Qtractor where the rest of the arrangement can be done. That's
very useful already, even though DrMr has only been announced less than
a week ago. ;-) DrMr definitely fills a gap there.
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
14 Feb
14 Feb
7:39 p.m.
On Tue, Feb 14, 2012 at 6:22 PM, Sebastian Moors wrote:
Or make a libhydrogen with a plain C public API? :)
Alexandre Prokoudine
http://libregraphicsworld.org
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...) ?
4615
days inactive
4620
days old
linux-audio-dev@lists.linuxaudio.org
38 comments
15 participants
participants (15)
-
Albert Graef -
Alexandre Prokoudine -
Dave Phillips -
David Robillard -
Filipe Lopes -
Gabbe Nord -
Jeremy Jongepier -
m.wolkstein＠gmx.de -
Nick Lanham -
Paul Davis -
Paul Giblock -
rncbc -
Rui Nuno Capela
-
Sebastian Moors -
thijs van severen