22 Sep
2011
22 Sep
'11
7:05 p.m.
Hi all,
I am in search of a more or less easy way to do voice-to-drums - that
is, to trigger drum samples (MIDI or otherwise) and control their volume
(velocity) using my voice recorded from a microphone. Real-time is not
necessary, and neither is multi-sample capability. The objective is to
create more lively, groovy drum loops, which I can emulate with my voice.
I tried using the Trigger LADSPA plugin but so far have not had any
success with it. The output I get makes no sense to me, and the meaning
of some parameters like e.g. threshold is unclear due to units chosen.
Can anyone point me to any HOWTOs on using Trigger or describe the
workflow in a few words?
I would also like to know about possible alternatives to Trigger,
including those for Windows.
Thanks in advance,
Artem Vakhitov
22 Sep
22 Sep
9:05 p.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
Hi Artem,
On 09/22/2011 07:05 PM, Artem Vakhitov wrote:
Hi all,
I am in search of a more or less easy way to do voice-to-drums - that
is, to trigger drum samples (MIDI or otherwise) and control their volume
(velocity) using my voice recorded from a microphone. Real-time is not
necessary, and neither is multi-sample capability. The objective is to
create more lively, groovy drum loops, which I can emulate with my voice.
I'm not sure you can do that with any tool 'out of the box' especially
the "control their volume" part, as triggers usually have a 'binary'
(on/off threshold). Of course (but that is probably obvious) being human
voice monophonic you will have to do "a piece at a time"
I tried using the Trigger LADSPA plugin but so far have not had any
success with it. The output I get makes no sense to me, and the meaning
of some parameters like e.g. threshold is unclear due to units chosen.
Can anyone point me to any HOWTOs on using Trigger or describe the
workflow in a few words?
I'll give it a try (although I never used the LADSPA plugin version): A
trigger is usually quite simple. It "monitors" an input signal, when the
signal's amplitude goes above the threshold (which you set) it will play
(trigger) the chosen sample. The hold parameter (usually measured in
milliseconds) is important because it sets how long the Trigger remains
inactive (holds) after it triggered this avoids re-triggering the sample
too quickly especially if the input signal remains above the threshold
for too long.
Here is an very simple example of what you're probably thinking of:
http://lorenzosu.altervista.org/temp/dump/trigger_test.ogg
Hard panned left is the audio input (in this case it's not my voice but
me tapping on my crap laptop mic) hard right the triggered sample. You
can noticed some taps are "missed" this is because they were below
threshold (too quiet). The hold was at 80 ms (excuse the horrible
quality of the audio input quickly made on my laptop and it's night here..)
I would also like to know about possible alternatives to Trigger,
including those for Windows.
Well I made a very simple trigger for PD [1] a while ago (to be used
mainly with ardour - used for the above example).
Lorenzo
[1] http://lorenzosu.altervista.org/pd/trigger/
Thanks in advance,
Artem Vakhitov
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:16 p.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On Thu, Sep 22, 2011 at 09:06:53PM +0200, Lorenzo Sutton wrote:
I'm not sure you can do that with any tool
'out of the box' especially
the "control their volume" part, as triggers usually have a 'binary'
(on/off threshold). Of course (but that is probably obvious) being human
voice monophonic you will have to do "a piece at a time"
If you need not only the timing but also to control volume
then it's unlikely this can be done without delay. The part
of the input that would contain usable information to control
volume would very probably come after the trigger, but to
play the sample you need both. The only solution then is to
delay the trigger. That means that simple solutions such as
the ladspa plugin can't do what you want.
Ciao,
--
FA
9:42 p.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On 22.09.2011 23:16, Fons Adriaensen wrote:
If you need not only the timing but also to control
volume
then it's unlikely this can be done without delay. The part
of the input that would contain usable information to control
volume would very probably come after the trigger, but to
play the sample you need both. The only solution then is to
delay the trigger. That means that simple solutions such as
the ladspa plugin can't do what you want.
The thing is, I do not need to do that in any kind of real time. It
would be sufficient to feed a "beat box" .wav file at the input and get
the corresponding .wav or .mid file at the output. All digital
processing can be done fully off-line, so all timing and amplitude info
is there in advance.
Regards,
Artem
11:38 p.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On Thu, Sep 22, 2011 at 11:42:05PM +0400, Artem Vakhitov wrote:
On 22.09.2011 23:16, Fons Adriaensen wrote:
Even if it hasn't to work in real time Pd is probably the
ideal tool to prototype such a system. The alternative
would be to write some ad-hoc C/C++ code, possibly using
existing 'feature extraction' libraries or plugin code.
As a first guess, what you need would be:
- (optional) some pre-filtering to make the trigger
more reliable,
- the trigger itself,
- a delay on the trigger,
and in parallel
- (optional) some pre-filtering for the envelope
follower,
- an envelope follower,
- when the delayed trigger arrives, read the envelope
follower and start the sample playback.
Ciao,
--
FA
If you need not only the timing but also to
control volume
then it's unlikely this can be done without delay. The part
of the input that would contain usable information to control
volume would very probably come after the trigger, but to
play the sample you need both. The only solution then is to
delay the trigger. That means that simple solutions such as
the ladspa plugin can't do what you want.
The thing is, I do not need to do that in any kind of real time. It
would be sufficient to feed a "beat box" .wav file at the input and get
the corresponding .wav or .mid file at the output. All digital
processing can be done fully off-line, so all timing and amplitude info
is there in advance. 
23 Sep
23 Sep
4:07 a.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On Thu, Sep 22, 2011 at 09:38:51PM +0000, Fons Adriaensen wrote:
On Thu, Sep 22, 2011 at 11:42:05PM +0400, Artem
Vakhitov wrote:
Just idle curiosity, but why
do you guys recommend PD over SC or csound?
I had the idea they were more or less equally suited.
Cheers,
S.M.
On 22.09.2011 23:16, Fons Adriaensen wrote:
Even if it hasn't to work in real time Pd is probably the
ideal tool to prototype such a system. The alternative If you need not only the timing but also to
control volume
then it's unlikely this can be done without delay. The part
of the input that would contain usable information to control
volume would very probably come after the trigger, but to
play the sample you need both. The only solution then is to
delay the trigger. That means that simple solutions such as
the ladspa plugin can't do what you want.
The thing is, I do not need to do that in any kind of real time. It
would be sufficient to feed a "beat box" .wav file at the input and get
the corresponding .wav or .mid file at the output. All digital
processing can be done fully off-line, so all timing and amplitude info
is there in advance.
9:31 a.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
Massy,
On 23/09/2011 04:07, S. Massy wrote:
On Thu, Sep 22, 2011 at 09:38:51PM +0000, Fons
Adriaensen wrote:
Of course. As far as I can read nobody recommended PD "over" SC, csound
or any other environment application. Personaly I mention PD quite often
as it's what I mostly use (and know) these days.
Lorenzo.
On Thu, Sep 22, 2011 at 11:42:05PM +0400, Artem
Vakhitov wrote:
Just idle curiosity, but
why do you guys recommend PD over SC or csound?
I had the idea they were more or less equally suited. On 22.09.2011 23:16, Fons Adriaensen wrote:
Even if it hasn't to work in real time Pd is probably the
ideal tool to prototype such a system. The alternative If you need not only the timing but also to
control volume
then it's unlikely this can be done without delay. The part
of the input that would contain usable information to control
volume would very probably come after the trigger, but to
play the sample you need both. The only solution then is to
delay the trigger. That means that simple solutions such as
the ladspa plugin can't do what you want.
The thing is, I do not need to do that in any kind of real time. It
would be sufficient to feed a "beat box" .wav file at the input and get
the corresponding .wav or .mid file at the output. All digital
processing can be done fully off-line, so all timing and amplitude info
is there in advance.
Cheers,
S.M.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:21 a.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On Thu, Sep 22, 2011 at 10:07:22PM -0400, S. Massy wrote:
Just idle curiosity, but why do you guys recommend PD
over SC or csound?
I had the idea they were more or less equally suited.
For someone who knows them well, yes.
But in the other case, if you have to learn one of them
from scratch just to solve a particular problem, I'm pretty
sure that Pd is the easier way to go. And that is *not* just
because it has a graphical user interface.
Take SC. I love the way the synthesis engine works and can
be controlled using OSC. But, even as a programmer, that is
someone used to writing formal instructions and descriptions
in a text based format, I have to *fight* the SC language all
the time. IMHO it's a mess, and it seems to be designed to
allow spectacular one-liners rather than for clarity and
consistency. I'm using it now only to write synthdefs, for
all the rest I use Python.
Ciao,
--
FA
5:31 p.m.
On Fri, Sep 23, 2011 at 09:21:45AM +0000, Fons Adriaensen wrote:
On Thu, Sep 22, 2011 at 10:07:22PM -0400, S. Massy
wrote:
Thanks. I was just curious, since PD is the only one of
the major
synthesis engines I haven't played with (because of its graphical
nature). And I do catch your drift about SC. In fact, it seems to be a
common sin of all those languages, as they seem to evolve out of need
(functionality) rather than design (semantics): it can be good or bad,
but usually is confusing to the newcomer, whatever else it is.
Cheers,
S.M.
Just idle curiosity, but why do you guys
recommend PD over SC or csound?
I had the idea they were more or less equally suited.
For someone who knows them well, yes.
But in the other case, if you have to learn one of them
from scratch just to solve a particular problem, I'm pretty
sure that Pd is the easier way to go. And that is *not* just
because it has a graphical user interface.
Take SC. I love the way the synthesis engine works and can
be controlled using OSC. But, even as a programmer, that is
someone used to writing formal instructions and descriptions
in a text based format, I have to *fight* the SC language all
the time. IMHO it's a mess, and it seems to be designed to
allow spectacular one-liners rather than for clarity and
consistency. I'm using it now only to write synthdefs, for
all the rest I use Python. 
10:41 p.m.
On Fri, 23 Sep 2011 09:21:45 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
Take SC. I love the way the synthesis engine works and
can
be controlled using OSC. But, even as a programmer, that is
someone used to writing formal instructions and descriptions
in a text based format, I have to *fight* the SC language all
the time. IMHO it's a mess, and it seems to be designed to
allow spectacular one-liners rather than for clarity and
consistency.
I feel the same way.
I'm using it now only to write synthdefs, for
all the rest I use Python.
I'm a noob on this, and I think I don't really get what parts of the SC
I know are sclang and what scsynth. Using Python and OSC I guess you
can easilly play SynthDefs (because these are loaded on the server and
anyhow sclang communicates with OSC to the server), but do you loose all
the other nice stuff like Ugens, Tasks, Routines, Patterns?
I'd be so happy to be able to use supercollider's functionality in
python.
cheers
renato
11:15 p.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On Fri, Sep 23, 2011 at 10:40:20PM +0200, Renato wrote:
On Fri, 23 Sep 2011 09:21:45 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
That's part of the problem. It is possible to use sclang in
a way that makes the language/engine separation explicit.
But then not much remains of the language.
Take SC. I love the way the synthesis engine
works and can
be controlled using OSC. But, even as a programmer, that is
someone used to writing formal instructions and descriptions
in a text based format, I have to *fight* the SC language all
the time. IMHO it's a mess, and it seems to be designed to
allow spectacular one-liners rather than for clarity and
consistency.
I feel the same way.
I'm using it now only to write synthdefs, for
all the rest I use Python.
I'm a noob on this, and I think I don't really get what parts of the SC
I know are sclang and what scsynth. Using Python and OSC I guess you can easilly play
SynthDefs (because
these are loaded on the server and anyhow sclang communicates with
OSC to the server), but do you loose all the other nice stuff like
Ugens, Tasks, Routines, Patterns?
Ugens are part of SynthDefs, they are an engine side thing. The others,
Tasks, Routines, Patterns you can do as well in Python, and then at
least you know what's happening. Patterns can be tricky, the easiest
way to do something similar is using Stackless Python.
That assumes you want patterns, most of the time I don't want them
and I'm thinking more in terms of a events on a timeline, or a set
of timelines. That is one thing that sclang does not support very well
- all the attention of its creators/developers is on patterns. You
are more or less forced to think in that way unless you need only
very basic functionality.
BTW, I'm still waiting for a basic description of Tasks, Routines, tne
'.fork' method and whatever else sclang has to offer for concurrent
execution. Are these coroutines, application level threads, system level
threads, or what ? '.fork' suggest it's creating a new process but I'm
pretty sure it doesn't. Etc. Etc.
Ciao,
--
FA
24 Sep
24 Sep
1:21 a.m.
On Fri, Sep 23, 2011 at 09:15:27PM +0000, Fons Adriaensen wrote:
least you know what's happening. Patterns can be
tricky, the easiest
way to do something similar is using Stackless Python.
That assumes you want patterns, most of the time I don't want them
and I'm thinking more in terms of a events on a timeline, or a set
of timelines. That is one thing that sclang does not support very well
- all the attention of its creators/developers is on patterns. You
are more or less forced to think in that way unless you need only
very basic functionality.
You might give ChucK a whirl, if you haven't yet. It
sounds like its
philosophy might better resonate with yours. Though I don't think it has
all the functionalities SC does.
Cheers,
S.M.
5:17 p.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On Fri, Sep 23, 2011 at 07:21:36PM -0400, S. Massy wrote:
You might give ChucK a whirl, if you haven't yet.
It sounds like its
philosophy might better resonate with yours. Though I don't think it has
all the functionalities SC does.
Will give it a try again once it has decent Jack support.
Ciao,
--
FA
23 Sep
23 Sep
9:38 a.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
Hi Fons,
On 22/09/2011 23:38, Fons Adriaensen wrote:
On Thu, Sep 22, 2011 at 11:42:05PM +0400, Artem
Vakhitov wrote:
I don't quite get what the delay is needed for. To sync with the
envelope follower?
On 22.09.2011 23:16, Fons Adriaensen wrote:
Even if it hasn't to work in real time Pd is probably the
ideal tool to prototype such a system. The alternative
would be to write some ad-hoc C/C++ code, possibly using
existing 'feature extraction' libraries or plugin code.
As a first guess, what you need would be:
- (optional) some pre-filtering to make the trigger
more reliable,
- the trigger itself,
- a delay on the trigger, If you need not only the timing but also to
control volume
then it's unlikely this can be done without delay. The part
of the input that would contain usable information to control
volume would very probably come after the trigger, but to
play the sample you need both. The only solution then is to
delay the trigger. That means that simple solutions such as
the ladspa plugin can't do what you want.
The thing is, I do not need to do that in any kind of real time. It
would be sufficient to feed a "beat box" .wav file at the input and get
the corresponding .wav or .mid file at the output. All digital
processing can be done fully off-line, so all timing and amplitude info
is there in advance.
and in parallel
- (optional) some pre-filtering for the envelope
follower,
- an envelope follower,
- when the delayed trigger arrives, read the envelope
follower and start the sample playback.
Ciao,
Lorenzo
10:54 a.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On Fri, Sep 23, 2011 at 09:39:56AM +0200, Lorenzo Sutton wrote:
To give the envelope follower (or other feature extraction
algorithm) the time to produce a reliable value. This takes
finite time, and with sounds that have a clear onset (as
required for good trigger timing) you can't use the signal
before the trigger point.
Ciao,
--
FA
- (optional)
some pre-filtering to make the trigger
more reliable,
- the trigger itself,
- a delay on the trigger,
I don't quite get what the delay is needed for. To sync with the
envelope follower? 
10:19 a.m.
Hi,
On Thu, Sep 22, 2011 at 09:38:51PM +0000, Fons Adriaensen wrote:
Even if it hasn't to work in real time Pd is
probably the
ideal tool to prototype such a system. The alternative
would be to write some ad-hoc C/C++ code, possibly using
existing 'feature extraction' libraries or plugin code.
As a first guess, what you need would be:
- (optional) some pre-filtering to make the trigger
more reliable,
- the trigger itself,
- a delay on the trigger,
and in parallel
- (optional) some pre-filtering for the envelope
follower,
- an envelope follower,
- when the delayed trigger arrives, read the envelope
follower and start the sample playback.
There is an object included in Pd to do quite good onset detections for
percussive sounds, it's called [bonk~]. Another object, [sigmund~], is a
pitch tracker for pitched sounds, but it also detects onsets.
A nice thing about bonk~ is that it can be trained to discriminate
between different kinds of sounds, so for example it can be made to
trigger different samples if you sing "pah" versus singing "tschk".
Another apprroach would be to use some software based on the aubio
library (like the Pd external)
Ciao
--
Frak
22 Sep
22 Sep
9:41 p.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On 22.09.2011 23:06, Lorenzo Sutton wrote:
I'll give it a try (although I never used the
LADSPA plugin version): A
trigger is usually quite simple. It "monitors" an input signal, when the
signal's amplitude goes above the threshold (which you set) it will play
(trigger) the chosen sample. The hold parameter (usually measured in
milliseconds) is important because it sets how long the Trigger remains
inactive (holds) after it triggered this avoids re-triggering the sample
too quickly especially if the input signal remains above the threshold
for too long.
Thanks for the explanation, it all makes more sense now.
Here is an very simple example of what you're
probably thinking of:
http://lorenzosu.altervista.org/temp/dump/trigger_test.ogg
Hard panned left is the audio input (in this case
it's not my voice but
me tapping on my crap laptop mic) hard right the triggered sample. You
can noticed some taps are "missed" this is because they were below
threshold (too quiet). The hold was at 80 ms (excuse the horrible
quality of the audio input quickly made on my laptop and it's night here..)
Wow, this seems to work well for the triggering part!
Well I made a very simple trigger for PD [1] a while
ago (to be used
mainly with ardour - used for the above example).
Lorenzo
[1] http://lorenzosu.altervista.org/pd/trigger/
Thank you for the link, I have just never got around to learning PD yet :-)
Regards,
Artem
21 Oct
21 Oct
2:26 p.m.
New subject: Voice-to-drums in general and the Trigger LADSPA in particular
On 22.09.2011 21:05, Artem Vakhitov wrote:
I am in search of a more or less easy way to do
voice-to-drums - that
is, to trigger drum samples (MIDI or otherwise) and control their volume
(velocity) using my voice recorded from a microphone. Real-time is not
necessary, and neither is multi-sample capability. The objective is to
create more lively, groovy drum loops, which I can emulate with my voice.
To reply to myself, reviving this old thread: I have found a more or
less OOTB solution for voice-to-drums, albeit for Windows. It is called
KTDrumTrigger and is a freeware VST plugin. It works inside Reaper, so
there is a chance for it working on Linux - within Reaper or other hosts
that support Windows VST using Wine.
Artem
4582
days inactive
4611
days old
linux-audio-user@lists.linuxaudio.org
17 comments
6 participants
participants (6)
-
Artem Vakhitov -
Fons Adriaensen -
Frank Barknecht -
Lorenzo Sutton -
Renato -
S. Massy