> I'm hoping that you're thinking of a realtime display, in which the
> peaks roll off to create a true waterfall effect.
Baudline (http://www.baudline.com) is a fantastic viewer that does fft
cascade. I've used it for a couple of years, and it is great for figuring out
how different sounds "work", and it has an oscilloscope-type display as well.
I finally started making my pet music project and realized I need a
drum synth to make some cool sounds. psindustrializer is good but also
need some tr-909-style sounds. I remeber from my old windoze days I
used a nice piece of software called Stomper. Does anybody know any
software for linux with comparable capabilities? Or we need to write
Stomper does not work under wine :(
I had a couple of articles on drum synths. Check
I built the circuit in a00*.jpg at the time when this article
was fresh. The article b00*jpg mentions an earlier article.
I will check that out at library.
Hmm.. I coded a drum synth for Commodore VIC-20 at the time.
VIC provided an audio chip with three oscillators, noise,
and a common volume if I remember correctly. What I did was to
modulate osc pitch and volume parameters with a fast and accurate
(compared to Basic) assembly code. The drum sounds were assigned to
the keys. This was about 1984, inspired by Yamaha's digital RX drum
synths, not by analog drums.
for developers of open source graphics software
>From: "Levi D. Burton" <ldb(a)puresimplicity.net>
>does the idea of documenting various lad design patterns make
>sense to anyone?
Such "LAD Gems" doc would be much needed here too.
(For audio dsp gems, take a look at "musicdsp.org".)
I would appreciate if somebody would take a look at
Ardour and document best gems found there. E.g., the GUI
and audio thread separation and start up sequences.
Likewise for Linuxsampler and one of its GUI frontends.
for developers of open source graphics software
>Good to see someone other than Grame' guys try to "push" MidiShare.... ((:
well, i'm only pushing because i'm using it, and i can't use ALSA. :)
>But Jay, MidiShare cannot help in terms of synchronizing MIDI with
>audio at the sample level..... MidiShare events are 1 millisecond
yes, i understand that now .. i initially mis-understood pd's idea on
this, since under OSX, MidiShare is 'sync'ed' using an Audio timer..
but, it would in fact be interesting if MidiShare had a new 'Audio
Event' type added to it, from the standpoint of timestamp'ed events
.. thats feasible, i think .. of course, this would only be relevant
if one was already using MidiShare, but it would be a nice addition
to what I consider a very clean and productive API .. /me goes off to
prepare an "AudioShare" patch, heh heh ..
>But well the Linux official API is now ALSA, and the OSX official
>API is CoreMidi..... and we have to live with that.
what makes an API 'official' under Linux, anyway? in my opinion, the
old maxim, "use what works" applies .. and ALSA has proven to be a
very difficult and annoying thing to get set up and working (witness
jwz' recent terror) .. while MidiShare has (for the most part) been
smooth and dreamy.
but .. ymmv, yo.
i have searched the web and the ALSA pages and found very little
information concerning the status of the development efforts, if
any, and who might be interested.
This card seems like a good means to hook a notebook into a DJ
mixer, splitting the output into 2 or 3 stereo outs.
I am very interested in such a driver, but I dud find a reference
to a kernel PCMCIA bug on the ALSA sound card list. How much of a
showstopper is it?
Is there any problem that could be fixed by throwing money at it?
And, if it is a money problem, if the funds were available, how
long would it take for a driver to be completed? My minimum
requirement would be a driver that would support the Audigy 2 ZS
Notebook as well as an Audigy Platimun or SB Live! is supported.
I am trying to correct some factual errors in wikipedia regarding FM
synthesis (aka phase modulation.)
The page in qustion is here:
My current corrections are in italics. Further corrections appreciated
I am currently looking at the Casio section near the end (regarding
phase distortion.) Wasn't this technique developed way back in the 60's
by french academics?
mvh // Jens M Andreasen
(and yes, somebody ought to rewrite the whole page from scratch :))
Since I finally ordered my Multiface, I also started to write
a small program which I am going to need since hdspconf and hdspmixer
are both GUI only.
hdsposc will offer the RME mixer and the metering functionality
Why do I write this mail? I'd like to know if someone else
could also make use of this tool. If so, I'd like to hear
your input what you'd want to exactly do with it. If no one responds,
I'll save coding time by ONLY implementing the Multiface (since thats
what I can test) and probably not polish it much, since
what I need is probably very basic.
Oh, and BTW, during coding of hdsposc a question arose:
Is it recommended practice to immediately close a hwdep device
again after performing a single operation, or would it be OK
to leave the hwdep handle open during runtime and only close it
again on program shutdown?
I have a question regarding linking multiple plugins into a single
if I do:
$ ld -shared -o plugins.so plugins/*.o
- then ld complains that g_psStereoDescriptor and g_psMonoDescriptor
as well as _init and _fini functions are duplicate and does nothing.
If I try:
$ ld -shared -z muldefs -o plugins.so plugins/*.o
- this does some wizardry on changing the duplicate functions names
(_init and _fini) and in the host only the last plugin in the .o
files list is seen.
As I understand I cannot change the names of _init and _fini because
these are standard for libraries (or not?) and names of
g_psStereoDescriptor and g_psMonoDescriptor are standard for a LADSPA
plgin (or not?)... But what should I do? Or is is better to keep the
plugins in separate .so files?
Thanks very much!