6 Jul
2006
6 Jul
'06
7:41 p.m.
ALSA MIDI Humanizer is a tiny application that route MIDI events between
two applications adding random timing and velocity offsets to NOTEON and
NOTEOFF events, with a bare bones GUI to adjust the two ranges.
More infos here:
http://www.cesaremarilungo.com/blog/?post=17
Download:
http://www.cesaremarilungo.com/download/ALSA-MIDI-Humanizer-0.0.1.tar.gz
To build it just 'make'.
For the developers reading this list: at the moment the code is just a
quick hack. I didn't know anything about ALSA develpment, the GTK+
toolkit and linux threads until this morning when I've started studying
some tutorials (used the midirouter.c code from the ALSA tutorial by
Matthias Nagorni as a starting point). So, be kind.
Comments and suggestions are highly appreciated.
Thank you!
c.
--
www.cesaremarilungo.com
6 Jul
6 Jul
8:04 p.m.
Really interesting idea. I can't wait to play with it.
I am using Fedora Core 5. This could be just the results of my being
inexperienced at compiling, here is the console output of the make
command:
------------------------
[me@mycomp ALSA-MIDI-Humanizer-0.0.1]$ make
make: Warning: File `Makefile' has modification time 7.6e+02 s in the
future
gcc humanizer.c -o humanizer -lasound -lpthread `pkg-config --cflags
--libs gtk+-2.0`
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtk+-2.0' found
humanizer.c:15:21: error: gtk/gtk.h: No such file or directory
humanizer.c:33: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
humanizer.c:34: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
humanizer.c:127: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘delete_event’
humanizer.c: In function ‘updateSettings’:
humanizer.c:138: error: ‘spinnerT’ undeclared (first use in this
function)
humanizer.c:138: error: (Each undeclared identifier is reported only
once
humanizer.c:138: error: for each function it appears in.)
humanizer.c:139: error: ‘spinnerV’ undeclared (first use in this
function)
humanizer.c: At top level:
humanizer.c:142: error: expected ‘)’ before ‘*’ token
humanizer.c:148: error: expected ‘)’ before ‘*’ token
humanizer.c: In function ‘main’:
humanizer.c:158: error: ‘GtkWidget’ undeclared (first use in this
function)
humanizer.c:158: error: ‘window’ undeclared (first use in this function)
humanizer.c:159: error: ‘button’ undeclared (first use in this function)
humanizer.c:160: error: ‘main_vbox’ undeclared (first use in this
function)
humanizer.c:160: error: ‘hbox’ undeclared (first use in this function)
humanizer.c:161: error: ‘GtkObject’ undeclared (first use in this
function)
humanizer.c:161: error: ‘adj1’ undeclared (first use in this function)
humanizer.c:161: error: ‘adj2’ undeclared (first use in this function)
humanizer.c:164: error: ‘frame’ undeclared (first use in this function)
humanizer.c:174: error: ‘GTK_WINDOW_TOPLEVEL’ undeclared (first use in
this function)
humanizer.c:177: error: ‘delete_event’ undeclared (first use in this
function)
humanizer.c:181: error: ‘FALSE’ undeclared (first use in this function)
humanizer.c:186: error: ‘TRUE’ undeclared (first use in this function)
humanizer.c:195: error: ‘scaleT’ undeclared (first use in this function)
humanizer.c:201: error: ‘spinnerT’ undeclared (first use in this
function)
humanizer.c:208: error: ‘cb_update_spinner’ undeclared (first use in
this function)
humanizer.c:208: error: ‘gpointer’ undeclared (first use in this
function)
humanizer.c:208: error: expected ‘)’ before ‘spinnerT’
humanizer.c:211: error: ‘cb_update_scale’ undeclared (first use in this
function)
humanizer.c:211: error: expected ‘)’ before ‘adj1’
humanizer.c:230: error: ‘scaleV’ undeclared (first use in this function)
humanizer.c:236: error: ‘spinnerV’ undeclared (first use in this
function)
humanizer.c:243: error: expected ‘)’ before ‘spinnerV’
humanizer.c:246: error: expected ‘)’ before ‘adj1’
make: *** [all] Error 1
------------------------
On Thu, 2006-07-06 at 23:42 +0000, Cesare Marilungo wrote:
ALSA MIDI Humanizer is a tiny application that route
MIDI events between
two applications adding random timing and velocity offsets to NOTEON and
NOTEOFF events, with a bare bones GUI to adjust the two ranges.
More infos here:
http://www.cesaremarilungo.com/blog/?post=17
Download:
http://www.cesaremarilungo.com/download/ALSA-MIDI-Humanizer-0.0.1.tar.gz
To build it just 'make'.
For the developers reading this list: at the moment the code is just a
quick hack. I didn't know anything about ALSA develpment, the GTK+
toolkit and linux threads until this morning when I've started studying
some tutorials (used the midirouter.c code from the ALSA tutorial by
Matthias Nagorni as a starting point). So, be kind.
Comments and suggestions are highly appreciated.
Thank you!
c.
8:10 p.m.
Jordan Nash wrote:
Really interesting idea. I can't wait to play with
it.
I am using Fedora Core 5. This could be just the results of my being
inexperienced at compiling, here is the console output of the make
command:
------------------------
[me@mycomp ALSA-MIDI-Humanizer-0.0.1]$ make
make: Warning: File `Makefile' has modification time 7.6e+02 s in the
future
gcc humanizer.c -o humanizer -lasound -lpthread `pkg-config --cflags
--libs gtk+-2.0`
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
You lack the gtk+2 development libraries or you should set the
PKG_CONFIG_PATH.
Check if you have the file 'gtk+-2.0.pc' in /usr/lib/pkgconfig or
/usr/local/lib/pkgconfig.
c.
No package 'gtk+-2.0' found
humanizer.c:15:21: error: gtk/gtk.h: No such file or directory
humanizer.c:33: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
humanizer.c:34: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
humanizer.c:127: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘delete_event’
humanizer.c: In function ‘updateSettings’:
humanizer.c:138: error: ‘spinnerT’ undeclared (first use in this
function)
humanizer.c:138: error: (Each undeclared identifier is reported only
once
humanizer.c:138: error: for each function it appears in.)
humanizer.c:139: error: ‘spinnerV’ undeclared (first use in this
function)
humanizer.c: At top level:
humanizer.c:142: error: expected ‘)’ before ‘*’ token
humanizer.c:148: error: expected ‘)’ before ‘*’ token
humanizer.c: In function ‘main’:
humanizer.c:158: error: ‘GtkWidget’ undeclared (first use in this
function)
humanizer.c:158: error: ‘window’ undeclared (first use in this function)
humanizer.c:159: error: ‘button’ undeclared (first use in this function)
humanizer.c:160: error: ‘main_vbox’ undeclared (first use in this
function)
humanizer.c:160: error: ‘hbox’ undeclared (first use in this function)
humanizer.c:161: error: ‘GtkObject’ undeclared (first use in this
function)
humanizer.c:161: error: ‘adj1’ undeclared (first use in this function)
humanizer.c:161: error: ‘adj2’ undeclared (first use in this function)
humanizer.c:164: error: ‘frame’ undeclared (first use in this function)
humanizer.c:174: error: ‘GTK_WINDOW_TOPLEVEL’ undeclared (first use in
this function)
humanizer.c:177: error: ‘delete_event’ undeclared (first use in this
function)
humanizer.c:181: error: ‘FALSE’ undeclared (first use in this function)
humanizer.c:186: error: ‘TRUE’ undeclared (first use in this function)
humanizer.c:195: error: ‘scaleT’ undeclared (first use in this function)
humanizer.c:201: error: ‘spinnerT’ undeclared (first use in this
function)
humanizer.c:208: error: ‘cb_update_spinner’ undeclared (first use in
this function)
humanizer.c:208: error: ‘gpointer’ undeclared (first use in this
function)
humanizer.c:208: error: expected ‘)’ before ‘spinnerT’
humanizer.c:211: error: ‘cb_update_scale’ undeclared (first use in this
function)
humanizer.c:211: error: expected ‘)’ before ‘adj1’
humanizer.c:230: error: ‘scaleV’ undeclared (first use in this function)
humanizer.c:236: error: ‘spinnerV’ undeclared (first use in this
function)
humanizer.c:243: error: expected ‘)’ before ‘spinnerV’
humanizer.c:246: error: expected ‘)’ before ‘adj1’
make: *** [all] Error 1
------------------------
On Thu, 2006-07-06 at 23:42 +0000, Cesare Marilungo wrote:
--
www.cesaremarilungo.com
ALSA MIDI Humanizer is a tiny application that
route MIDI events between
two applications adding random timing and velocity offsets to NOTEON and
NOTEOFF events, with a bare bones GUI to adjust the two ranges.
More infos here:
http://www.cesaremarilungo.com/blog/?post=17
Download:
http://www.cesaremarilungo.com/download/ALSA-MIDI-Humanizer-0.0.1.tar.gz
To build it just 'make'.
For the developers reading this list: at the moment the code is just a
quick hack. I didn't know anything about ALSA develpment, the GTK+
toolkit and linux threads until this morning when I've started studying
some tutorials (used the midirouter.c code from the ALSA tutorial by
Matthias Nagorni as a starting point). So, be kind.
Comments and suggestions are highly appreciated.
Thank you!
c.
9:11 p.m.
OK, I got it to run now.
How do I get it to route midi information, though? I have it set to go
between Rosegarden and ZynAddSubFX, but it doesn't seem to pass on the
information. I've also tried to put it between the Virtual Keyboard and
ZynAddSubFX, but I can't seem to get it to pass on the MIDI data.
-Jordan
On Fri, 2006-07-07 at 00:10 +0000, Cesare Marilungo wrote:
Jordan Nash wrote:
Really interesting idea. I can't wait to play
with it.
I am using Fedora Core 5. This could be just the results of my being
inexperienced at compiling, here is the console output of the make
command:
------------------------
[me@mycomp ALSA-MIDI-Humanizer-0.0.1]$ make
make: Warning: File `Makefile' has modification time 7.6e+02 s in the
future
gcc humanizer.c -o humanizer -lasound -lpthread `pkg-config --cflags
--libs gtk+-2.0`
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
You lack the gtk+2 development libraries or you should set the
PKG_CONFIG_PATH.
Check if you have the file 'gtk+-2.0.pc' in /usr/lib/pkgconfig or
/usr/local/lib/pkgconfig.
c.
No package 'gtk+-2.0' found
humanizer.c:15:21: error: gtk/gtk.h: No such file or directory
humanizer.c:33: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
humanizer.c:34: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
humanizer.c:127: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘delete_event’
humanizer.c: In function ‘updateSettings’:
humanizer.c:138: error: ‘spinnerT’ undeclared (first use in this
function)
humanizer.c:138: error: (Each undeclared identifier is reported only
once
humanizer.c:138: error: for each function it appears in.)
humanizer.c:139: error: ‘spinnerV’ undeclared (first use in this
function)
humanizer.c: At top level:
humanizer.c:142: error: expected ‘)’ before ‘*’ token
humanizer.c:148: error: expected ‘)’ before ‘*’ token
humanizer.c: In function ‘main’:
humanizer.c:158: error: ‘GtkWidget’ undeclared (first use in this
function)
humanizer.c:158: error: ‘window’ undeclared (first use in this function)
humanizer.c:159: error: ‘button’ undeclared (first use in this function)
humanizer.c:160: error: ‘main_vbox’ undeclared (first use in this
function)
humanizer.c:160: error: ‘hbox’ undeclared (first use in this function)
humanizer.c:161: error: ‘GtkObject’ undeclared (first use in this
function)
humanizer.c:161: error: ‘adj1’ undeclared (first use in this function)
humanizer.c:161: error: ‘adj2’ undeclared (first use in this function)
humanizer.c:164: error: ‘frame’ undeclared (first use in this function)
humanizer.c:174: error: ‘GTK_WINDOW_TOPLEVEL’ undeclared (first use in
this function)
humanizer.c:177: error: ‘delete_event’ undeclared (first use in this
function)
humanizer.c:181: error: ‘FALSE’ undeclared (first use in this function)
humanizer.c:186: error: ‘TRUE’ undeclared (first use in this function)
humanizer.c:195: error: ‘scaleT’ undeclared (first use in this function)
humanizer.c:201: error: ‘spinnerT’ undeclared (first use in this
function)
humanizer.c:208: error: ‘cb_update_spinner’ undeclared (first use in
this function)
humanizer.c:208: error: ‘gpointer’ undeclared (first use in this
function)
humanizer.c:208: error: expected ‘)’ before ‘spinnerT’
humanizer.c:211: error: ‘cb_update_scale’ undeclared (first use in this
function)
humanizer.c:211: error: expected ‘)’ before ‘adj1’
humanizer.c:230: error: ‘scaleV’ undeclared (first use in this function)
humanizer.c:236: error: ‘spinnerV’ undeclared (first use in this
function)
humanizer.c:243: error: expected ‘)’ before ‘spinnerV’
humanizer.c:246: error: expected ‘)’ before ‘adj1’
make: *** [all] Error 1
------------------------
On Thu, 2006-07-06 at 23:42 +0000, Cesare Marilungo wrote:
ALSA MIDI Humanizer is a tiny application that
route MIDI events between
two applications adding random timing and velocity offsets to NOTEON and
NOTEOFF events, with a bare bones GUI to adjust the two ranges.
More infos here:
http://www.cesaremarilungo.com/blog/?post=17
Download:
http://www.cesaremarilungo.com/download/ALSA-MIDI-Humanizer-0.0.1.tar.gz
To build it just 'make'.
For the developers reading this list: at the moment the code is just a
quick hack. I didn't know anything about ALSA develpment, the GTK+
toolkit and linux threads until this morning when I've started studying
some tutorials (used the midirouter.c code from the ALSA tutorial by
Matthias Nagorni as a starting point). So, be kind.
Comments and suggestions are highly appreciated.
Thank you!
c.
9:18 p.m.
Jordan Nash wrote:
OK, I got it to run now.
How do I get it to route midi information, though? I have it set to go
between Rosegarden and ZynAddSubFX, but it doesn't seem to pass on the
information. I've also tried to put it between the Virtual Keyboard and
ZynAddSubFX, but I can't seem to get it to pass on the MIDI data.
-Jordan
You can use qjackctl to connect Rosegarden MIDI output to it, and its
output to Zyn input.
c.
On Fri, 2006-07-07 at 00:10 +0000, Cesare Marilungo
wrote:
--
www.cesaremarilungo.com
Jordan Nash wrote:
Really interesting idea. I can't wait to play
with it.
I am using Fedora Core 5. This could be just the results of my being
inexperienced at compiling, here is the console output of the make
command:
------------------------
[me@mycomp ALSA-MIDI-Humanizer-0.0.1]$ make
make: Warning: File `Makefile' has modification time 7.6e+02 s in the
future
gcc humanizer.c -o humanizer -lasound -lpthread `pkg-config --cflags
--libs gtk+-2.0`
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
You lack the gtk+2 development libraries or you should set the
PKG_CONFIG_PATH.
Check if you have the file 'gtk+-2.0.pc' in /usr/lib/pkgconfig or
/usr/local/lib/pkgconfig.
c.
No package 'gtk+-2.0' found
humanizer.c:15:21: error: gtk/gtk.h: No such file or directory
humanizer.c:33: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
humanizer.c:34: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘*’ token
humanizer.c:127: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘delete_event’
humanizer.c: In function ‘updateSettings’:
humanizer.c:138: error: ‘spinnerT’ undeclared (first use in this
function)
humanizer.c:138: error: (Each undeclared identifier is reported only
once
humanizer.c:138: error: for each function it appears in.)
humanizer.c:139: error: ‘spinnerV’ undeclared (first use in this
function)
humanizer.c: At top level:
humanizer.c:142: error: expected ‘)’ before ‘*’ token
humanizer.c:148: error: expected ‘)’ before ‘*’ token
humanizer.c: In function ‘main’:
humanizer.c:158: error: ‘GtkWidget’ undeclared (first use in this
function)
humanizer.c:158: error: ‘window’ undeclared (first use in this function)
humanizer.c:159: error: ‘button’ undeclared (first use in this function)
humanizer.c:160: error: ‘main_vbox’ undeclared (first use in this
function)
humanizer.c:160: error: ‘hbox’ undeclared (first use in this function)
humanizer.c:161: error: ‘GtkObject’ undeclared (first use in this
function)
humanizer.c:161: error: ‘adj1’ undeclared (first use in this function)
humanizer.c:161: error: ‘adj2’ undeclared (first use in this function)
humanizer.c:164: error: ‘frame’ undeclared (first use in this function)
humanizer.c:174: error: ‘GTK_WINDOW_TOPLEVEL’ undeclared (first use in
this function)
humanizer.c:177: error: ‘delete_event’ undeclared (first use in this
function)
humanizer.c:181: error: ‘FALSE’ undeclared (first use in this function)
humanizer.c:186: error: ‘TRUE’ undeclared (first use in this function)
humanizer.c:195: error: ‘scaleT’ undeclared (first use in this function)
humanizer.c:201: error: ‘spinnerT’ undeclared (first use in this
function)
humanizer.c:208: error: ‘cb_update_spinner’ undeclared (first use in
this function)
humanizer.c:208: error: ‘gpointer’ undeclared (first use in this
function)
humanizer.c:208: error: expected ‘)’ before ‘spinnerT’
humanizer.c:211: error: ‘cb_update_scale’ undeclared (first use in this
function)
humanizer.c:211: error: expected ‘)’ before ‘adj1’
humanizer.c:230: error: ‘scaleV’ undeclared (first use in this function)
humanizer.c:236: error: ‘spinnerV’ undeclared (first use in this
function)
humanizer.c:243: error: expected ‘)’ before ‘spinnerV’
humanizer.c:246: error: expected ‘)’ before ‘adj1’
make: *** [all] Error 1
------------------------
On Thu, 2006-07-06 at 23:42 +0000, Cesare Marilungo wrote:
ALSA MIDI Humanizer is a tiny application that
route MIDI events between
two applications adding random timing and velocity offsets to NOTEON and
NOTEOFF events, with a bare bones GUI to adjust the two ranges.
More infos here:
http://www.cesaremarilungo.com/blog/?post=17
Download:
http://www.cesaremarilungo.com/download/ALSA-MIDI-Humanizer-0.0.1.tar.gz
To build it just 'make'.
For the developers reading this list: at the moment the code is just a
quick hack. I didn't know anything about ALSA develpment, the GTK+
toolkit and linux threads until this morning when I've started studying
some tutorials (used the midirouter.c code from the ALSA tutorial by
Matthias Nagorni as a starting point). So, be kind.
Comments and suggestions are highly appreciated.
Thank you!
c.
9:45 p.m.
--- Cesare Marilungo <cesare(a)poeticstudios.com> wrote:
ALSA MIDI Humanizer is a tiny application that route
MIDI events between
two applications adding random timing and velocity offsets to NOTEON and
[...]
For the developers reading this list: at the moment
the code is just a
quick hack. I didn't know anything about ALSA develpment, the GTK+
toolkit and linux threads until this morning when I've started studying
some tutorials (used the midirouter.c code from the ALSA tutorial by
Matthias Nagorni as a starting point). So, be kind.
Comments and suggestions are highly appreciated.
Interesting idea, though I'm not sure adding random delays
really "humanizes" things. Of course I realize this is mostly
something you've put together as a learning exercise. BTW,
in case you're interested in reading some ramblings of another
beginning ALSA MIDI programmer (me), you might check out this:
http://www.geocities.com/smcameron/linux-audio-notes.html, which
is kind of a log I've kept for the last year or so.
Maybe there are some interesting links in there, if nothing
else, or maybe some humor at my expense, LOL.
For a humanizing type feature of my drum machine application,
I added a per instrument (per note, really, as MIDI drums
instruments are mapped to notes) feature that allows a particular
instrument to "drag" or "rush" which is to say, fire off a little
late, or a little early. My implementation is a little buggy, in
that when dragging or rushing causes an instrument to slip across
a measure boundary, things get a little squirrelly, but the idea
is there. I got that idea from reading a little instructional book
about playing the drums, I guess it's common practice among drommers
to keep some important instruments in fairly strict time, while kind
of messing about with some others.
I guess for a filter app, "rushing" is not really possible, without
a time machine, though "dragging" every other instrument would
amount to the same thing, plus insertion of latency.
-- steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
10:09 p.m.
Stephen Cameron wrote:
--- Cesare Marilungo <cesare(a)poeticstudios.com>
wrote:
Thank you for your suggestions, Steve!
Yes, I'm writing it also as a learning exercise but I plan to actually
use it. I've always used this kind of functionality in cubase.
And yes, "rushing" is not possible without a timemachine. :-)
It could be done inside a sequencer, reading ahead.
Another problem that should be solved is that with the current
implementation a noteon event that has been randomly delayed too much
can happen after the noteoff.
I've also planned to add the possibility to have more channels, each
with its own settings. But it would be interesting if I can define some
filtering rules (like notes and velocity ranges) for each channel. This
is easy.
Give me some time. It's just version 0.0.1! Don't they say to release early?
c.
--
www.cesaremarilungo.com
ALSA MIDI Humanizer is a tiny application that
route MIDI events between
two applications adding random timing and velocity offsets to NOTEON and
[...]
For the developers reading this list: at the
moment the code is just a
quick hack. I didn't know anything about ALSA develpment, the GTK+
toolkit and linux threads until this morning when I've started studying
some tutorials (used the midirouter.c code from the ALSA tutorial by
Matthias Nagorni as a starting point). So, be kind.
Comments and suggestions are highly appreciated.
Interesting idea, though I'm not sure adding random delays
really "humanizes" things. Of course I realize this is mostly
something you've put together as a learning exercise. BTW,
in case you're interested in reading some ramblings of another
beginning ALSA MIDI programmer (me), you might check out this:
http://www.geocities.com/smcameron/linux-audio-notes.html, which
is kind of a log I've kept for the last year or so.
Maybe there are some interesting links in there, if nothing
else, or maybe some humor at my expense, LOL.
For a humanizing type feature of my drum machine application,
I added a per instrument (per note, really, as MIDI drums
instruments are mapped to notes) feature that allows a particular
instrument to "drag" or "rush" which is to say, fire off a little
late, or a little early. My implementation is a little buggy, in
that when dragging or rushing causes an instrument to slip across
a measure boundary, things get a little squirrelly, but the idea
is there. I got that idea from reading a little instructional book
about playing the drums, I guess it's common practice among drommers
to keep some important instruments in fairly strict time, while kind
of messing about with some others.
I guess for a filter app, "rushing" is not really possible, without
a time machine, though "dragging" every other instrument would
amount to the same thing, plus insertion of latency.
-- steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
10:17 p.m.
--- Cesare Marilungo <cesare(a)poeticstudios.com> wrote:
[...]
Give me some time. It's just version 0.0.1!
Don't they say to release early?
Of course. I wasn't meaning to criticize, hope it didn't seem that way.
-- steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
10:29 p.m.
Stephen Cameron wrote:
--- Cesare Marilungo <cesare(a)poeticstudios.com>
wrote:
[...]
I was joking.
c.
Give me some time. It's just version 0.0.1!
Don't they say to release early?
Of course. I wasn't meaning to criticize, hope it didn't seem that way.
-- steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
www.cesaremarilungo.com
7 Jul
7 Jul
7:10 a.m.
Hallo,
Stephen Cameron hat gesagt: // Stephen Cameron wrote:
Interesting idea, though I'm not sure adding
random delays
really "humanizes" things.
Humans, even bad musicians, don't play randomly "wrong", so it is
indeed not exactly humanizing to just add some random deviations. How
to really humanize is an ongoing debate. One interesting concept in
this regard is described in the work of Jeff Blimes and in his concept
of the "Tatum". A short introduction is this paper:
http://ssli.ee.washington.edu/people/bilmes/mypapers/icmc93_paper.pdf
Blimes also did listening tests with various approaches on humanizing
including random, Gaussian variations. These were rejected by most
listeners as "sloppy" and "random" and this approach according to his
paper is the worst one to "humanize".
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
8:47 a.m.
Frank Barknecht wrote:
Hallo,
Stephen Cameron hat gesagt: // Stephen Cameron wrote:
Well, I called it 'humanizer' just because it is how this kind of
functionality in sequencers and drum machines has always been called,
AFAIK. It doesn't pretend to make a track programmed in a sequencer more
human.
However I really find it useful when used with small range settings,
even applied to the kind of tracks that in some music styles (like
electronic music) could also have been left as they were programmed.
As Stephen said, if you just randomize the timing and the velocity of a
sequenced drum track it doesn't sound as a real drummer at all. But you
can program the more audible variations by hand, add a very subtle
randomization to the whole track and use a slightly wider range for the
cymbals.
Anyway, as I said, I've always used this functionality in various
situations (but I can't speak for my own results). It is builtin in
cubase, digital performer and any other commercial software sequencer
I've tried in my life.
Don't think of it as a pretentious attempt to revolutionize computer
music. It's just a little utility app that somebody might find useful in
some situations.
Even more, I believe that an application that sounds just like a real
drummer for instance, is possible, but I'm not really interested in such
thing artistically speaking.
Cheers,
c.
--
www.cesaremarilungo.com
Interesting idea, though I'm not sure adding
random delays
really "humanizes" things.
Humans, even bad musicians, don't play randomly "wrong", so it is
indeed not exactly humanizing to just add some random deviations. How
to really humanize is an ongoing debate. One interesting concept in
this regard is described in the work of Jeff Blimes and in his concept
of the "Tatum". A short introduction is this paper:
http://ssli.ee.washington.edu/people/bilmes/mypapers/icmc93_paper.pdf
Blimes also did listening tests with various approaches on humanizing
including random, Gaussian variations. These were rejected by most
listeners as "sloppy" and "random" and this approach according to his
paper is the worst one to "humanize".
Ciao
8:56 a.m.
Cesare Marilungo wrote:
Frank Barknecht wrote:
I've just found this:
http://www.midi-plugins.de/mplug/mplug-hum.html
This is more or less what I plan to do with this project. Are you
interested?
c.
--
www.cesaremarilungo.com
Hallo,
Stephen Cameron hat gesagt: // Stephen Cameron wrote:
Well, I called it 'humanizer' just because it is how this kind of
functionality in sequencers and drum machines has always been called,
AFAIK. It doesn't pretend to make a track programmed in a sequencer
more human.
However I really find it useful when used with small range settings,
even applied to the kind of tracks that in some music styles (like
electronic music) could also have been left as they were programmed.
As Stephen said, if you just randomize the timing and the velocity of
a sequenced drum track it doesn't sound as a real drummer at all. But
you can program the more audible variations by hand, add a very subtle
randomization to the whole track and use a slightly wider range for
the cymbals.
Anyway, as I said, I've always used this functionality in various
situations (but I can't speak for my own results). It is builtin in
cubase, digital performer and any other commercial software sequencer
I've tried in my life.
Don't think of it as a pretentious attempt to revolutionize computer
music. It's just a little utility app that somebody might find useful
in some situations.
Even more, I believe that an application that sounds just like a real
drummer for instance, is possible, but I'm not really interested in
such thing artistically speaking.
Cheers,
c.
Interesting idea, though I'm not sure adding
random delays
really "humanizes" things.
Humans, even bad musicians, don't play randomly "wrong", so it is
indeed not exactly humanizing to just add some random deviations. How
to really humanize is an ongoing debate. One interesting concept in
this regard is described in the work of Jeff Blimes and in his concept
of the "Tatum". A short introduction is this paper:
http://ssli.ee.washington.edu/people/bilmes/mypapers/icmc93_paper.pdf
Blimes also did listening tests with various approaches on humanizing
including random, Gaussian variations. These were rejected by most
listeners as "sloppy" and "random" and this approach according to
his
paper is the worst one to "humanize".
Ciao
9:09 a.m.
Greetings:
Ah, one of my favorite threads. I compose a lot with MIDI, and
sometimes I like to try making the results sound at least a little more
human. A few (probably obvious) notes :
No human player can play two notes in a row with exactly the same
precision, it's simply not possible. Small-range random changes to
velocity at least help shake up the flatness of MIDI parts. However, if
the range of variation is too wide the randomizations sound pointless.
No human players play with metronomic accuracy, nor is such a thing
desirable from human players. However, the range of variation is a
significant consideration. Set drummers often play the bass drum, snare,
hi-hat, and cymbal in slightly different tempo relations, creating the
various grooves and feels that underlie musical styles.
A "groover" would be a cool piece of software, i.e., something that
shapes the existing music into another rhythmic style, but I don't think
it would be easy to get right.
IMO the best way to humanize MIDI parts is to hand-code their
velocities, note by note where necessary, which means the coder must
have a practical knowledge of performance factors. I also routinely add
a tempo track that loops an asymmetric group of fluctuating tempo
values, like a very narrow-range LFO applied to tempo. Again, if the
width of the range is too great the looseness becomes sloppy, destroying
the intended effect. Usually I keep a range of +/-4 clicks, e.g.
120-121-122-121-120-119. If these values are applied to tempo events at
the level of 16th-note triplets they'll have a nice "upsetting" effect
on the rigidity of the sequencer's tempo.
Dynamics and tempo relativities are profound aspects of any engaging
performance, whether a player plans them in advance or they occur as an
improvised response to the music (and possibly to the other players).
Just some thoughts for further consideration.
Best,
dp
9:21 a.m.
Dave Phillips wrote:
Greetings:
Ah, one of my favorite threads. I compose a lot with MIDI, and
sometimes I like to try making the results sound at least a little
more human. A few (probably obvious) notes :
No human player can play two notes in a row with exactly the same
precision, it's simply not possible. Small-range random changes to
velocity at least help shake up the flatness of MIDI parts. However,
if the range of variation is too wide the randomizations sound pointless.
No human players play with metronomic accuracy, nor is such a thing
desirable from human players. However, the range of variation is a
significant consideration. Set drummers often play the bass drum,
snare, hi-hat, and cymbal in slightly different tempo relations,
creating the various grooves and feels that underlie musical styles.
A "groover" would be a cool piece of software, i.e., something that
shapes the existing music into another rhythmic style, but I don't
think it would be easy to get right.
IMO the best way to humanize MIDI parts is to hand-code their
velocities, note by note where necessary, which means the coder must
have a practical knowledge of performance factors. I also routinely
add a tempo track that loops an asymmetric group of fluctuating tempo
values, like a very narrow-range LFO applied to tempo. Again, if the
width of the range is too great the looseness becomes sloppy,
destroying the intended effect. Usually I keep a range of +/-4 clicks,
e.g. 120-121-122-121-120-119. If these values are applied to tempo
events at the level of 16th-note triplets they'll have a nice
"upsetting" effect on the rigidity of the sequencer's tempo.
Dynamics and tempo relativities are profound aspects of any engaging
performance, whether a player plans them in advance or they occur as
an improvised response to the music (and possibly to the other players).
Just some thoughts for further consideration.
Best,
dp
Dave, have you seen this software I've just found?
http://www.midi-plugins.de/mplug/mplug-hum.html
This is quite close to what I want to achieve.
After I've read your comments, and those by Frank and Stephen, I believe
that the possibilty to choose different probability curves (linear,
gaussian, exponential, reverse exponential) is the next feature to add.
--
www.cesaremarilungo.com
9:55 a.m.
Cesare Marilungo wrote:
Dave, have you seen this software I've just
found?
http://www.midi-plugins.de/mplug/mplug-hum.html
This is quite close to what I want to achieve.
I took a look at it after seeing your link to it. Very interesting, I'd
like to check it out.
After I've read your comments, and those by Frank
and Stephen, I
believe that the possibilty to choose different probability curves
(linear, gaussian, exponential, reverse exponential) is the next
feature to add.
I agree. These things are at least worth trying, and they may inspire
some musical usage we haven't yet considered. I love surprises... :)
Best,
dp
2:47 p.m.
On 7/7/06, Dave Phillips <dlphillips(a)woh.rr.com> wrote:
Cesare Marilungo wrote:
Maybe a more musical way to "humanize" would be to increase velocity
(by a small random amount) on the downbeat, and maybe decrease on
1/8th or 1/16th notes. Or an option to increase on the backbeats,
decrease elsewhere. Sort of like a step sequencer where you program
the delta (relative to the input) at each step instead of the absolute
value.
You'd need tempo information for any of that, I guess. Might be
easier when Jack MIDI is more widely available.
What about using pitch bend to slightly "detune" some notes? Might
make rolls sounds a little less mechanical...
Dave, have you seen this software I've just
found?
http://www.midi-plugins.de/mplug/mplug-hum.html
This is quite close to what I want to achieve.
I took a look at it after seeing your link to it. Very interesting, I'd
like to check it out.
After I've read your comments, and those by
Frank and Stephen, I
believe that the possibilty to choose different probability curves
(linear, gaussian, exponential, reverse exponential) is the next
feature to add.
I agree. These things are at least worth trying, and they may inspire
some musical usage we haven't yet considered. I love surprises... :)
Best,
dp
3:19 p.m.
Paul Coccoli wrote:
On 7/7/06, Dave Phillips <dlphillips(a)woh.rr.com>
wrote:
I was thinking about implementing some filtering rules for this, along
with the support for multiple channels. That way you can send notes to
different channels with different settings.
Cesare Marilungo wrote:
Maybe a more musical way to "humanize" would be to increase velocity
(by a small random amount) on the downbeat, and maybe decrease on
1/8th or 1/16th notes. Or an option to increase on the backbeats,
decrease elsewhere. Sort of like a step sequencer where you program
the delta (relative to the input) at each step instead of the absolute
value. Dave, have you seen this software I've just
found?
http://www.midi-plugins.de/mplug/mplug-hum.html
This is quite close to what I want to achieve.
I took a look at it after seeing your link to it. Very interesting, I'd
like to check it out.
After I've read your comments, and those by
Frank and Stephen, I
believe that the possibilty to choose different probability curves
(linear, gaussian, exponential, reverse exponential) is the next
feature to add.
I agree. These things are at least worth trying, and they may inspire
some musical usage we haven't yet considered. I love surprises... :)
Best,
dp
You'd need tempo information for any of that, I guess. Might be
easier when Jack MIDI is more widely available.
What about using pitch bend to slightly "detune" some notes? Might
make rolls sounds a little less mechanical...
No. The pitch bend would detune the notes being played all together.
c.
--
www.cesaremarilungo.com
12:23 p.m.
On Fri, 2006-07-07 at 13:21 +0000, Cesare Marilungo wrote:
After I've read your comments, and those by Frank
and Stephen, I believe
that the possibilty to choose different probability curves (linear,
gaussian, exponential, reverse exponential) is the next feature to add.
ONe of the things that I find somewhat grating about certain soundfonts
is that the vibrato on strings is always exactly the same. Some way to
give that some variation would also be nice.
bye
John
1:48 p.m.
John Anderson wrote:
On Fri, 2006-07-07 at 13:21 +0000, Cesare Marilungo
wrote:
I don't think this is possible in MIDI. Please, somebody correct me if
I'm wrong.
c.
--
www.cesaremarilungo.com
After I've read your comments, and those by
Frank and Stephen, I believe
that the possibilty to choose different probability curves (linear,
gaussian, exponential, reverse exponential) is the next feature to add.
ONe of the things that I find somewhat grating about certain soundfonts
is that the vibrato on strings is always exactly the same. Some way to
give that some variation would also be nice.
bye
John
1:50 p.m.
On 7/7/06, Cesare Marilungo <cesare(a)poeticstudios.com> wrote:
>ONe of the things that I find somewhat grating
about certain soundfonts
>is that the vibrato on strings is always exactly the same. Some way to
>give that some variation would also be nice.
I don't think this is possible in MIDI. Please,
somebody correct me if
I'm wrong.
That would have to be addressed in the sample engine itself
--
Brett McCoy: Programmer by Day, Guitarist by Night
http://www.alhazred.com
http://www.cassandrasyndrome.com
http://www.revelmoon.com
1:58 p.m.
Brett W. McCoy wrote:
On 7/7/06, Cesare Marilungo
<cesare(a)poeticstudios.com> wrote:
Exactly.
c.
--
www.cesaremarilungo.com
>ONe of the things that I find somewhat
grating about certain soundfonts
>is that the vibrato on strings is always exactly the same. Some way to
>give that some variation would also be nice.
I don't think this is possible in MIDI.
Please, somebody correct me if
I'm wrong.
That would have to be addressed in the sample engine itself
12 Jul
12 Jul
7:52 a.m.
On Friday 07 July 2006 15:23, John Anderson was like:
ONe of the things that I find somewhat grating about
certain soundfonts
is that the vibrato on strings is always exactly the same. Some way to
give that some variation would also be nice.
Absolutely. The range and shape of the variations could be programmed into the
instrument definition and linked to a spare MIDI controller. I can forsee us
deprecating MIDI in favour of something like OSC for serious work,
eventually. Obviously the format will have to remain negotiable for backwards
compatibility reasons, but by and large I find MIDI and soundfonts so
horrendously limited as to be only really useful for demos. I'd like to see
proper microtonal support in all sound-producing applications, currently only
ZynAddSubFX handles this nicely. For me 12Tet@A=440Hz always sounds out of
tune. YMMV. Not being a confident programmer I'm finding Csound,
supercollider and even Pd et al., rather complicated to get into and I have
taxi'd up the runway many times, great for experimenting, but I haven't made
the time to learn how to produce quality results - I suspect most ordinary
musicians won't either. In general, I'm finding the process of creating new
instrument sounds to be less straightforward than I would like it to be, be
that editing soundfonts, csound orchestras, ZynAddSubFX patches or whatever.
Really I'm yearning for analog synths, I have fond memories of playing with
MS10s, SH101s and my old Pro1 and the kind of resonant filter sweeps that are
possible with analog filters. Is the sound I am looking for simply not
possible digitally? Would anyone with the appropriate skills consider
modelling VCS3 or Prophet filters in software? The closest application is
probably Alsa Modular Synth for what I want (as I'd like to be able to filter
samples too), but it does appear to have limitations. I shall persevere,
obviously.
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
We are the people We've been waiting for.
11:02 a.m.
tim hall wrote:
Really I'm yearning for analog synths, I have fond
memories of playing with
MS10s, SH101s and my old Pro1 and the kind of resonant filter sweeps that are
possible with analog filters. Is the sound I am looking for simply not
possible digitally? Would anyone with the appropriate skills consider
modelling VCS3 or Prophet filters in software? The closest application is
probably Alsa Modular Synth for what I want (as I'd like to be able to filter
samples too), but it does appear to have limitations. I shall persevere,
obviously.
I still own (and use) a Korg MS20. I had an MS10 also, but sold it two
years ago to pay some bills :-) . I'm not a DSP expert but what makes
these synths unique were their unpredictability and their lack of
precision. An analog circuit like that is sensible to temperature, humidity.
The difference between a real analog synth and a soft synth is much like
the difference between a tape recorder and a digital recorder. We're
used to the sound of the first kind, a sound that is determined by the
intrinsic limitations of that technology.
If we reproduce or store our performance in bits anyway, there's no
difference between a well programmed soft synth and a real analog apart
from the fact that the first one sound (and has been designed to sound)
too perfect.
Isn't, again, a matter of introducing a bit of randomicity (if this is
the correct term)?
c.
--
www.cesaremarilungo.com
13 Jul
13 Jul
9 a.m.
On Wednesday 12 July 2006 16:02, Cesare Marilungo was like:
tim hall wrote:
It's not just that we're used to the analog sound, there is a definite
psycho-acoustic difference. IMO.
Really I'm yearning for analog synths, I have
fond memories of playing
with MS10s, SH101s and my old Pro1 and the kind of resonant filter sweeps
that are possible with analog filters. Is the sound I am looking for
simply not possible digitally? Would anyone with the appropriate skills
consider modelling VCS3 or Prophet filters in software? The closest
application is probably Alsa Modular Synth for what I want (as I'd like
to be able to filter samples too), but it does appear to have
limitations. I shall persevere, obviously.
I still own (and use) a Korg MS20. I had an MS10 also, but sold it two
years ago to pay some bills :-) . I'm not a DSP expert but what makes
these synths unique were their unpredictability and their lack of
precision. An analog circuit like that is sensible to temperature,
humidity. The difference between a real analog synth and a soft synth is
much like the difference between a tape recorder and a digital recorder.
We're used to the sound of the first kind, a sound that is determined by
the intrinsic limitations of that technology. If we reproduce or store our performance in bits
anyway, there's no
difference between a well programmed soft synth and a real analog apart
from the fact that the first one sound (and has been designed to sound)
too perfect.
Isn't, again, a matter of introducing a bit of randomicity (if this is
the correct term)?
It is possible to simulate oscillator drift et al., sure, but it is difficult
to get good clean sine tones in the upper ranges digitally.
I saw / heard some nice external boxes at the Sounds Expo, I don't remember
the manufacturer offhand (I will look it up). They did a nice Prophet and
Moog style synth, both digitally modelled, so I know it is possible. When I
have a bit of spare cash I will probably get one of these - I have to say I
also like the MS2000, which is in a similar price range.
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
We are the people We've been waiting for.
11:20 a.m.
On Wed, Jul 12, 2006 at 03:02:48PM +0000, Cesare Marilungo wrote:
Isn't, again, a matter of introducing a bit of randomicity (if this is
the correct term)?
The problem is that the idea of just adding a "bit of randomicity"
is that "randomness" is always a matter of glossing over complexity,
chaos, and non-linearity with a simple function which generally does
not behave in the same way as the original system. There is nothing
truly random in this universe, except at the quantum level, and we
are not even 100% sure of that. Outside that there is only a glossing
over of detail and calling it random. So adding random simulated heat
fluctuations to the virtual components of a soft synth is not going to
make it sound more like an actual analogue synth unless you have done a
very heavy statistical analysis of the original system and come up with
an equation for your soft synth that does approximate the mathematical
properties of the original system closely. Most of the time though we
all just call the rand() function (or whatever is available to you in
your particular environment), which always yeilds the same statistical
bell curve "feel" - in my opinion this is insufficient to make a soft
synth sound analogue, or a drum machine sound like a person. (That said,
I'm guilty of doing this in my own music all the time because I enjoy
the robot like aesthetic of machine generated pseudo randomness).
Best,
Chris.
-------------------
chris(a)mccormick.cx
http://mccormick.cx
9:24 p.m.
New subject: [linux-audio-user] Re: ALSA MIDI Humanizer v0.0.1
On 7/12/06, tim hall <tech(a)glastonburymusic.org.uk> wrote:
On Friday 07 July 2006 15:23, John Anderson was like:
ARRG you used the bad words!!!! AMS? I prefer a program that has a
release in the last 2 years, i find it edging to impossible to do
anything useful in AMS at all. Get the svn version of om/ingen
http://www.nongnu.org/om-synth/ You can do a lot of nice analog style
stuff with it. Many of the smack patches are analog style.
Loki
ONe of the things that I find somewhat grating
about certain soundfonts
is that the vibrato on strings is always exactly the same. Some way to
give that some variation would also be nice.
Absolutely. The range and shape of the variations could be programmed into
the
instrument definition and linked to a spare MIDI controller. I can forsee us
deprecating MIDI in favour of something like OSC for serious work,
eventually. Obviously the format will have to remain negotiable for
backwards
compatibility reasons, but by and large I find MIDI and soundfonts so
horrendously limited as to be only really useful for demos. I'd like to see
proper microtonal support in all sound-producing applications, currently
only
ZynAddSubFX handles this nicely. For me 12Tet@A=440Hz always sounds out of
tune. YMMV. Not being a confident programmer I'm finding Csound,
supercollider and even Pd et al., rather complicated to get into and I have
taxi'd up the runway many times, great for experimenting, but I haven't made
the time to learn how to produce quality results - I suspect most ordinary
musicians won't either. In general, I'm finding the process of creating new
instrument sounds to be less straightforward than I would like it to be, be
that editing soundfonts, csound orchestras, ZynAddSubFX patches or whatever.
Really I'm yearning for analog synths, I have fond memories of playing with
MS10s, SH101s and my old Pro1 and the kind of resonant filter sweeps that
are
possible with analog filters. Is the sound I am looking for simply not
possible digitally? Would anyone with the appropriate skills consider
modelling VCS3 or Prophet filters in software? The closest application is
probably Alsa Modular Synth for what I want (as I'd like to be able to
filter
samples too), but it does appear to have limitations. I shall persevere,
obviously.
--
cheers, 
9:41 p.m.
New subject: [linux-audio-user] Re: ALSA MIDI Humanizer v0.0.1
Loki Davison wrote:
ARRG you used the bad words!!!! AMS?
I agree that AMS is buggy, and that om in many ways are better. But I
must admit that I found AMS even more fun/easy to work with than om. Esp
if you stick to the build-in modules in AMS, the modules work together
really smoothly. I know that defect, no-common-conventions, generic
interfaces LADSPA plugins isn't om's fault, but it's still part of the
user-experience.
But of course the buggyness and fact that it's unmaintained makes AMS
totally unusable for me too.
--
peace, love & harmony
Atte
http://www.atte.dk | quartet: http://www.anagrammer.dk
http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
14 Jul
14 Jul
10:21 a.m.
New subject: [linux-audio-user] Re: ALSA MIDI Humanizer v0.0.1
On Friday 14 July 2006 00:24, Loki Davison was like:
ARRG you used the bad words!!!! AMS?
Oh do grow up. It's a Linux Audio app and its developers deserve respect for
their efforts.
I prefer a program that has a
release in the last 2 years, i find it edging to impossible to do
anything useful in AMS at all.
Agreed, however AMS isn't the only application with these problems, or by any
means the worst.
Get the svn version of om/ingen
http://www.nongnu.org/om-synth/ You can do a lot of nice analog style
stuff with it.
I look forward to playing with om just as soon as someone produces a .deb for
it. I know I'm perfectly capable of doing so myself from source, however I
don't have time or headspace for that right now. I will be happy if om can do
this relatively simply.
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
We are the people We've been waiting for.
7 Jul
7 Jul
3:57 p.m.
Hallo,
Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
Frank Barknecht wrote:
Blimes explicitly criticizes the existing sequencer presets for
"humanizing". He doesn't do so because they don't sound human, but
because their way of just using random variations is "unmusical" -
unless of course one tries to do a certain kind of mathematically
inspired music, which has its place, too, but most of the times may
not be, what users of commercial software sequencers want to achieve.
(Actually many of these sequencers also provide ways to use uneven
quantizations derived from recordings of real humans.)
As Dave P. wrote, if a real *groove* is wanted, editing a lot of stuff
like timings and velocities by hand and ear is the usual way to work.
Obviously one takes this hard and time consuming road, because just
adding gaussian or other randomization is not achieving satisfying
results for the goal at hand.
I would really recommend to read Blimes' paper and thesis. It is very
interesting stuff and maybe you want to try your hand at a Linux clone
of the software he presents in the paper afterwards? It would be an
interesting project and you could build it on top of your current
program.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
to really humanize is an ongoing debate. One
interesting concept in
this regard is described in the work of Jeff Blimes and in his concept
of the "Tatum". A short introduction is this paper:
http://ssli.ee.washington.edu/people/bilmes/mypapers/icmc93_paper.pdf
Well, I called it 'humanizer' just because it is how this kind of
functionality in sequencers and drum machines has always been called,
...
Anyway, as I said, I've always used this functionality in various
situations (but I can't speak for my own results). It is builtin in
cubase, digital performer and any other commercial software sequencer
I've tried in my life. 
8 Jul
8 Jul
4:37 p.m.
On Fri, 2006-07-07 at 19:57 +0200, Frank Barknecht wrote:
As Dave P. wrote, if a real *groove* is wanted,
editing a lot of stuff
like timings and velocities by hand and ear is the usual way to work.
Obviously one takes this hard and time consuming road, because just
adding gaussian or other randomization is not achieving satisfying
results for the goal at hand.
A potentially good but certainly expensive method would be to record
many expert human players and analyze their playing. Some kind of
patterns must emerge.
Then try and reproduce that in software.
--
Florin Andrei
http://florin.myip.org/
4:51 p.m.
On Sat, 2006-07-08 at 11:37 -0700, Florin Andrei wrote:
On Fri, 2006-07-07 at 19:57 +0200, Frank Barknecht
wrote:
How does Hydrogen's humanize feature work? It certainly sounds good.
Maybe that could be broken out into a standalone app?
Lee
As Dave P. wrote, if a real *groove* is wanted,
editing a lot of stuff
like timings and velocities by hand and ear is the usual way to work.
Obviously one takes this hard and time consuming road, because just
adding gaussian or other randomization is not achieving satisfying
results for the goal at hand.
A potentially good but certainly expensive method would be to record
many expert human players and analyze their playing. Some kind of
patterns must emerge.
Then try and reproduce that in software.
5:42 p.m.
Lee Revell wrote:
On Sat, 2006-07-08 at 11:37 -0700, Florin Andrei
wrote:
Lee, I've just checked the code.
It uses a random offsets with gaussian distribution (just like my
humanizer0.0.2). There's more: the algorithm used is the same I used for
my project (found here: http://www.taygeta.com/random/gaussian.html).
But hydrogen source uses rand() as a random generator, when I've heard
that random() is much better (more uniform distribution) and in fact I
also changed rand() to random() from v0.0.1 to 0.0.2.
c.
--
www.cesaremarilungo.com
On Fri, 2006-07-07 at 19:57 +0200, Frank Barknecht
wrote:
How does Hydrogen's humanize feature work? It certainly sounds good.
Maybe that could be broken out into a standalone app?
Lee
As Dave P. wrote, if a real *groove* is wanted,
editing a lot of stuff
like timings and velocities by hand and ear is the usual way to work.
Obviously one takes this hard and time consuming road, because just
adding gaussian or other randomization is not achieving satisfying
results for the goal at hand.
A potentially good but certainly expensive method would be to record
many expert human players and analyze their playing. Some kind of
patterns must emerge.
Then try and reproduce that in software.
7:30 p.m.
On Sat, Jul 08, 2006 at 09:42:43PM +0000, Cesare Marilungo wrote:
But hydrogen source uses rand() as a random generator,
when I've heard
that random() is much better (more uniform distribution) and in fact I
also changed rand() to random() from v0.0.1 to 0.0.2.
From the man page:
The versions of rand() and srand() in the Linux C Library use the same
random number generator as random() and srandom(), so the lower-order
bits should be as random as the higher-order bits. However, on older
rand() implementations, and on current implementations on different
systems, the lower-order bits are much less random than the higher-
order bits.
And even that doesn't matter unless you use only the lower bits.
There is certainly no difference in the distribution if you divide
by RAND_MAX to a [0...1] float result.
--
FA
Follie! Follie! Delirio vano e' questo!
7:46 p.m.
Fons Adriaensen wrote:
On Sat, Jul 08, 2006 at 09:42:43PM +0000, Cesare
Marilungo wrote:
Ok, right, on linux they're the same. Thank you. :-P
c.
--
www.cesaremarilungo.com
But hydrogen source uses rand() as a random
generator, when I've heard
that random() is much better (more uniform distribution) and in fact I
also changed rand() to random() from v0.0.1 to 0.0.2.
From the man page:
The versions of rand() and srand() in the Linux C Library use the same
random number generator as random() and srandom(), so the lower-order
bits should be as random as the higher-order bits. However, on older
rand() implementations, and on current implementations on different
systems, the lower-order bits are much less random than the higher-
order bits.
And even that doesn't matter unless you use only the lower bits.
There is certainly no difference in the distribution if you divide
by RAND_MAX to a [0...1] float result.
5:29 p.m.
Hallo,
Florin Andrei hat gesagt: // Florin Andrei wrote:
A potentially good but certainly expensive method
would be to record
many expert human players and analyze their playing. Some kind of
patterns must emerge.
Then try and reproduce that in software.
This is what Jeff Blimes (et al.) did.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
5:43 p.m.
Frank Barknecht wrote:
Subject:
Re: [linux-audio-user] [ANN] ALSA MIDI Humanizer v0.0.1
From:
Frank Barknecht <fbar(a)footils.org>
Date:
Sat, 8 Jul 2006 21:28:48 +0200
To:
linux-audio-user(a)music.columbia.edu
To:
linux-audio-user(a)music.columbia.edu
Hallo,
Florin Andrei hat gesagt: // Florin Andrei wrote:
Frank, I've read the Jeff Blimes paper.
It's interesting but his software is more like a drum machine (something
that produces the midi events) when I'm trying to make something similar
to hydrogen functionality, but more generic and with far more controls.
Something that provides a lot of tools but leaves the decisions about
how to use it to the musician.
c.
--
www.cesaremarilungo.com
A potentially good but certainly expensive method
would be to record
many expert human players and analyze their playing. Some kind of
patterns must emerge.
Then try and reproduce that in software.
This is what Jeff Blimes (et al.) did.
Ciao
12 Jul
12 Jul
8:06 a.m.
On Saturday 08 July 2006 19:37, Florin Andrei was like:
This is only a theory*, but the majority of music that is
considered 'harmonic' is based on whole-number ratios (2:3 -> 8:9). It makes
a great deal of musical sense to apply this (filter) to rhythmic data and/or
the randomised variations of that data. Most rhythmical information can be
broken down into single, double and triplet groups. The aural complexity of
the music is directly proportional to the complexity of the maths. It should
be up to the user to specify the allowable amount of harmonic / rhythmic
complexity. Just a thought.
* It is, however a theory that I base most of my music on. ;)
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
We are the people We've been waiting for.
As Dave P.
wrote, if a real *groove* is wanted, editing a lot of stuff
like timings and velocities by hand and ear is the usual way to work.
Obviously one takes this hard and time consuming road, because just
adding gaussian or other randomization is not achieving satisfying
results for the goal at hand.
A potentially good but certainly expensive method would be to record
many expert human players and analyze their playing. Some kind of
patterns must emerge.
Then try and reproduce that in software.
6742
days inactive
6750
days old
linux-audio-user@lists.linuxaudio.org
36 comments
15 participants
participants (15)
-
Atte André Jensen -
Brett W. McCoy -
Cesare Marilungo -
Chris McCormick -
Dave Phillips -
Florin Andrei -
Fons Adriaensen -
Frank Barknecht -
John Anderson -
Jordan Nash -
Lee Revell -
Loki Davison -
Paul Coccoli -
Stephen Cameron -
tim hall