This is Steinway_IMIS soundfont, version 2.2.
This version fixes the issue with loops. I hope this is the good one
and there are no more remaining major bugs.
Marcos is a little busy right now, so he asked me to make this fix. He
is thinking to make other improvements, so expect more updates soon.
Does anyone know of a good plugin that will generate subharmonics?
I would like to put a little more low frequency "oomph" into my bass
track. Preferrable LADSPA, but VST would work, too.
Thanks for any help!
> Ken Restivo wrote:
>> It has been over 7 years since I last messed around with writing Pthreads applications.
>> I recall it as a painful, ugly, brain-numbing task. I located an exercise I did back then to address the consumer/producer problem in Pthreads, and just the sight of it is giving me a headache.
>> I'm being lazy, so instead of researching everything that's out there, I'll ask here: can anyone recommend a relatively simple and painless abstraction library (GPL or LGPL of course) that will give me functions to create a thread in which I can stuff things into a ring buffer, and another thread in which I can pull stuff out of it?
>> By the way, I know that JACK has a very nice event buffer which is insanely easy to use (and I have), and makes multithreading almost transparent, but this isn't a JACK app.
> I don't know of any abstraction library, but creating/terminating a normal
> thread with pthread is really an easy task IMO. It's about 10 lines in C.
> For inter-thread communication there's Portaudio's ring buffer:
> It can easily be used out of Portaudio (I'm currently doing that), and it
> features memory barriers  which AFAIK Jack's ringbuffer doesn't.
> One problem with everything Portaudio is this heavy naming scheme. For a simpler
> API, you might like my little wrapper:
Nice. It's probably quicker to copy the jack_ringbuffer.c file out of jack
> Portaudio actually also offers a callback mechanism (with hidden thread
> creation), so if you're coding an non-JACK audio app, you might want to check it
> For thread synchronization, semaphores (man semaphore.h) are really easy to use.
> However, if you need a lock-free equivalent (for realtime, ...) phtread mutex
> and especially pthread_mutex_trylock are your friends.
Those friends can be really cranky sometimes though.
By using atomic operations instead, it's possible to avoid
a lot of headache by not having to synchronize at all.
Performance might be better too. Midishare has lockfree
atomic functions for lifo and fifi queues:
sorry, just realized that the hammond discussion mentioned below was here and
not at LAD, so please allow this kind of "crosspost":
this is my first post to LAD. The discussion about a hammond simulation "Fons
could you make us...", Beatrix and some research for writing a (german)
wikipedia article (stub) about the Vox Continental inspired me to hack a quick
organ program that simulates the internal signal flow of the "Connie" with JACK
MIDI input and JACK audio output.
This is for all those who might have tried seq24 with jack2.
Attached is a patch containing modifications made by
Stéphane Letz, the developer of jack2 who was so kind to
have a look into the seq24 code yesterday.
In the original setting, seq24 was not able to do a proper
client connection and failed working with jack2 transport. It also fixes the deprecated call to jack_client_new.
It applies to src/perform.cpp , hope it works as a patch...
Thanks very much Stéphane.
I'm thinking about finally upgrading from my cheap soundblaster+mic to
something of a little higher quality. I'm thinking along the lines of an
external firewire/usb box and some kind of low-cost mic.
I'd use it primarely for vocals, but I'd like the recording interface to
support 2-channel, for possible some piano recordings/etc. I also don't want
to spend very much, and would plan to get it used, on ebay.
What do you guys use or recommend?
> Message: 28
> Date: Mon, 01 Jun 2009 09:54:22 +0300
> From: Asmo Koskinen <asmo.koskinen(a)arkki.info>
> Subject: Re: [LAU] ubuntu realtime.
I did not take quotes from the following link because the whole thing deserves
This bummed be out so I had to quote this:
> Almost down for the count, Cory K.
The note was a plea for help so I would like to see what we can do.
There are so many things to discuss and so many possible directions to go in
Just thinking about it can be overwhelming
Free (not free beer, but freedom) is wonderful, but it ironically can be
more paralyzing than confinement, so let me start with a simple and self
I tried to write this list a few times, and every time it got too long and
complicated. At the risk of being flamed here is my simple list:
- Manual install (like arch Linux) is fine and probably preferred. (manual is
fine, but complete default instructions would be needed)
- specific hardware (i.e. motherboard, video card and audio interface) is fine
- most/all of the popular audio apps with a kernel that combined to create a
system that was extremely stable and had reasonable latency (less than 10ms?
Or maybe less than 7ms? What ever can be done with reasonable and reliable
- I would donate at least $100 per year (If a thousand people joined me that
would be $100K Could one person full time, or several people part-time sign
up for that?
- I would donate a few years in advance say three years (If this would help
someone/some-few decide to do this)
- I would also help out. This assumes the individual or small core team would
dedicate sufficient time to partition the tasks in a way that would facilitate
Ignoring resources (money, people, etc) is it reasonable to build and maintain
such a distribution?
Is $100k per year enough? If not how much is needed?
Are 1000 users at $100 reasonable to expect? How about 2000 at $50? Or 500 at
$200 (I would consider donating $200/year) Strike that If this existed today
I would donate $200.
I know that the conventional wisdom is that Linux audio is not for new Linux
users but I think that is the root of the chicken/egg problem that we have
here. A predictable, stable, reliable audio distribution may generate the
support that the particular distribution (and Linux audio in general) needs to
get to the next level.
Can we prime this pump with a conservative but very useful distribution?