2 Oct
2012
2 Oct
'12
4:59 a.m.
code here:
https://gist.github.com/3815747
specgram here:
http://ubuntuone.com/3XbDaa6fXmpnpMwCx6QWRd
it should not increase the depth like it is doing.
help pls ;-)
best,
--
GNU/Linux User #479299
labmacambira.sf.net
2 Oct
2 Oct
4:52 p.m.
From: "Renato Fabbri"
<renato.fabbri(a)gmail.com>
code here:
https://gist.github.com/3815747
it should not increase the depth like it is doing.
I don't see any "ti" above the line:
a.wavwrite(ti,"vibrato.wav",fa)
HTH (I'm not a specialist of python/numpy)
5:45 p.m.
fixed it, should be working now.
2012/10/2 SxDx <sed(a)free.fr>
--
GNU/Linux User #479299
labmacambira.sf.net
From:
"Renato Fabbri" <renato.fabbri(a)gmail.com>
code here:
https://gist.github.com/3815747
it should not increase the depth like it is doing.
I don't see any "ti" above the line:
a.wavwrite(ti,"vibrato.wav",fa)
HTH (I'm not a specialist of python/numpy)
8:39 p.m.
fixed it, should be working now.
I translated your program into C, ran it, and get
a nice constant vibrato.
If you want to have a look (if you read C):
http://pastebin.com/pJKA10Ub
It spits floats, the 2s of vibrato followed by the 2s with no vibrato.
You can compile: gcc ex.c -lm then run ./a.out | aplay -r 44100 -f FLOAT_LE
(it works on my x86_64 computer, it should work on
any little endian thing, I guess)
I tried your python version and get weird results.
I don't know what's wrong. Translating line by line
into C gives a nice vibrato...
weird...
Sorry, I can't help more.
8:47 p.m.
Of course, as always, it's only after you press "send"
that things get clear...
The problem is in your cumsum, you use n.int.
Don't do that. Do cumsum (as float) and *then* transform
gi to an int array.
8:52 p.m.
The last one in the series, sorry for the mess...
so replace:
gi=n.cumsum(dD,0,n.int)%Dv
by:
gi=n.cumsum(dD)
gi=n.array(gi, dtype=int)%Dv
3 Oct
3 Oct
6:22 p.m.
it works with gi=n.cumsum(dD,0,n.int)%Dv
for me.
it was not working beforehand, in this version:
https://gist.github.com/3815747/9721cfc5eff7a4dd706a7f1e80a6264d3bd6915d
when i assumed frequency variation and did the LUT
procedure normally, without the cumsum which takes in
account individual steps and resulting positions.
can you post the .wav that https://gist.github.com/3815747
outputs?
thanks for the feedback and the C version!
2012/10/2 SxDx <sed(a)free.fr>
The last one in the series, sorry for the mess...
so replace:
gi=n.cumsum(dD,0,n.int)%Dv
by:
gi=n.cumsum(dD)
gi=n.array(gi, dtype=int)%Dv
--
GNU/Linux User #479299
labmacambira.sf.net
7:18 p.m.
it works with gi=n.cumsum(dD,0,n.int)%Dv
for me.
So, your code had no problem?
it was not working beforehand, in this version:
https://gist.github.com/3815747/9721cfc5eff7a4dd706a7f1e80a6264d3bd6915d
when i assumed frequency variation and did the LUT
procedure normally, without the cumsum which takes in
account individual steps and resulting positions.
can you post the .wav that https://gist.github.com/3815747
outputs?
http://sed.free.fr/pyt.tar.bz2
sorry, no wav, I don't have scikits,
I did ti.tofile("ti.raw") and t.tofile("t.raw").
I get the same results with my C code if I
change it to do the cumsum in ints.
7:27 p.m.
2012/10/3 SxDx <sed(a)free.fr>
answer is on the next lines of the message (right?):
--
GNU/Linux User #479299
labmacambira.sf.net
it works with
gi=n.cumsum(dD,0,n.int)%Dv
for me.
So, your code had no problem?
it was not working beforehand, in this version:
https://gist.github.com/3815747/9721cfc5eff7a4dd706a7f1e80a6264d3bd6915d
when i assumed frequency variation and did the LUT
procedure normally, without the cumsum which takes in
account individual steps and resulting positions.
can you post the .wav that https://gist.github.com/3815747
outputs?
http://sed.free.fr/pyt.tar.bz2
sorry, no wav, I don't have scikits,
I did ti.tofile("ti.raw") and t.tofile("t.raw").
I get the same results with my C code if I
change it to do the cumsum in ints.
7:40 p.m.
2012/10/3 SxDx <sed(a)free.fr>
Okay, sorry then. I just saw and tried the latest version
which did not work on my computer.
yeah, great to know that. Thanks!
--
GNU/Linux User #479299
labmacambira.sf.net
So, your code had no problem?
answer is on the
next lines of the message (right?):
> > it was not working beforehand, in this version: 
9:21 p.m.
What exactly does this program output?
I can save the output of this
program to a file, but then, what
would I do with this file?
Thanks;
----- Original Message -----
SxDx <sed(a)free.fr> writes:
I translated your program into C, ran it, and get
a nice constant vibrato.
If you want to have a look (if you read C):
http://pastebin.com/pJKA10Ub
It spits floats, the 2s of vibrato followed by the 2s with no vibrato.
You can compile: gcc ex.c -lm then run ./a.out | aplay -r 44100 -f FLOAT_LE
(it works on my x86_64 computer, it should work on
any little endian thing, I guess)
4 Oct
4 Oct
12:05 p.m.
> http://pastebin.com/pJKA10Ub
> You can compile: gcc ex.c -lm then run ./a.out | aplay -r 44100 -f FLOAT_LE
What exactly does this program output?
I can save the output of this
program to a file, but then, what
would I do with this file?
just 4s of audio, as float 32bits, endianness of your computer
(probably little endian; almost everyone is little endian today).
You can "aplay" the file, or convert to whatever audio format
that has a header (and if you want compression, lossless or not)
using whatever tool you like (sox, ffmpeg, ...)
Use the python code to directly have a wav file.
I think you don't really need the file though.
4878
days inactive
4880
days old
linux-audio-user@lists.linuxaudio.org
12 comments
3 participants
participants (3)
-
Ivan K -
Renato Fabbri -
SxDx