Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

[linux-audio-dev] XAP: Some thoughts on control ramping

by David Olofson

I realized a few more things about ramping when messing with Audiality's voice mixers: 1) The STOP event *is* rather handy, as it has no value argument to be calculated or processed. If you're doing internal ramping (or coefficients) instead of using the ramped value directly, STOP just means you stop ramping your internal controls. SET (which is what you must use if you don't have STOP) is supposed to *set* a new value, obviously, and would normally result in the coefficients being recalculated, regardless of current stat. 2) RAMP events with a <target_value, duration> aim point do not guarantee *anything* but the value hitting the aim point. Plugins are not required to perform truly linear ramping; only something that "sounds similar". If you would SET halfway to the aim point, you would get a click, unless the receiver is doing *truly* linear ramping internally! 3) Ramping with aim points means you don't have to know where you are, to set up an accurate ramp to a desired value. You don't even have to know if the current value is above or below the target value. Now, a STOP event before the aim point of a ramp in progress would not always give you *exactly* what you want, but close enough. (Provided the receiver "fakes" linear ramping well enough - which it basically *must* do anyway, for ramping to be usable.) Remember that if you set up a new ramp, it will take you to the new aim point regardless of the current value. So, as long as you don't *SET* before (or after) the aim point, you're safe. 4) Normally, you'd probably re-aim with RAMP, but in some cases, you really just want to hold where you are indefinitely. That's when you would use STOP - or fake it with a "long" ramp to what should be the current value. Both should work, but STOP is easier and faster. 5) A more serious issue is that if control events are not allowed while ramping, except at the time of the aim point, there is no way to avoid sending one RAMP event for each block while ramping. You can't aim further ahead than the first frame of the next block, or you might have to break in and adjust the aim before you hit the aim point. This could potentially be a serious performance issue with low latency hosts, since it means 1000+ RAMP events (and the related transformation overhead) per ramping control. As a real life example of the alternative, the RT envelope generator in Audiality uses one event per node. (DAHDSR currently, which means 7 nodes.) Extra events will have to be inserted to handle real time modulation of the envelope (volume and pan controls, at the very least), but there's never a need for more than one extra event per linear section added. Questions: A) Is it necessary to require that aim points are within the current block, to avoid "re-aiming"? B) Is STOP useful enough to be in XAP? Anyway, I think I have answered my own questions by explaining all this (A: Yes, or complex effects won't mix with low latency, and B: no, you'll probably end up using RAMP all the time anyway) - but I'm still interested in comments. This might not be all there is to it. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---

23 years

[linux-audio-dev] Simple reverbs

by David Olofson

Well, I got the new device subsystem working in Audiality, although I've only finished the SDL audio driver. ALSA 0.9 rawmidi more or less finished, OSS audio is a mess, and there's no OSS rawmidi yet. (Although that's rather trivial; basically a stripped down version of ALSA rawmidi.) Anyway, I got sidetracked - as usual. ;-) First, I started playing with a noise modulated delay line, but didn't find the results very interesting. So I decided to run a bunch of fixed feedback delay lines in parallel - and that sounded a lot more interesting: It became a pretty neat reverb. :-) With 16 delays and exponential or exponential +/- Golomb ruler, it sounds great for "normal" sounds, but has some problems with transients; it's not dense enough. However, with these uneven delay time distributions, it doesn't sound metallic at all. It rather turns the transients into some sort of "noise" (sounds like random granular synthesis, basically), that soon becomes this "shhhh" most of us desire. With even/linear delay time distribution, it still sounds pretty good, but it starts to remind of a gong simulator or something. Plate reverb, maybe... Interesting, but not what I was looking for - although I'm throwing all interesting variants in, so they can be selected through a plugin control. With 32 delays, it starts to sound *real* interesting - but it also starts to abuse my PC133 RAM pretty seriously. It won't run real time on my P-III 933 above some 48 delay lines, although this is with 32 bit buffers of 8192 samples each. This can be improved upon a lot, since I'm only using a tiny fraction of the maximum delay times with that dense settings. (Like 300 +/- 100 samples.) Also, it's all integer, so I could probably use 16 bits. I have no feedbacks in beetween delays; just one local, LP filtered feedback per delay. Every other pair of delays is stereo reversed. Tried some network feedback setups, but I couldn't figure out any truly useful configurations. Untested idea: Have multiple feedbacks for each delay line. (The old "reverb" of Audiality is actually just one stereo delay line with multiple feedbacks, BTW.) The idea is that, while not as effective as separate delays, this is a lot cheaper, so I might get more density/cycle. Oh, and I'll try the well known delay time modulation trick, of course. Maybe using filtered noise instead of periodic LFO waveforms? Thoughts? Any ideas for useful cross feedback configurations? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---

23 years

[linux-audio-dev] Tkeca 1.0.2 released!

by Luis Pablo Gasparotto

Changes: - Bug when .ecasoundrc was not in ~/ directory (Ecasound 2.2.0) - Bug when no ladspa directory defined in ecasoundrc http://www.sourceforge.net/projects/tkeca Regards, Luis Pablo Ahora pod�s usar Yahoo! Messenger desde tu celular. Aprend� c�mo hacerlo en Yahoo! M�vil: http://ar.mobile.yahoo.com/sms.html

23 years

[linux-audio-dev] rewire comes to protools

by Paul Davis

http://namm.harmony-central.com/WNAMM03/Content/Propellerhead/PR/ReWire-2-P… aka: "not enough developers have licensed DirectConnect". sure would be nice to get JACK to allow the first app started to become the server ... --p

23 years

[linux-audio-dev] interesting info regarding hdsp behavior

by Ivica Bukvic

Hi all, I've been messing with hdsp and found out an interesting issue. After installing the driver for the first time onto the xp machine I also had no sound coming out of the soundcard even though totalmix app showed levels to be up. After clicking on the levels and/or moving them a bit, suddenly the sound was there (as if the default values were there only in the app itself, but did not affect the actual levels on the card until they were moved for the first time). I was wondering maybe this is the problem we're having in Linux, where the card loads just fine, but for some reason there is no sound until a reboot has taken place. I know this may be completely stupid thing to pursue, but since I've heard of no fix for this issue, I thought this may be a possible culprit. I am still struggling with the Linux driver (I got the card working on an Dell Inspiron 8200 where the card posts and everything supposedly works, but there is no sound coming from it), so perhaps as dumb as this sounds, this may be the solution to the problem we've been having with the hdsp in Linux. I should also mention that I am using hdsp pcmcia interface and that I've flashed it using the latest update from the rme-audio website (could this also have something to do with it?). Any info on this issue is greatly appreciated. Sincerely, Ivica Ico Bukvic

23 years

[linux-audio-dev] calling snd_seq_open in dynamically linked code

by Dave Griffiths

I'm getting errors when I call snd_seq_open in a plugin, which go away in a standalone test app: ALSA lib dlmisc.c:100:(snd_dlsym_verify) unable to verify version for symbol snd_config_hook_load ALSA lib conf.c:2655:(snd_config_hooks_call) symbol snd_config_hook_load is not defined inside (null) ALSA lib conf.c:3066:(snd_config_update_r) hooks failed, removing configuration calling: snd_seq_open(&seq_handle, "default", SND_SEQ_OPEN_INPUT, 0) What could be the reason for this? cheers, dave

23 years

[linux-audio-dev] sooperlooper goes PD

by Jesse Chappell

The SooperLooper LADSPA plugin now comes with PD patches! For those that might not remember, SooperLooper is a LADSPA plugin that emulates the Gibson-Oberheim Echoplex Digital Pro looping sampler. Go get more info and download it at its new address: http://essej.net/sooperlooper/ See the screenshot of the PD patches in action here: http://essej.net/sooperlooper/sooperlooper_pd_shot.png It is controllable via the PD GUI or MIDI program change messages from your footcontroller (the ideal interface). Unfortunately, there are bugs in the plugin~-0.2 external that seems to be around. I made a source patch that fixes the output control message bugs, and extended them to include the output control port index as well. You will need this patched version of plugin~ to run SooperLooper in PD properly. Get the patch here: http://essej.net/sooperlooper/pd-plugin0.2-patch.diff If someone on the pd-devel list could forward this, I would much appreciate it. Dave Phillips, could you also update the web address on your LM&S pages with the new address above? Enjoy... please post with any problems/suggestions. jlc

23 years

Re: [linux-audio-dev] Route Stantons Final Scratch to internal sound cards?

by Patrick Shirkey

>What I think could be possible is using (writing a driver for) the >scratchamp with OSS or ALSA drivers, as they seem to be USB soundcards >by creative. Those will have standard chipsets. >But that wasn't the question I guess... If you are interested in trying to get it working with alsa then you need the usb-audio driver. Installing it and inserting the module will tell you pretty quickly how easy it will be to get working. The alsa usb-audio driver is significantly more advanced than the oss version which it was based on. If it doesn't work for you then sending in the info from lsusb to the alsa-devel list will help a lot. Have a look at the generic instructions for usb in the alsa-docs. http://www.alsa-project.org/alsa-doc/ Patrick. --

23 years

[linux-audio-dev] Route Stantons Final Scratch to internal sound cards?

by Modnogg

Hi! Do you think it's possible that Final Scratch could use two internal Soundcards instead of the two external ones? I bought this Final Scratch package and opened the external box. This looks like a USB-Hub witch two external Creative USB sound cards. But I don't like external sound cards and especially not the creative ones! Do you think it's possible to route the USB sound cards to my internal sound cards? I could use the sound driver library from linux. But my problem is how to link the software to other soundcards? Thanks for an answer! Modnogg

23 years

[linux-audio-dev] Anyone hacking JACK or ALSA support for Audiality?

by David Olofson

I'm rewriting the audio and control I/O code right now, and I'm adding ALSA 0.9 audio and MIDI support while I'm at it. ALSA 0.5 support will probably be ditched in the process, as I can't test it, and don't care much. OSS I/O and SDL audio output will still be there. The new design is based on a common device struct for all I/O devices, and drivers and APIs are supported by adding implementations behind that, C++ polymorphic style. I think this will make it a lot easier to add support for other I/O APIs. It also comes with a string based selection interface that can easily be hooked up to the command line, config files or whatever. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---

23 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev