Wanted to let everyone know thanks for the massive assists so far. Got jack, qtractor, zynsubbaddfx, going and talking to each other and to/from the Yamaha keyboard via standard game (EMU10k1) port MIDI. Family was quite impressed could play Yamaha keyboard from computer and vice-versa. Zyn never sounded so beautiful. HT to Paul Nasca.
Ubuntu 9.04 on Dell Dimension 4400 with 1gb ram
EMU10k1 soundcard with MIDI connected via game ports
zyn = 2.2.1-4.1ubuntu1
qtractor = 0.3.0-0ubuntu1
qjackctl = 0.3.4
ardour = 1:2.7.1-2ubuntu1 ** Have been unable to get it to record MIDI as yet
Jack settings:
priority is hard set to default for whatever reason (thought I saw something in an earlier thread about it being set to zero. Not sure how to fix that part (or if I am totally off-base). Frames/period are 128 and sample rate is 48000 while periods per buffer is set at 2. I know several have suggested trying to set it at 3-5 and it refuses to do so (most often resulting in a crash). It claims to be running real-time, just not sure why it gave 88 xruns in 35 minutes of playing.
ulimit -r = 99
ulimit -l = 64
Not sure what else anyone might need to help troubleshoot, so will await replies.
Thanks in advance
Paul
In my sudden flurry of rebuilding/optimizing/updating, I decided to also upgrade to the latest TAP and CAPS plugins.
TAP went well.
CAPS is dying thusly
g++ -o caps.so Amp.o Cabinet.o Chorus.o Click.o Clip.o Compress.o Eq.o HRTF.o Lorenz.o Pan.o Phaser.o Preamp.o Reverb.o Roessler.o Scape.o Sin.o SweepVF.o ToneControls.o ToneStack.o VCO.o White.o interface.o
/usr/scratch/backports/caps/caps-0.4.3/interface.cc:124: multiple definition of `_fini'
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crti.o:/build/buildd/glibc-2.7/build-tree/glibc-2.7/csu/../sysdeps/generic/initfini.c:109: first defined here
interface.o: In function `_init':
/usr/scratch/backports/caps/caps-0.4.3/interface.cc:69: multiple definition of `_init'
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crti.o:/build/buildd/glibc-2.7/build-tree/i386-libc/csu/crti.S:15: first defined here
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make[1]: *** [caps.so] Error 1
This looks like a very familiar error, I remember before from my development days. IIRC it has something to do with not specifying linker options correctly, or forgetting to include proper libraries when linking. But for the life of me I can't remember what the solution was.
Any ideas?
Thanks again to everyone for all your help!
-ken
Hi all,
A bugfix version of TAP-plugins has been released. It aims to fix:
* problems on 64-bit (silence in EQ, etc)
* denormal problems
* GCC compiler warnings
* uninitialised variables (detected via Valgrind)
Thanks to Damon Chaplin for spotting the issues, working on the
solution and preparing a patch.
TAP-plugins is hosted on SourceForge, please visit:
http://tap-plugins.sf.nethttp://sourceforge.net/projects/tap-plugins/
There is no new functionality in this release. If 0.7.0 works perfectly
for you, there is no need to upgrade.
Enjoy,
Tom
Good day all
I've recently gotten interested in recording & mixing in surround, which led
me to Ambisonics as well. I've noticed Fons has a good deal of contribution
to that field, judging from his tools (ambdec et al) and credits.
My first stumbling block is how one would go about the mixing process for
such a project, especially since none of our DAWs have (true) support for
surround. Granted, there are ways to work around it, especially if one
doesn't need fancy 360-degree panning UIs. For instance, although I've not
tried it yet, theoretically one can stream separate tracks to ac3jack. Each
track can have its own panning relative to front and rear groups, and since
conventional surround (not ambisonics) has no height information, that'd be
adequate. I don't know if existing surround VST plug-ins could be used
within Ardour properly.
Secondly, would the tools from http://www.kokkinizita.net/linuxaudio/ be
enough for ambisonics? I notice that there is only a decoder, but for
mixing, one needs an encoder (which I understand to be the panning and
bussing of WXYZ). Is there any native tool to help with that?
Third and _most_ important of all, is it possible to listen to the _virtual_
surround image in real-time through stereo? IIRC, Windows has/had these neat
little utilities provided by vendors to recreate 3D (virtual) surround with
n number of speakers, marketing to the 2-channel stereo crowd. Any surround
audio being streamed by the system would fall back to this 3D thing if no
surround hardware is available. Not sure whether the same applies for an
ASIO environment. If not, I may be asking for something which has not yet
been developed.
Considering that ALSA has a "plug-in" for downmixing multi-channel audio,
and it works OK, could there be a way to use it/something similar within a
JACK environment? It'd really help when I'm recording live, eg. an
orchestra, with surround miking and no more than just a monitoring
headphone. Something like ac3jack, but with some sort of virtual surround
output option.
Fourth and least important, is there a native tool for converting audio to
5.1 (or so thereof) with panners? I have a Zoom H2 which outputs 4 channels
(front and rear stereo) and don't want to rely on the VST that's available.
Sometimes I just happen to need fast methods, especially when I'm mobile.
Regards
Hello all!
I'm just compiling/configuring a 2.6.30.4 vanilla kernel. Only with the
current configuration it won't start.
When I boot and I can choose the kernel and it tries to start, but then the
two LEDs on my keyboard (as in letters and numbers :-) ) start to blink
rhythmically and nothing else happens.
Does anyone of you have some standard ideas of, what to change? I already
tried:
1. The RCU settings
2. disabled tickless system
3. disabled control groups
4. double-checked, that I chose the correct CPU and ACPI settings
Points I'm not sure about are some of the memory options. There are options
to disallow extensive access of /dev/mem, checking for corrupt memory and
something concerning AMI and PHOENIX biosen to have the first 64k of memory.
Those weren't there the last time I made my kernel.
If anyone has helpful hints (not take a look at the screen please! :-) ),
then I'd be _VERY_ grateful!
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
On Sat, Aug 15, 2009 at 11:37:25AM +0200, hermann wrote:
> Am Freitag, den 14.08.2009, 12:59 -0700 schrieb Ken Restivo:
> > On Tue, Jul 21, 2009 at 05:56:42PM +0200, Carlos Sanchiavedraz wrote:
> > > Really good info; in fact some time ago I tried to figure out how to
> > > analize and reproduce in the digital realm a sound or fx.
> > >
> > > But, as Ken, my skills in DSP and programming aren't that good to try
> > > to help in such a deep way. I think I'd be more usefull in analysing
> > > by ear or to contribute with some ideas.
> > >
> > > However, what I could do is to provide some more data from a Wah pedal
> > > (borrowed), along with Julien's. In fact, I was considering to buy one
> > > some time ago, but I didn't decided nor what kind (Wah, Cry baby...)
> > > Maybe this is a sign ;)
> > >
> > > 2009/7/21, Ken Restivo <ken(a)restivo.org>:
> > > > On Mon, Jul 20, 2009 at 11:51:07AM +0200, Fons Adriaensen wrote:
> > > >> On Sun, Jul 19, 2009 at 08:10:47PM -0700, Ken Restivo wrote:
> > > >>
> > > >> > Just a quick update on the wah research.
> > > >> >
> > > >> > A friend owns a Dunlop "Jimi Hendrix Wah", which says it is the
> > > >> > "Original Thomas Design", by which I assume they mean to claim it's the
> > > >> > same design as the Thomas Organ Wah, formerly Vox.
> > > >> >
> > > >> > This website's describes the frequency response as a lowpass with a
> > > >> > resonant peak:
> > > >> > http://www.geofex.com/Article_Folders/wahpedl/wahped.htm
> > > >> >
> > > >> > So here is what JAPA says it does (and I believe JAPA more than some
> > > >> > random website):
> > > >> >
> > > >> > When fully closed, it's a bandpass, with a VERY high Q!
> > > >> > http://restivo.org/misc/lowend-jimi.png
> > > >> >
> > > >> > But, wait, when I open it up, suddenly it becomes more like a highpass,
> > > >> > but with a lot of resonance:
> > > >> > http://restivo.org/misc/midrange-jimi.png
> > > >> >
> > > >> > When it's fully opened, it's definitely a highpass, but with a helluva
> > > >> > peak:
> > > >> > http://restivo.org/misc/high-jimi.png
> > > >> >
> > > >> > So, not only is the opposite of what that article says, but it's also
> > > >> > kind of non-linear. I'll poke around the various LADSPA plugins and see
> > > >> > if I can find something nearly like this.
> > > >> >
> > > >> > Another guitar-player friend has a different wah (IIRC, either a "Cry
> > > >> > Baby", or a Morley), and I'll see if I can run his through this and see
> > > >> > what it comes up looking like.
> > > >>
> > > >>
> > > >> AFAICS this is a resonant (which is not the same as bandpass) filter.
> > > >> If the response near Fs/2 bcomes flat, that does not mean it is a
> > > >> highpass.
> > > >>
> > > >> Remember that any digital filter is 'mirrored' to the other side
> > > >> of Fs/2. Also the magnitude of the response must be continuous or
> > > >> zero at all points (for finite order).
> > > >>
> > > >> The result of all this is that at Fs/2 the response must be either
> > > >> zero or have a zero derivative, i.e. be horizontal.
> > > >>
> > > >> In a high order filter you can make the 'roundoff' region near
> > > >> Fs/2 very small, but it's always there, unless the response is
> > > >> zero at that frequency.
> > > >>
> > > >> You can probably get this type of response using the MOOG VCF
> > > >> by taking the output at a different point in the algorithm.
> > > >>
> > > >> The MOOG VCF is 4th order, this is overkill as the analog
> > > >> circuit is very likely to be just 2nd order.
> > > >>
> > > >
> > > > Thanks. Alas, that seems like a very concise explanation, but I don't have
> > > > the mathematical background to implement that.
> > > >
> > > > If someone feels like modifying the Moog VCF to make it a Vox/Thomas Wah,
> > > > I'd be eternally grateful. But it's pretty clear I don't have the skills to
> > > > take this over the finish line.
> > > >
> >
> >
> > I received a suggestion off-list to try the Guitarix plugins, which I did, and got very good results from it:
> >
> >
> > http://restivo.org/projects/wah/high-jimi.png
> > http://restivo.org/projects/wah/guitarixcry-high.png
> >
> >
> > http://restivo.org/projects/wah/lowend-jimi.png
> > http://restivo.org/projects/wah/guitarixcry-low.png
> >
> > http://restivo.org/projects/wah/midrange-jimi.png
> > http://restivo.org/projects/wah/guitarixcry-mid.png
> >
> >
> > Part of the difference in the plots is that I wasn't using the correct JAPA settings for the plots of the actual "Jimi Hendrix Thomas" wah. The frequencies are different, but that might just be because the Guitarix plugin sweeps higher and lower than the Jimi pedal.
> >
> > It sounds great. Now I'm either going to hack together an auto-wah via AMS or something and an envelope follower, or build myself an Arduino pedal footcontroller.
> >
> > Funky and fun.
> >
> > -ken
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user(a)lists.linuxaudio.org
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>
> Hi
>
> The crybaby(wah) from guitarix is the original crybaby from Professor
> Julius O. Smith as he describes here:
>
> http://ccrma.stanford.edu/realsimple/faust_strings/Adding_Wah_Pedal.html
>
> It's included in the faust distribution and there you can find also a
> description how to make it a auto wah.
> http://faust.grame.fr/
>
> Anyway, here is the auto wah version as standalone app attached
> You can build it with
>
> g++ -O3 `pkg-config --cflags --libs jack gtk+-2.0` autowah.cpp -o
> autowah
>
>
> If you like it and will get a ladspa version, send me a note, it's fast
> done with faust and I have a Id free for it.
>
> have fun
> hermann
AWESOME!!
All I needed to do was the following in order to get the sound I wanted:
--- a/autowah.cpp
+++ b/autowah.cpp
@@ -956,7 +956,7 @@ class mydsp : public dsp {
virtual void buildUserInterface(UI* interface) {
interface->openVerticalBox("crybaby");
interface->addCheckButton("on/off", &fcheckbox0);
- interface->addHorizontalSlider("Mapping", &fslider0, 1.0f, 1.0f, 10.0f, 0.1f);
+ interface->addHorizontalSlider("Mapping", &fslider0, 1.0f, 1.0f, 50.0f, 0.1f);
interface->addHorizontalSlider("level", &fslider1, 0.1f, 0.0f, 1.0f, 1.000000e-02f);
interface->addHorizontalSlider("wet/dry", &fslider2, 0.0f, -1.0f, 1.0f, 1.000000e-03f);
Most of the time I'll have it set between 30 and 40, but having the headroom up to 50 is nice.
Quick example here:
http://www.restivo.org/misc/wahtest2.ogg
Here come the ducks!
Yes, please, I'd love to have a LADSPA version. I think the GTK version did strange things to my window manager (i.e. it's not following the mouse anymore).
THANKS AGAIN! I will be using this Friday and Saturday night, for sure.
-ken
has anyone had luck getting a E-MU Tracker Pre to work with the latest
rt and plain vanilla kernels?
the review on Amazon says the kernel as of Oct 2008 operates 'only at
44.1KHz 16bit and without software volume control'
Having obtained a solid 2ms latency at 48kHz with my Multiface II, I
decided to shoot for 96. Partially I wondered if it might help with the
loss of high end I was trying to troubleshoot in the earlier post about
impedance matching -- I'm definitely losing treble somewhere. I've
verified that I can compensate for it coming back into the mixer with
EQ, but the point is, I shouldn't have to. CD's are only 44.1kHz, and
they have no lack of treble at all. (Though it does often sound grainy
or metallic to me...still, it's treble.) I can't imagine a reason that
48kHz should be dulling the top end.
Anyway, the RME should be able to do 96kHz, so whether it solves the EQ
issue or not, I wanted to try it. This is what I'm getting at just
about any setting in the Jack messages:
apparent rate = 96000
creating alsa driver ...
hw:1,0|hw:1,0|2048|2|96000|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 96000Hz, period = 2048 frames (21.3 ms), buffer = 2
periods
ALSA: final selected sample format for capture: 32bit integer
little-endian
ALSA: use 2 periods for capture
ALSA: cannot set hardware parameters for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
If I set it to 3 periods per buffer, it just changes to:
ALSA: got smaller periods 2 than 3 for capture
All of this sounds like I'm just using parameters that the driver/card
doesn't like. I'd be grateful for the information if someone who has a
Multiface that works at 96kHz could post their Jack settings. I'm sure
this must be possible, but I'm apparently just not asking for the right
settings from the interface. The machine is a 3.2GHz AMD quad, so I've
got plenty of system bandwidth, and the card is the PCI-E version.
Addendum: This is what I get for not being satisfied. You'd think I'd
quit when I got solid 48kHz, but nooooo...
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
