Linux-audio-dev November 2002

linux-audio-dev@lists.linuxaudio.org

87 participants
85 discussions

Re: [linux-audio-dev] 3MU as LADSPA plugin?

by Mario Lang

"Richard Furse" <rf015d9821(a)blueyonder.co.uk> writes: > Sounds like an excellent idea... Only problem is that 3MU has a sequence setting in his config file too, which makes porting to LADSPA a bit strange. LADSPA doesn't have any string-value fascilities, or anything else for sequencer data, right? > Looked for this tk3MU thing and found TromVSpace, now obsolete. You can find tk3MU on the linux-sound page, right next to 3MU. And for those curious how such a .3MU file should actually look like, I managed to work one out, from reading the tk3MU sources: ---------------------------------------<>------------------------------------- #!3MU portamento-time = 50 attack = 2.1 release = 6.9 repetitions = 16 cutoff = 100 decay = 65 filter-amount = 190 filter-poles = 10 resonance = 39 tempo = 40 waveform = "square" cutoff = 13 Note = { c0 c1 d1 c0 c1 d1 e0 d#1 } note-mode = { normal normal normal normal normal normal normal normal } note-length = { legato normal legato legato legato normal legato normal } note-portamento = { 1 0 0 1 0 0 1 0 } ---------------------------------------<>------------------------------------- -- CYa, Mario

22 years, 1 month

[linux-audio-dev] Fwd: RE: [music-dsp] Transformer emulation revisited

by Steve Harris

This is from the music-dsp list, it seems relevant to what people were discussing with SPICE emualtion of tube circuits. - Steve ----- Forwarded message from "Sergio R. Caprile" <yogurthu(a)arnet.com.ar> ----- > Date: Thu, 07 Nov 2002 11:05:32 -0300 (ART) > From: "Sergio R. Caprile" <yogurthu(a)arnet.com.ar> > Subject: RE: [music-dsp] Transformer emulation revisited > To: music-dsp(a)shoko.calarts.edu > X-Mailer: XFMail 1.5.2 on Linux > > > On 06-Nov-2002 music-dsp-digest wrote: > > > I've been too lazy to sit down and calculate the typical Preamp hi-freq > > boosting from schematic component values, need to do that sometime. > > I did some Spice simulations some time ago, as far as I remember it was more a > sort of low-freq roll-off: single pole hi-pass between stages and poor resistor > decoupling. > > > Even if the preamp has hi-freq boost that emphasizes higher-frequency > > distortion, a downstream saturating transformer might "sound good" by > > selectively adding extra harmonics to the low notes? From one view, the > > transformer might be "undoing" the preamp's hi-freq emphasized distortion. > > But the two might work synergystically to make a more complex sound than a > > simple broadband fuzz? > > > > Since there is non-linear processing involved, the transformer is unable to > undo the preamp hi-freq distortion, but it adds a different color. The main > reason to hi-pass before distorting stages was to avoid that cutting rumbling > sound or excessive bass, well, that was before grunge and Metallica and... > > > There was no tone control setting that would completely straighten out the > > lines in the tri wave, even with the amp running clean. There were > > frequency-dependent effects in distorted tones which made the waves even > > more difficult to interpret. > > The Fender tone network (later adopted and modified by Marshall and almost > everyone, including Roland) is designed to color the signal, there is no "clean" > position as in a regular Baxandall network. There is an intentional notch at > 250/500 Hz that can be softened by the mid control and two bumps at 100Hz and > 5KHz. > I am not much into tubes, but most of the preamp stages where intentionally > biased so the tubes could easily be overdriven. Some Marshall have "feature" > capacitors running across different stages, I mean, the schems say: for model A > this capacitor, model B no capacitor, model C, change to this value. Pretty much > of the sound seems to have come out of sorcery ;^), or trial and error btw. > > James: > You said you simulated a simplified tone control > Did you simulate the Fender/Marshall network ? I tried to get the transfer > function but it gets a bit complicated and I always give up before bilinear > transform, and don't want to split the circuit as that might remove all the > interactions along the controls. > > Regards > > > > -- > -------------------------------------------------------------- > Sergio R. Caprile, Electronics Engineer, Bs.As., Argentina > http://www.geocities.com/scaprile > -------------------------------------------------------------- > > dupswapdrop -- the music-dsp mailing list and website: subscription info, > FAQ, source code archive, list archive, book reviews, dsp links > http://shoko.calarts.edu/musicdsp/ ----- End forwarded message -----

22 years, 1 month

