> 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.
Cheers,
Jason Downer
Hello.
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
one?
Stomper does not work under wine :(
Thanks.
Hello.
I had a couple of articles on drum synths. Check
ftp://ftp.funet.fi/pub/sci/audio/devel/lad/drumsynth/
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.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
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.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
Hi Steve, thanks for the reply.
I will definitely look into using DSSI, looks like it
could be good once as supported as LADSPA is (I'd
never even heard of it before your post, although
that's probably just me). Is it intended as an
eventual LADSPA replacement? I never really saw the
need to divide plugins into 'instruments' and
'effects', and it seems like DSSI can do both.
Stefan Turner
> It would be more practical to do it as a DSSI
plugin, LADSPA has no way
> to
> indicate that you want to load files during runtime,
and no UI.
>
> In DSSI you can load the impulse in the "UI"
process, perform the FFT
> on
> it and send it ot hte DSP code with configure().
Once there the DSP
> code
> can the overlap-add/save on it.
>
> - Steve
___________________________________________________________
Win a castle for NYE with your mates and Yahoo! Messenger
http://uk.messenger.yahoo.com
Hi,
this question is mostly for Thomas Charbonnel, I suppose, as he was
working on this a while ago...
Is the Alsa driver for the RME HDSP MADI already up and running?
sincerely,
Marije
Hi,
Hopefully this is within the scope of this list but following a lot of
recent googling, there doesn't appear to be any interest in
"open-sourcing" anything related to DVD-Audio.
As you may know, commercially authored DVD-Audio disks have three very
unfriendly features - encryption, watermarking and Meridian Lossless
Packing (MLP). I am assuming that these are some of the reasons
developers have not become interested in DVD-Audio.
However, none of those features are compulsory, and if you remove those
obstacles (which I am not interested in overcoming - simply avoiding),
you are left with a standard which allows 18 combinations of samplerate
and sample wordsize for 2-channel stereo audio (including 16-bit/44.1KHz
RedBook, and going all the way up to 24-bit/192KHz), plus a range of
6-channel uncompressed surround sound formats.
My aim is to produce a set of GPL'd tools to both author, "un-author",
and play such unencrypted, uncompressed disks, and am curious to know if
any other developers have an interest in this area or not.
To this end, I've started the "dvd-audio" project at sourceforge -
http://sourceforge.net/projects/dvd-audio/ I have not yet populated the
site with HTML content or any of the software I'm in the process of
developing, but there is a "dvd-audio-devel" mailing list which anyone
is welcome to subscribe to.
I should reiterate that I'm not interested in investigating features
such as encryption or MLP - I simply wish to be able to author my own
unencrypted and uncompressed DVD-Audio disks using my own music, which I
can then play back either on my hardware DVD-Audio player or on my PC,
all using free software
Regards,
Dave.
My impression is that more and more applications are moving to
OSC for inter-process communication.
Question 1: Are most audio/midi applications converging on OSC?
Are there any moving away from it? Or are there other strong
contenters in this area?
AFAIK all linux audio/midi applications use an arbitrary UDP port
number, and rely on manual configuration of this for the server and
all clients.
With OSC popularity increasing this will pose a growing problem
for end users who have to configure the ports, and for developers
of client programs that want to interact with multiple servers.
The answer to this issue is service discovery, which was recently
discussed on the OSC_dev list [1]. That thread leads to a product
called howl [2], which is an open implementation of mDNS/redezvous/
zeroconf (take your pick). It provides 3 daemons (of which 2 should
be run) and some libraries.
Using this implementation all applications would (ideally) register
or discover services using the howl libraries. Apart from this, the
programs would communicate via OSC.
To me this seems like a lot of overhead for a relatively small gain.
OTOH it seems like a very flexible and future-proof solution.
An alternate way I've been considering is an OSC-based service
discovery daemon. It would accept OSC messages to register and discover
services. The advantage of this is that it only uses 1 small daemon,
but more importantly that applications do not need to use any additional
libraries besides the OSC one (<insert liblo plug here> :). So far I
can see 6 input messages for such a daemon, with 4 response messages.
The disadvantage is that the daemon would still need an arbitrary port
number, and all applications would need to know it (at least for a while).
For intra-host discover the daemon could still interact with howl or
something like it if that is needed. But if this approach is successfull
we could request one dedicated port from IANA.
Question 2: Are there other better alternatives?
Question 3: Which alternative is better or do you prefer? (mDNS/OSC-daemon)
The only thing I haven't mentioned yet is LASH. Well, in my opinion it
is the prime example of an application that needs to interact with all
other linux audio/midi appications. As such, I think it could gain most
from a service discovery scheme. And there has been talk about using
OSC for it [3].
Comments/suggestions/questions? Blast away! Phasers on stun please!
And Steve: appologies for stepping on your turf.
Best regards,
--
Martin
[1] http://www.create.ucsb.edu/pipermail/osc_dev/2004-December/000841.html
[2] http://www.porchdogsoft.com/products/howl/
[3] http://music.columbia.edu/pipermail/linux-audio-dev/2004-August/009288.html
[4] http://www.cnmat.berkeley.edu/OpenSoundControl/
---------------------------------------------------------------------------
30 years from now GNU/Linux will be as redundant a term as UNIX/MERT is
today. - Martin Habets
---------------------------------------------------------------------------
On Mon, 2005-02-21 at 15:42 +0100, CC-Band wrote:
> hi,
>
> i tried out the agnula demudi project.
>
> jack & hydrogen works fine but sometimes hydrogen crashes immediately.
> what can i do to get information, why?
I am having the exact same problem with Hydrogen. Most of the time it
crashes immediately. If I start it repeatedly it will eventually
succeed.
I have found it's a lot more likely to segfault immediately on startup
if JACK is run in verbose mode, and the crashes are more likely with
lower latencies. 32 frames almost always crashes. 128 almost always
succeeds. 64 is hit or miss. Lower latencies are less likely to crash
on a faster machine.
I have reproduced this across several versions of JACK and Hydrogen on
multiple machines.
I got a backtrace from gdb and this is where it crashes (from
src/lib/Hydrogen.cpp):
inline void audioEngine_process_clearAudioBuffers(uint32_t nFrames)
{
*---> memset( m_pMainBuffer_L, 0, nFrames * sizeof( float ) ); // clear main out Left
memset( m_pMainBuffer_R, 0, nFrames * sizeof( float ) ); // clear main out Right
As soon as it goes to clear the audio buffers, boom.
As the problem is timing sensitive it's certainly a race condition. I
cannot determine whether the bug is in JACK or hydrogen though.
I have reported the problem on hydrogen-devel and got no response
whatsoever. It's getting to be frustrating as the bug is 100%
reproducible, but I can't even get the Hydrogen developers to ACK my bug
report.
Here is the backtrace.
Lee
(gdb) bt full
#0 0xb759949b in memset (dstpp=0x0, c=0, len=512)
at ../sysdeps/i386/memset.c:65
d0 = 128
dstp = 0
x = 0
#1 0x0807da0f in audioEngine_process_clearAudioBuffers (nFrames=128) at
src/lib/Hydrogen.cpp:702
No locals.
#2 0x08074381 in audioEngine_process (nframes=128, arg=0x0) at
src/lib/Hydrogen.cpp:746
res = 0
startTimeval = {tv_sec = 1107297223, tv_usec = 403047}
sendPatternChange = 183
res2 = -1218109252
renderTime_start = {tv_sec = -1217118338, tv_usec = -1208618368}
i = 3086349340
pNote = (class Note *) 0x1
renderTime_end = {tv_sec = 91845001, tv_usec = -1084229004}
ladspaTime_start = {tv_sec = 52302212, tv_usec = 0}
ladspaTime_end = {tv_sec = -1208836712, tv_usec = 0}
val_L = -0.87490797
val_R = 1.40129846e-45
fRenderTime = 0
fLadspaTime = 1.821688e-44
finishTimeval = {tv_sec = -1208834440, tv_usec = -1084229128}
sampleRate = 1.17287768e-35
#3 0xb7f2e9f9 in jack_client_thread (arg=0x82f59d0) at client.c:1264
control = (volatile struct {...} *) 0xb73a3000
event = {type = GraphReordered, x = {n = 0, port_id = 0, self_id
= 0}, y = {n = 1, ptid = 1, other_id = 1}}
status = 0 '\0'
c = 0 '\0'
err = 0
#4 0xb773fe51 in pthread_start_thread (arg=0xbf5ffbe0) at manager.c:309
default_params = {__sched_priority = 0}
request = {req_thread = 0x0, req_kind = REQ_CREATE, req_args =
{create = {attr = 0x0, fn = 0, arg = 0x0, mask = {__val = {
0 <repeats 32 times>}}}, free = {thread_id = 0}, exit = {code
= 0}, post = 0x0, for_each = {fn = 0, arg = 0x0}}}
outcome = (void *) 0x0
#5 0xb75f96ea in clone () from /usr/lib/debug/libc.so.6
fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres =
{mnt_fsname = 0x0, mnt_dir = 0x0, mnt_type = 0x0, mnt_opts = 0x0,
mnt_freq = 0,
mnt_passno = 0}, fs_ret = {fs_spec = 0x0, fs_file = 0x0, fs_vfstype
= 0x0, fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0, fs_passno = 0}}
__elf_set___libc_subfreeres_element_fstab_free__ = (const void
*) 0xb762dce0
Greetings:
My ancient bright.net address is finally closed, as of now. I'll
receive no more email at that address (current addy is in this mail's
header). If you've sent any mail to me over the past two days it's
probably been lost: I inadvertently cleared my Inbox for the older
account, so please resend if you've sent anything directly to me
recently. All my bright.net pages will be revived at another location,
I'll send a note to this list at that time to say where & when.
Best,
dp