Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

Re: [linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?

by eviltwin69＠cableone.net

Hey, I wouldn't mind working on the graphics, I just don't know where to start or who else is working on it. Jan On Tue, 8 Jun 2004 09:18 , Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> sent: >On Tue, Jun 08, 2004 at 11:45:53 +0200, Marek Peteraj wrote: >> VST plugins tend to be rather complex, offering tons of features and >> eyecandish GUIs, while LADSPAs usually offer limited functionality, no >> GUI at all(hosts usually provide simple ones to control the parameters). >> But what's interesting is that each LADSPA plugin usually implements >> exactly one type of DSP technique, for example, an oscillator, or a >> delay. This basically leads to a situation where a certain DSP technique >> is 'isolated' in a separate plugin. > >I think thats down to two factors (and its not a good thing) > >1) LADSPA developers are few in number and short in time. The basics are a > good place to start. > >2) The lack of a UI standard makes complex plugins a bit pointless. > >There are a few counter examples (e.g. my VyNil plugin wraps a lot of >different bits), and infact if you look in many LADSPA plugins you will >see theres really more going on than there appears to be. > >[OT] - my canned plugin writing experience - all generalisations and IMHO > of course > > Time breakdown: 10% writing code, 10% maths and optimising, 80% tweaking > and tuning. > > Mapping the controls 1:1 with DSP parameters makes plugins crap - people > say they want that if you ask them, but they dont mean it ;) > > Fewer controls is better. > > Affordance, appearance and usability has as much affect on the perceived > sound quality as the DSP code (posivly and negativly). Some of this can > be achieved without a custom UI. > >You mentioned JAMin - true that does use LADSPA plugins - but of the total >ammount of code the LADSPA plugins are a tiny fraction. I just reused them >because I hate fixing bugs in two places :) > >[OOT] I used to think that a UI spec for LADSPA (to make it competetive >with VST) was a technological problem. I now thinks its a manpower issue >(I think Paul Davis pointed this out a couple of years ago :). Games >develpment has moved to the point where the graphics work is more >expensive than the software development, and I bet its not far off in >plugin / eyecandy app development. We have no, or almost no, graphics >people here. > >There are plenty of graphics people working on Free Software projects, but >they all seem to be working on games projects. What a waste. I guess >drawing goblins is more fun than sliders and LEDs. Who knew? ;) >

21 years, 4 months

[linux-audio-dev] Re: Graph reordering

by Juhana Sadeharju

>From: Alfons Adriaensen <fons.adriaensen(a)alcatel.be> > >On Fri, Jun 11, 2004 at 08:37:09AM -0400, Paul Davis wrote: > >> you cannot modify the graph in JACK while the graph is being used to >> process audio. you do not know how long the graph modification will >> take if you try to do it (for example) right after you're done with >> one process cycle. the only sure way to do this is to use lock free >> parallel programming techniques. Would anyone please explane details of these techniques? Maybe it is something I know already but it is not clear. >The 'heavy state' is AFAICS not the real problem. >Heavy things can be put in place before the actual graph reordering >is done or removed after. This does not need to be done in the RT >thread. For speeding up this approach one can also use caches for the items. The engine butler can initialize module structures, delay lines, etc. at its spare time. These initialized items are placed to cache. When the engine needs an initialized item, it gets the item instantly from the cache. (No patent pending.) Juhana

21 years, 4 months

[linux-audio-dev] GThread vs. pthread

by Pete Bessman

Does anybody have any opinion on which threading system is superior? I've been using glib for a lot of things, but for whatever reason I'm hesitant about using it for threading if the only benefit it will provide is consistency (I'm guessing it's just a wrapper for pthread anyway). [pb]

21 years, 4 months

[linux-audio-dev] TiMidity as a CPU hog

by Dave Phillips

Greetings: Can someone explain why TiMidity eventually hogs the CPU at 95% or more after running for a while (like 12 hours or more) ? I'm talking about hogging the chip while TiMidity is idling, not playing. I'm using it as a softsynth, it works well, but even in the latest version its CPU usage just soars. Here's how I'm invoking 2.13.0 : timidity -iA -B2,8 -c /home/dlphilp/timidity.cfg -A100 -Oj -EFreverb=0 -EFchorus=0 Takashi: Obviously I spoke too soon in my earlier message. I just looked at top again and saw that TiMidity was eating up 96% of the CPU. :( Best, dp

21 years, 4 months

[linux-audio-dev] jack alsa driver cannot set period size below 512 for capture --> update

by Lee Revell

Hey, I posted this a few weeks ago, here is the original thread: http://eca.cx/lad/2004/06/0046.html After doing some research it seems that the issue is actually with JACK. The SBLive does not allow the hardware capture buffer to be set to any values other than these: static unsigned int capture_period_sizes[31] = { 384, 448, 512, 640, 384*2, 448*2, 512*2, 640*2, 384*4, 448*4, 512*4, 640*4, 384*8, 448*8, 512*8, 640*8, 384*16, 448*16, 512*16, 640*16, 384*32, 448*32, 512*32, 640*32, 384*64, 448*64, 512*64, 640*64, 384*128,448*128,512*128 }; This limits the allowed period sizes you can set with snd_pcm_hw_params_set_period_size; this is what jackd uses to set the period size to whatever is specified in the -p argument. However as far as I can tell, you should be able to use the ALSA xfer_align parameter to set this to, say, 128. Then, you set the playback period size to 128, and whenever you get an interrupt from the playback buffer running low you write the next 128 frames to the output device and read the next 128 from the capture buffer. Since the different sized hardware buffers for capture and playback are a quirk of the SBLive, I think this would require hardware-specific code for the EMU10K1 in JACK, the way there is one for the Hammerfall, HDSP, and ICE1712 already. Would someone with more low level knowledge of JACK and ALSA care to comment? Lee

21 years, 4 months

[linux-audio-dev] FYI (FW: [The end of an era])

by Claudio Mettler

...

21 years, 4 months

[linux-audio-dev] Terminology / sampler architecture

by Thorsten Wilms

Hi all! Besides widgte-level gui standards another topic for general usability is terminology. Naming of concepts like sessions, banks, presets, patches and so on. I expect quite some resistance about renaming stuff in existing apps, but a guideline would still be a good thing for future developments and minimizing confusion. So I would like to hear of personal preferences and known differences in naming on existing apps. Of special interest to me is naming and structure of the different organizational levels of samplers. And a specific questions: what is thought to be the best approach to allow both having multiple samples with greatly varying setups of filters/amps/etc (drumkits) and multiple samples for chromatic instruments with smooth changes of filter/amp/etc settings? Thanks in advance for any input! --- Thorsten Wilms

21 years, 4 months

[linux-audio-dev] Splitsheet

by Thorsten Wilms

Hi! While thinking about structure/organization for LDrum, I developed a concept for the gui of a modular system. http://wrstud.urz.uni-wuppertal.de/~ka0394/forum/04-06-15_splitsheet_01.png All happens in one window, with blocks that represent modules. These modules can be input filters (filtering channels, notes, velocity ranges), oscilators, sound filters, amp and everything else known from modular systems. The type of module for a block is determined by a dropdown menu. Other content are the type specific controls. Each block can be split up horizontaly or verticaly to create new blocks (see mockup for a horizontal split). Splitting could be offered in conetx menu or through dedicated buttons. Signal flow starts at the top and goes through top and bottom edges of blocks (no sideway signal flow). Splitting up and mixing happens automaticaly. Of course moduletypes could not be selected freely, because input filters would have to be chained directly, and could not be placed behind oscilators and the like. The system would make it easy to build rather simple chains of modules quite fast. noterange filters would allow to split things up using multiple samples or varying synthesis setups and join it back together at any stage. Alternatively to the block splitting, modules could be layed out on a canvas/grid. But that would require means to resize modules to form various relations. In short I think it would require more interaction for similar results. So this is a rough idea, free to be picked up. If there's real interest (a chance of implementation), it would be my pleasure to further develop it in cooperation. --- Thorsten Wilms

21 years, 4 months

[linux-audio-dev] [ANN] updates

by Fons Adriaensen

Already some bugfixes to the things I announced less than 24 hours ago... jaaa-0.1.1.tar.bz2 clthreads-0.0.3.tar.bz2 as usual to be found on <http://users.skynet.be/solaris/linuxaudio> Thanks to Jesse Chappell for pointing out the problems. -- FA

21 years, 4 months

[linux-audio-dev] [ANNOUNCE] Editor/Librarian for Rolands Alpha Juno synths

by Chris

Hi, The first release of my patch editor and librarian for Rolands Alpha Juno synths is available at: http://www.chriswareham.demon.co.uk/software/alphajuno/index.html It has been tested with an Alpha Juno 1, but should also support the Alpha Juno 2 and MKS 50 synthesisers. Now the bad news. I wrote the program on NetBSD, and I don't have access to a Linux machine to tweak and test it there. The only things that should need tweaking are in the source file "midi.c". If anyone could compile the program on Linux and let me have a diff of any changes, I would be most grateful. Failing that, I hope to have enough disk space to dual boot Linux as well as NetBSD in the near future, at which time I will port the program myself. As this has been quite an enjoyable and easy program to write, I am now interested in writing a generic editor and librarian for free Unix platforms. I am aware of the excellent JSynthLib, but its reliance on Java means it isn't easily ported across all the free Unix flavours. Writing a similar program in C or C++ would be the goal I'd like to pursue. Anyone interested in helping out (or who can point me at a project that's already undertaken this) please get in touch. Regards, Chris

21 years, 4 months

Jump to page:

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