[linux-audio-dev] 3MU as LADSPA plugin?

by Mario Lang

Hello.. I just decided to try out 3MU. Well, I'm at a loss there, the 3MU distribution doesnt seem to include a single example, and tk3MU is a gui again. But while looking at all this (and still not able to generate a single sound :-) ) I was wondering if anyone ever thought about turning 3MU into a ladspa plugin? It appears to have many parameters, and AFAIK, they can only be set at startup right now... Exposing that through ladspa controllers would be cute. -- CYa, Mario

22 years, 1 month

[linux-audio-dev] Re: Cheby amp code

by Steve Harris

On Sat, Nov 02, 2002 at 08:12:10 +0100, Tim Goetze wrote: > >In the instantaite block fixes it up more-or-less. Maybe even adds a bit > >of compression (it boosts the gain to make it roughly 1:1 too). > > have you modified the lut in the meantime? i don't seem to be getting > the right results with the log scaling you use. Did you try adding the 0th harmionic to the front of the table, and dropping the last harmonic? That made it sound pretty good for low notes. > ah, i'm afraid that's only half the truth. try the link i posted > to the list; somebody has been doing this before us and published. > i still haven't checked for frequency dependency of valve distortion, > but it seems they have, and found it to exist. Figures, on both counts. > additionally, it seems that to tackle intermodulation distortion it > is best to split the incoming signal to multiple bands (those great > theoreticians have been using FIRs in matlab) and shape each band > separately. they do in fact use two blended shapers per band. OK, why do they use two shapers? Or is it one cheby and one non polynomial? > btw, the 'lower frequency' phenomenon occurs with the real amp, too, > only it's not as pronounced. OK, I didn't know that. > drat. i fear that we'll need to cool this box into superconductance > to get the effect done *really* right. Yeah, I'm thinking we're not tackling it right, if behringer can knock out a virtual amp harware box for E150 it can't the that cycle hungry. - Steve

22 years, 1 month

[linux-audio-dev] GUIless friendly applications

by Mario Lang

Hello. I'm a blind Linux user since 1997, and I'm also interested in doing music on Linux. Since I'm the synth-type-of-guy, I'd really love to be able to play with software based synths, a little bit of step seuqencing, and some sample based stuff. Controlling my SuperNova DrumMachine via MIDI (and being able to sequence it) would also be nice. Well, since blind people are still very GUIdisabled in Linux, the only things I can use are those which are either CLI or curses based, or expose their functionality through a easily programmable API. If only choice number two is available, that isn't that nice, because I'd like to be productive sometimes, and if you have to write yourself every little bit of convenience thing, you are not really making music, you're programming :). THe biggest problem there is that you actually dont do much realtime modifications. And realtime changes to sequences or parameters of things are very important for experimental type of electronic music. SO I've looked around, and found some stuff, but still have nothing really useful. Here is the list of software which is nicely done, and GUIless friendly: Ecasound!!! Kai, cool done! But its not the thing I need unfortunately. GDAM. Looks promosing because the workhorse code is nicely separatedd from the GUI, and I already managed to program gdam123 a bit to allow rate control, but again, its not really what I'm looking for although it seems nice. Ardour is also somewhat accessible from what I hear, but again, its a multitrack recorder, not what I need. SSM: I looked at the code, and it seemed quite horrible to me. GUI and workhorse code are tightly coupled, I see no way for me to get to the underlying functionality. What I'm really missing is: Some Sequencer which is capable of MIDI out and in Some Synth software which is controllable through that sequencer. SSM seems nice, but its a GUI-only thing, PD is even more GUI... Some LADSPA plugins seem promising, but again its too much putting-things-together work. Can anyone add anything to that list? Can anyone help with the listed problems? Is some software author (i.e., the SSM author) interested to work with me on getting GUIless controllability? I'm not a good C programmer, but I'm at least familiar with what we'd need to work efficiently... Or am I missing anything completely? Some trick to circumvent the need for some GUIs? Can anyone give an example on how to create a short trtack with some samples and a synth line without X? -- CYa, Mario | Debian Developer <URL:http://debian.org/> | Get my public key via finger mlang(a)db.debian.org | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44

22 years, 1 month

[linux-audio-dev] Re: Cheby amp code

by Bill Schottstaedt

> i'm not up to understanding all implications of the fact that the > incoming signal is not a pure sine; This intrigued me -- I think the answer is that the process is not linear -- you get sum and difference tones much as in complex fm. I added an example to clm.html. Back when Marc and I were first messing around with waveshaping, I asked him about some way to set up the poynomials to get a particular spectral evolution as the amp increases (input amp being similar to fm index in this context) -- you can use Chebychev polynomials of the 2nd kind to play single-sideband tricks, so it seemed like there might be possibilities; other things intervened, and I don't think Marc ever got around to dealing with it.

