Hi,
Just spotted this in the wild.
http://quicktoots.linuxaudio.org/toots/codecs/codecs.pdf
Food for thought re the looming VP8 patent battle.
Microsoft just got Nokia and will do their best to take out MeeGo and all
the support for open source that Nokia currently embraces. We certainly
don't need them to take out html5 video too.
Reading through it's typical of Microsoft though. The only thing we can
guarantee from that bunch of crooks is that they cheat, lie and steal. At
least they are consistent ;-)
--
Patrick Shirkey
Boost Hardware Ltd.
Hi fellas,
I know there is a latency compensation for vst-plugins in Ardour, but
is there a way to make it (compensation) work for a VST-plugin in
Rosegarden too?
I have a heavy VSTi that I use in Rosegarden with it's internal
DSSI-VST. while I record the midi from my keyboard I use a latency of
4 ms but to record it without xruns in need to run jack with 92,. ms.
While syncing Ardour and Rosegarden latency is not compensated.
How can I manage this?
Thanks
On 02/13/2011 03:27 PM, Philipp Überbacher wrote:
> Excerpts from Robin Gareus's message of 2011-02-13 13:12:43 +0100:
>> On 02/13/2011 11:31 AM, Philipp Überbacher wrote:
>>> Excerpts from Robin Gareus's message of 2011-02-11 16:56:42 +0100:
>>>> On 02/10/2011 12:36 PM, Mike Cookson wrote:
>>>>> Cool, thanks. Btw before jack was available, i some files could
>>>>> not be played back due to mismatch of some file format details.
>>>>
>>>> Yesterday paulstretch 2.1 came out:
>>>> http://hypermammut.sourceforge.net/paulstretch/
>>>
>>> Can you tell me how to get sound out of it? Version 2.1 (the 'about'
>>> says 2.2). I tried with and without jack, mp3, ogg and wav files,
>>> without any success. I never see jack ports appear. With wav files I
>>> get the output: AInputS::seek 0 0 54110260 - possible audiofile bug
>>> (it always seeks to the end of the file)
>>>
>>> Portaudio seems to work, tested with audacity. Any ideas?
>>
>> Did you compile it with './compile_linux_fftw_jack.sh' ?
>>
>> I start JACK, start paulstretch, load some mp3 and just press play.
>> works just fine with .wav files too and the samplerate does not need to
>> match JACK's samplerate..
>>
>> FWIW: you can set the environment variable JACK_AUTOCONNECT
>> to decide the port-connection behaviour. The default is
>> 'system:playback_' - setting it to "DISABLE" will leave the output ports
>> unconnected.
>>
>> robin
>
> Thanks Robin, it was compiled with './compile_linux_fftw.sh'. I don't
> know why I didn't get audio with alsa either
because paulstretch does not have an ALSA output.
portaudio to ALSA (or pulseaudio or JACK) should work though, but may
require additional setup. Here (debian/squeeze) it (kind of [1]) works
with alsa-plug, but I prefer the native JACK port of course..
> , but it works fine now with
> jack, thanks.
> Paulstretch is quite crazy, I like it :)
yeah, it's amazing.
robin
[1] there's no resampling and sometimes choppy playback with portaudio.
--
Robin Gareus
web: http://gareus.org/ mail: robin(a)gareus.org
lab: http://citu.fr/ chat: xmpp:rgareus@ik.nu
Public Key at http://pgp.mit.edu/http://gareus.org/public.asc
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
Fri, 11 Feb 2011 23:18:00 +0100 письмо от Robert Jonsson <spamatica(a)gmail.com>:
> Hi guys,
>
> MusE does indeed have a pianoroll and the current qt3 version should
> be usable under those circumstances, haven't tried in a while though.
>
> Regards,
> Robert
>
> 2011/2/11 Josh Lawrence <hardbop200(a)gmail.com>:
> > On Fri, Feb 11, 2011 at 1:13 PM, Ken Restivo <ken(a)restivo.org>
> wrote:
> >> Is there a lightweight, fast, not-extravagant-with-screen-real-estate
> (i.e. will work in 1024X600) piano-roll sequencer?
> >
> > a couple of random ideas:
> >
> > 1. does muse have a piano roll? it can be started with the audio
> > engine disabled, which I like.
> > 2. qtractor does have a piano roll, and I enjoy using it. I have no
> > idea if it will run on that hardware, tho.
> >
> > --
> > Josh Lawrence
> > www.hardbop200.com
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user(a)lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-user
> >
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
I just got nice hint, how to reduce screen usage using qt4, qt4 probably gtk2 apps. Note, however, you need ability of WM or GUI toolkit (i.e. again, qt4) to hide toolbars for inactive windows. I'm using kde, and it works at least for qtractor (just ried).
1. Detach __ALL__ toolbars (from file to special).
2. Some toolbars may be hidden, if are not necessary for such quick access.
3. Use window manager functionality to "dock" (really - just place) toolbars on screen - move them with... for me - Alt + MButton, instead of using handler. In this case resistance will affect them, that is very necessary.
Hi All,
I have been working on the Neil tracker program recently, and hit a
weird bug that seems to affect only my computer! I get a segfault when
trying to use fft.h (which is used by the oomek 303 emulator, which has
incidentally now been released as open source - a really good sound
IMHO, but I digress). The following test code results in a segfault on
my computer - an AMD XP2500+ (but no-one elses as far as I can tell).
bt:
Program received signal SIGSEGV, Segmentation fault.
0x080486d7 in IFFT (fftBuffer=0x8049b00, fftFrameSize=2048, sign=1) at
fft.h:51
51 tr = *p2r * ur - *p2i * ui;
Any thoughts as to what might be happening?
James
test.cpp:
#include <cstdio>
#include <cmath>
#include "fft.h"
float a[4096];
int main ()
{
for(int i=0; i<4096; i++)
{
a[i]=0;
}
IFFT(a,2048,1);
printf("%f",a[1]);
}
fft.h:
#define M_PI 3.14159265358979323846
void IFFT(float *fftBuffer, long fftFrameSize, long sign)
/*
FFT routine, (C)1996 S.M.Sprenger. Sign = -1 is FFT, 1 is iFFT (inverse)
Fills fftBuffer[0...2*fftFrameSize-1] with the Fourier transform of the
time domain data in fftBuffer[0...2*fftFrameSize-1]. The FFT array takes
and returns the cosine and sine parts in an interleaved manner, ie.
fftBuffer[0] = cosPart[0], fftBuffer[1] = sinPart[0], asf. fftFrameSize
must be a power of 2. It expects a complex input signal (see
footnote 2),
ie. when working with 'common' audio signals our input signal has to be
passed as {in[0],0.,in[1],0.,in[2],0.,...} asf. In that case, the
transform
of the frequencies of interest is in fftBuffer[0...fftFrameSize].
*/
{
float wr, wi, arg, *p1, *p2, temp;
float tr, ti, ur, ui, *p1r, *p1i, *p2r, *p2i;
long i, bitm, j, le, le2, k;
for (i = 2; i < 2 * fftFrameSize - 2; i += 2) {
for (bitm = 2, j = 0; bitm < 2 * fftFrameSize; bitm <<= 1) {
if (i & bitm) j++;
j <<= 1;
}
if (i < j)
{
p1 = fftBuffer + i;
p2 = fftBuffer + j;
temp = *p1;
*(p1++) = *p2;
*(p2++) = temp;
temp = *p1;
*p1 = *p2;
*p2 = temp;
}
}
for (k = 0, le = 2; k < log(fftFrameSize)/log(2.); k++) {
le <<= 1;
le2 = le>>1;
ur = 1.0;
ui = 0.0;
arg = (float)M_PI / (le2>>1);
wr = (float)cos(arg);
wi = sign*(float)sin(arg);
for (j = 0; j < le2; j += 2) {
p1r = fftBuffer+j;
p1i = p1r+1;
p2r = p1r+le2;
p2i = p2r+1;
for (i = j; i < 2 * fftFrameSize; i += le) {
tr = *p2r * ur - *p2i * ui;
ti = *p2r * ui + *p2i * ur;
*p2r = *p1r - tr;
*p2i = *p1i - ti;
*p1r += tr;
*p1i += ti;
p1r += le;
p1i += le;
p2r += le;
p2i += le;
}
tr = ur*wr - ui*wi;
ui = ur*wi + ui*wr;
ur = tr;
}
}
}
hi
i've looked on the archive of the list but i didn't find anything
i just stumbled upon this
http://www.dinisnoise.org/<http://www.dinisnoise.org/videos/>
...
has anyone ever heard of it ? its a drone synth.
there are really nice videos which makes me really want to try it out !
jy
Thanks for the suggestions! I think I'll move the
context-sensitive popup menus into the main version --
I assume that's what you mean by right-click menus?
The looped play stuff is broken -- I hadn't noticed
the problem. I'll also add some mouse-oriented way
to play from the cursor.
For multichannel files, you can set the 'unite' and
'sync' buttons and all channels will be displayed
and acted-upon together -- is that what you have in
mind?
On the zoomed FFT -- it's been on my TODO list for
about a decade. You can drag the frequency (x) axis
to zoom in on the lower frequencies, and there's a
complicated way to zoom using the spectro* variables.
To dump the current spectrum to a text file, you
can use the peaks function:
(peaks "fft.data")
for example. Anyway, I'll get to work on this
stuff; GUI here I come (sigh)... Thanks again!
Hey, I think I posted this tune in an earlier reincarnation about a year
ago or so. Here it is again, with rerecorded drums and upright bass
instead of the acoustic one.. I might add that this is the grand piano I
sampled to create the Salamander grand piano library.. only It's
recorded with a zoom h4n.. Actually, most of it is, It's all h4n preamp
and AD but the bass is miced with a mic I built myself(based upon the
wonderful bruce swedien #1 microphones) and the snare is some cheap
t-bone and the kick is a beyerdynamic opus 99.
http://sharpattack.bandcamp.com/track/trace-of-events
Enjoy!
On Thu, Feb 10, 2011 at 6:40 PM, Leigh Dyer <lsd(a)wootangent.net> wrote:
> On 11/02/11 06:00, Luke Peterson wrote:
>
>> At my last show I decided to experiment a bit and use a Rock Band 3
>> keytar via a MidAir wireless midi adapter. The RB3 controller is
>> midi-compliant but completely undocumented, and while I have figured out
>> how to do most useful things on it such as octaves, pitch bend, and
>> modulation, I cannot figure out how to use any channel except channel 1
>> (and splitting to channel 10 on the lower half of the keyboard by
>> pressing one of the buttons -- I forget which). So I ended up playing
>> the B3 with my keytar, but had to sit back down at my controller to play
>> anything else, which is a bummer.
>>
>
> It sounds like you've figured out most of it anyway, but CDM did a write-up
> on the RB3 keytar that covers its MIDI functionality:
>
>
> http://createdigitalmusic.com/2010/10/hands-on-rock-band-3s-keytar-a-surpri…
>
> Unfortunately it looks like it's stuck on channel 1 with the exception of
> that drum split mode you mentioned.
>
> How has the keytar been for you otherwise? I have one myself, but I haven't
> done anything serious with it yet.
>
RB3 keytar has been good. I've used it at one show and three practices thus
far. It is really nice to have something small and portable that I can use
without having to deal with a stand, etc. It's taken my rig from something
that requires a large (at least) four-wheeled vehicle to get around to
something I can toss into a backpack and transport on a bicycle. The most
significant decrease in the amount of regular exercise I get since I went
from an 88-key weighted board to my Axiom 61. I've been drooling over
Roland's AX-n for a while now, but ultimately the Rock Band game controller
is far more portable than any of the "pro" keytars I've run across. From
specs it looks like the RB3 controller is 11" shorter than the Lucina AX-09
and has about half the heft.
The hardest thing to get used to is switch-handed accompaniment: clicking
the down-octave button a couple times before playing a left-handed part with
my right hand while our guitarist or horns are playing, then clicking
up-octave twice to pick up a lead is a bit awkward.
This article you cite is interesting; I figured out all the same features
through tooling around with the keyboard for 30 mins in kmidimon. I'm not
sure I agree with the complaints about the pitch bend (I have other
complaints about the touch strip). If you've played the game at all, you get
quite accustomed to holding the button down while hitting the touch strip
and playing at the same time (you get bonus points for doing this). If
anything, I find that I will accidentally hit the pitch bend and not notice
that I've de-tuned myself against the rest of my band, then upon hearing the
de-tune through a monitor spook myself into thinking I forgot how to play a
song. The upside of this is it may train my band to think it is more likely
my instrument's fault than my own when I'm playing wrong notes :P
The article didn't note that the controller has active sensing -- quite
important for a battery-powered device.
I find the simple powering-on-and-off of the device to be a bit of a pain.
If I haven't manually powered down the controller by holding down the Xbox
button for a couple seconds before I disconnect the midi cable or power-down
my laptop, it will sit there and blink til infinity, looking for an Xbox
connection. If I want the green flashing light to cease and I'm not in
vicinity of my Xbox, I have to plug a hot midi cable back into the
controller (this doesn't work if I just plug a disconnected midi cable in),
hold the Xbox button, then shut everything else down afterwards.
I'm familiar with the importance of connection order already with my rig: I
learned to plug my Fast Track Pro in to USB before any other USB midi device
or else I have to change around my JACK config to point to a device other
than hw:1. But now I have to remember to manually power down my keytar
before unplugging and disassembling my rig, too.
Otherwise, everything else is great. The only change I'd make is to have the
25 keys go from F to F instead of C to C, but I suppose that's something I'd
have to take up with the entire industry.
Luke
-----
Luke Peterson