3 Jun
2005
3 Jun
'05
11:01 a.m.
Assembling piezo microphones, cardboard, foam, wood
and a cymbal stand,
I have just made my first DIY electronic pads. Actually it's electronic
percussions, because I will play these mostly with hands.
I've found a few sites about DIY "edrums" (1), as well as some detailed
documentation about how to build a trigger-to-midi hardware controller
(2). But since I started this little project, I've been thinking about
plugging the piezo mikes directly into my soundcard inputs. My first
tests are very good : the signal is clean, and indicates faithfully how
hard the pads get hit.
Hi,
There will be a lot of developments in smack in the coming months on modeling hand drums
and i think you might get some good results with your triggers and smack. You can also try
pluggin the audio out of your triggers and the excitation signal for the physical modeling
drums in smack. This would allow you to get a level of control that is very difficult with
midi/osc in that it directly uses the attack/release/velocity etc of your triggers in the
sound.
Give me a yell if you want a hand with using them like that, as i'd love the testing.
Loki
6 Jun
6 Jun
8:05 a.m.
Hi Lachlan,
Lachlan Davison wrote:
I'm a bit lost now... There seem to be many opinions on how to use these pads.
I'm usually not really into synthetizing/modeling, more into using samples. But
I've been told that using a convolution engine as BruteFIR I could be able to
apply the signature of any sound to the raw signal that comes out of the pad.
With this convolution approach, no need to "trigger" anything anymore, just use
the signal as it is, and run it through the convolution engine. But BruteFIR
seems like a complex tool, and I currently have no knowledge about so-called
convolution.
If Smack is part of your thesis, as I read on your website, I'd recommend that
you build some pads, similar to mine. This way you should be able to tune Smack
much easier, so that it becomes a more giggable tool, using the pads.
Once you get this working, just drop me a mail so that I give it a try, from a
drummer point of view.
All that said, I must confess that I still believe that triggering is the only
real choice according to my needs. This would need such settings as
gain/xtalk/threshold in order to correctly convert the raw pad signal into a
such "trigger" event. This may be much harder to achieve than it sounds (1).
And I now think that this trigger-detection engine should indeed output midi, so
that you can plug into many different devices/applications. Now, once a midi
signal is issued, and ends up playing a sample or synthetizing a sound, nothing
forbids to further exploitate the original signal, as in the following diagram :
pad signal -----> trigger to midi conversion -----> sampler/expander
| |
| |
+-----------------------> effect filter <--------------+
|
+----> final sound
The "sample/expander" could either be a sampler as Specimen, or a synthetizer as
Smack.
Then, the "effect filter", could reuse the original pad signal form and
caracteristics in order to alter what's coming out of the
"sampler/expander".
Velocity may happen at the midi level, but other complex caracteristics that are
carried buy the original signal pad could be fed into a convolution engine,
into some dedicated Smack routines, or even into some LADSPA plugin.
I'm not sure about all of this, just ideas for now... While these ideas get more
precise, I may buy myself some Roland/Alesis dedicated hardware, with some
effect pedal in order to actually do music ;-)
References :
(1) See the Alesis DM-5 manual, section "About trigger parameters", page 40 :
http://www.alesis.com/downloads/manuals/DM5_Manual.pdf
--
og
Assembling
piezo microphones, cardboard, foam, wood and a cymbal stand,
I have just made my first DIY electronic pads. Actually it's electronic
percussions, because I will play these mostly with hands.
Hi,
There will be a lot of developments in smack in the coming months on modeling hand drums
and i think you might get some good results with your triggers and smack. You can also try
pluggin the audio out of your triggers and the excitation signal for the physical modeling
drums in smack. This would allow you to get a level of control that is very difficult with
midi/osc in that it directly uses the attack/release/velocity etc of your triggers in the
sound.
Give me a yell if you want a hand with using them like that, as i'd love the testing.
8:16 a.m.
On Mon, Jun 06, 2005 at 12:05:24PM +0200, Olivier Guilyardi wrote:
And I now think that this trigger-detection engine
should indeed output
midi, so that you can plug into many different devices/applications. Now,
once a midi signal is issued, and ends up playing a sample or synthetizing
a sound, nothing forbids to further exploitate the original signal, as in
the following diagram :
pad signal -----> trigger to midi conversion -----> sampler/expander
| |
| |
+-----------------------> effect filter <--------------+
|
+----> final sound
You'll probably need some delay in the pad signal to effect filter
to compensate for the detour via midi, as probably the pad output
will be quite short.
For really accurate results, you should output a 'trigger' signal
at audio rate, together with some other audio rate signals that
represent measured parameters such as velocity, etc.
If you put this into a LADSPA plugin, some synths (AMS for example)
would be able to use this directly, giving mininal latency and
latency jitter.
--
FA
8:43 a.m.
On Mon, 06 Jun 2005 12:05:24 +0200
Olivier Guilyardi <ml(a)xung.org> wrote:
With this convolution approach, no need to
"trigger" anything anymore, just use
the signal as it is, and run it through the convolution engine. But BruteFIR
seems like a complex tool, and I currently have no knowledge about so-called
convolution.
Hi,
for experiments you might also try my jack_convolve tool, which is a bit
simpler to use..
http://www.affenbande.org/~tapas/wiki/index.php?jack_convolve
BTW: the drawback of the convolution approach would be that it gets very
very expensive (cpu wise) at
- small periodsizes
- long response files
The cpu load is antiproportional to the periodsize and proportional to
the response file length.
OTOH really percussive sounds are rather shortish i assume.
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
11:24 a.m.
Hi Florian,
Florian Schmidt wrote:
On Mon, 06 Jun 2005 12:05:24 +0200
Olivier Guilyardi <ml(a)xung.org> wrote:
I'm running Debian Sarge with a 2.4 kernel, and this libdsp which
jack_convolve depends on is a real problem. libdsp needs nptl threading
style, and that seems to require linux 2.6. I don't know if Debian
supports nptl either.. I just can't compile libdsp.
I'm not going to switch to 2.6 now. I don't have enough time.
I tried removing the "DEFS += -DUSE_NPTL" line from the
libdsp/DynThreads/Makefile, but it ends up complaining about a Mutex.hh
file which does not seem to exists anywhere in the Debian distribution.
Before all of that, I tried to use the libdsp0 and libdsp-dev Debian
packages, but these are both from the 3.3.6 libdsp release, which
jack_convolve does not seem to recognize.
--
og
With this convolution approach, no need to
"trigger" anything anymore, just use
the signal as it is, and run it through the convolution engine. But BruteFIR
seems like a complex tool, and I currently have no knowledge about so-called
convolution.
for experiments you might also try my jack_convolve tool, which is a bit
simpler to use..
3:40 p.m.
On Mon, 06 Jun 2005 15:24:32 +0200
Olivier Guilyardi <ml(a)xung.org> wrote:
Hi Florian,
Hi!
I'm running Debian Sarge with a 2.4 kernel, and
this libdsp which
jack_convolve depends on is a real problem. libdsp needs nptl threading
style, and that seems to require linux 2.6. I don't know if Debian
supports nptl either.. I just can't compile libdsp.
I'm not going to switch to 2.6 now. I don't have enough time.
I tried removing the "DEFS += -DUSE_NPTL" line from the
libdsp/DynThreads/Makefile, but it ends up complaining about a Mutex.hh
file which does not seem to exists anywhere in the Debian distribution.
Before all of that, I tried to use the libdsp0 and libdsp-dev Debian
packages, but these are both from the 3.3.6 libdsp release, which
jack_convolve does not seem to recognize.
For quick tests without libDSP you can tweak the jack_convolve Makefile
a little:
uncomment the
#COMPILE_FLAGS += -DC_CMUL
line and remove "-ldsp" from the LINK_FLAGS line. This will use an
unoptimized C complex multiplication implementation. jack_convolve will
use around 10-20% more cpu than with the libDSP implementation.
I also put the libDSP author on the CC list. Maybe he knows more about
your libDSP-specific problems. Indeed the version packaged with your
debian is too old. You need at least libDSP version 5.0.1 (earlier
versions miss the complex multiply and add function which is needed by
jack_convolve)..
Regards,
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
8 Jun
8 Jun
11:57 a.m.
Hi Florian,
Florian Schmidt wrote:
For quick tests without libDSP you can tweak the
jack_convolve Makefile
a little:
uncomment the
#COMPILE_FLAGS += -DC_CMUL
line and remove "-ldsp" from the LINK_FLAGS line. This will use an
unoptimized C complex multiplication implementation. jack_convolve will
use around 10-20% more cpu than with the libDSP implementation.
It did compile. I also needed to remove the #include <dsp/dspop.h> in
convolve.c
Okay, so I now have an idea of what convolution is. Your little piece of
software is very nice, very easy to understand. I used three samples : a
bassdrum, a snare drum, and a short guitar chord. I plugged the output
of one of my pads into jack_convolve's input and its output into the
alsa_pcm playback.
Both the bassdrum and the chord sounded quite nice. But the snare drum
sounded like very far away. I guess this comes from the silence at the
end of this sample.
What exactly happens with these "response files" ? Should I use very
simple samples, like a sine wave with no silence ? Shouldn't convolving
be coupled with trigerring ? I mean : hitting the pad would start the
sample playback, and the convolving engine would use both this sample
playback and the pad signal to produce its output. In this case,
jack_convolve would then need one output and two inputs :
- one for the pad signal,
- and one for the "response signal", that is : the sample playback that
started right when the pad got hit
Is this possible, or do I misunderstand convolution here ?
Regards
--
og
7052
days inactive
7057
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Alfons Adriaensen -
Florian Schmidt -
Lachlan Davison -
Olivier Guilyardi