22 years, 1 month

[linux-audio-dev] Re: Cheby amp code

by Tim Goetze

found out some interesting facts about the chebyshev. been playing around a little with a chebyshev shaper, feeding it various harmonic amplitudes and a sine oscillation, taking an FT afterward. it seems that in order to get a harmonic of amplitude 0.5, you must not pass 0.5 to chebpc for that harmonic, but sqrt(2)/2. for a harmonic of amplitude .333333333, pass in sqrt(3)/3, etc. thus, if we want amplitude 'a' for a given harmonic, the chebpc coefficient is 'a * sqrt (1/a)' rather than simply 'a'. (negative amplitudes: ?). the peak value of the chebyshev-shaped output will be the sum of all coefficients calculated in this manner. the further the incoming sine is scaled down (from [-1,+1]), the less the harmonic mix will match the wanted amplitudes. for the amp code, this would mean we should probably try the following: compress/expand the incoming signal to fit exactly into [-1, 1] (normalize). the coefficient tables need some treatment, too -- we want the output sum to be 1, and the relative strengths of the harmonics to match. i'm not up to understanding all implications of the fact that the incoming signal is not a pure sine; neither do i have a recipe for preparing the coefficient tables -- if we scale the individual coefficients by 1/sum their mix will not match what we want. tim

22 years, 1 month

Re: [linux-audio-dev] GUIless friendly applications

by Benno Senoner

We at the LinuxSampler project, http://linuxsampler.sourceforge.net will go the GUIless route too and as Juan L. suggested it is probably wise to use a TCP socket because it allows remote controllability which can sometimes be very helpful. Imagine these racks found in webfarms starting making music :-) Anyway as our project advances, I hope that some good soul will implement a CLI interface for the sampler too so that it becomes more accessibile for people with disabilities. I agree with your stance about merging GUI and engine code: it is a mess and often introduces many maintenance and performance problems. Most audio programmer so not seem to realize that using mutexes called from GUI threads that share data with the audio thread speaks SUICIDE because you will never be able to ensure that your sub-5 msec audio engine does not drop out under heavy load. Yes ... (blocking) mutexes simplify a bit the programmer's task , but I'm sorry to say it your product will never be usable in the pro audio field. Hoping for a peaceful, client-server centric audio application world. :-) Benno -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

22 years, 1 month

Re: [linux-audio-dev] anyone interested in porting a GPL'ed VST plugin?

by Benno Senoner

Paul Davis wrote: > it shouldn't be *too* difficult ... Someone suggested LADSPA but I do not see an easy way to do it since LADSPA does not support MIDI and this seems a VST2 instrument. Time to intruduce an instrument API or extend LADSPA ? Of course one can write a standalone JACK client (currently probably the best thing to do), but this means reinventing the wheel all over again. Let see what comes out of LinuxSampler, the discussions and ideas proposed on the list are quite interesting perhaps it would not be a bad idea to add VST instrument support so that opensource plugins like that one could be easily ported without needing and extensive rewrite (at least for the DSP part, the GUI stuff is a separate issue). Does anyone remember if it is possibile to use the VST headers (unmodified) on Linux or is Steinberg against ? I remember that some time ago Paul Davis wrote about these issues on the mailing lists but I do not remember what the outcome was. Thoughts ? Benno -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.

22 years, 1 month

[linux-audio-dev] Re: linux-audio-dev -- confirmation of subscription -- request 999072

by Stuart C. Bruce

On Tue, 05 Nov 2002 15:02:13 -0500 linux-audio-dev-request(a)music.columbia.edu wrote: > linux-audio-dev -- confirmation of subscription -- request 999072 > > We have received a request from 216.254.100.146 for subscription of > your email address, <stuart(a)realhappy.net>, to the > linux-audio-dev(a)music.columbia.edu mailing list. To confirm the > request, please send a message to > linux-audio-dev-request(a)music.columbia.edu, and either: > > - maintain the subject line as is (the reply's additional "Re:" is > ok), > > - or include the following line - and only the following line - in the > message body: > > confirm 999072 > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form.) > > If you do not wish to subscribe to this list, please simply disregard > this message. Send questions to > linux-audio-dev-admin(a)music.columbia.edu. >

22 years, 1 month

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 November 2002