Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

Re: [linux-audio-dev] Modular synths of the world, unite and take over :-)

by ico＠fuse.net

How about having all apps implement Open Sound Control (some of them already have, such as pd, csound etc.)? Then you could control them all from one source (i.e. RTMix). Then, suddenly there would be no redundancy ;-)... Ico > > From: Lukas Degener <AFBLukas(a)gmx.de> > Date: 2003/03/18 Tue AM 08:54:55 EST > To: linux-audio-dev(a)music.columbia.edu > Subject: [linux-audio-dev] Modular synths of the world, unite and take over :-) > > Roman Kaljakin wrote: > > >I am pleased to announce Octavian - a realtime software synthesizer for GNU\Linux > >operating system. > > Octavians's design is like analog modular synthesizers,(...) > > > Well, here we have another modular synth framework. :-) > > Hi Roman, i realy like parts of your ui design. just looked at the > screenshots so far, but i think i will try octavian soon. > I would have reacted earlier to your announce, but i was somewhat busy > and didn't follow lad traffic very regulary. > > Sseems we have a little problem. > Ok, maybe problem is not exactly the right term, let's put it this way: > Right now, there is beast, there is gAlan, there is ams, and of course > there is also pd, jmax, etc. and lately Octavian, and, rats, there maybe > a zillion of other apps out there that i do not yet know of (authors of > such apps, please append your project to my list:-) ) > > While each of this projects may have unique approaches to certain > problems, or use different metaphors for similar things, i guess it is a > valid assumption, that they all have _very_ similar goals in terms of > functionality. At least that was my impression after talking with Stefan > (beast) and Torben (gAlan). > > The Big Question(tm): > How can we avoid redundant work? > > My (somewhat utopious) suggestion: > maybe we should think in components that use/modify a common > datastructure/model. > > This has almost (but not completly) nothing to do with merging ;-) > It means that we have to agree on what exactly that common model would > be, and after that, we would go on writing > different components that actualy work with this model. The problem of > course would be to define that model. > > But once we have managed this, it should be possible to have different > components cooperate on the same instance of that model at the same > time, without knowing about each other, i.e. all "inter-component" > communication would be established via the model. I tend to think of > this as a "Macro Model/View/Controller" pattern. (i have forgotten the > actual term, something like "Document Oriented Design" i think.) > > So this goes out to Matthias, Torben, Stefan, Roman, and of course > everyone else interested in such a thing: > What do you think? > > Regards, > Lukas > > > > > >

22 years, 2 months

[linux-audio-dev] RE:linux-audio-dev digest, Vol 1 #402 - 13 msgs

by RichardC＠europlex.ie

Hello linux-audio-dev-request(a)music.columbia.edu I have received your e-mail regarding 'linux-audio-dev digest, Vol 1 #402 - 13 msgs' I will be out of the office until the 24th of March. Please refer any queries that require immediate attention to Phil Carroll @ philc(a)europlex.ie Regards Richard Caldwell

22 years, 2 months

Re: [linux-audio-dev] Echo Darla/Gina/Layla/... on Linux

by Ranjit Singh

> with all due respect, you are talking about somewhere between 1-5000 > lines of code that would take someone experienced about 3 days to get > to 60% functionality. once it reaches that point, ALSA will happily > take it on, and you get CVS and the ALSA mailing lists to use. Fair enough, I don't know enough about linux module coding. If we can get a 60% functional version in less than a week, I'd be dead chuffed! ;) We're effectively talking about a driver for the Motorola DSP onboard (I can't remember what the no is.) We first need to get it to C code- isn't that what the CPP used to do? Sorry, it's been a while. 8-)

22 years, 2 months

[linux-audio-dev] link: Sound on Sound: Cutting Edge : The Future of Music Technology

by Kai Vehmanen

Nothing new really, but it's on SoS so I guess it's worth a read ;) http://www.sospubs.co.uk/sos/apr03/articles/cuttingedge0403.asp -- http://www.eca.cx Audio software for Linux!

22 years, 2 months

RE: [linux-audio-dev] Interface with real modules

by Joachim Backhaus

Hi there, Waldorf from Germany has made an analog VCF which could be connected via USB to a computer system: http://www.waldorf-music.com/afb/ Regards, Joachim Backhaus > -----Original Message----- > From: Thomas Webb [mailto:magusofthedark@yahoo.com] > Sent: Mittwoch, 19. März 2003 14:52 > To: linux-audio-dev(a)music.columbia.edu > Subject: Re: [linux-audio-dev] Interface with real modules > > > > However you can still have a lot of fun e.g. having > > FM or Ringmod between > > software and true analogue VCOs. It would also be a > > very good idea to > > combine a true analogue VCF with a digital synth as > > it's the filter that > > is the weakest point of digital synthesis. It is > > then however difficult to > > implement proper VCF tracking. This could only be > > done by using a true > > analogue MIDI to CV converter, let this control the > > VCF tracking and send > > the same notes to the softsynth and the true > > analogue MCV connected to the > > VCF. > yeah, the main thing I was thinking of was using an > analogue filter.. The medical company I work for has > this real hightech voltmeter (high res and > everything). I can probably get that to work > perfectly with any modules. The only problem is it's > freaky expensive. Too bad a standard soundcard won't > work quite right. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com >

22 years, 2 months

[linux-audio-dev] RE:linux-audio-dev digest, Vol 1 #405 - 13 msgs

by RichardC＠europlex.ie

Hello linux-audio-dev-request(a)music.columbia.edu I have received your e-mail regarding 'linux-audio-dev digest, Vol 1 #405 - 13 msgs' I will be out of the office until the 24th of March. Please refer any queries that require immediate attention to Phil Carroll @ philc(a)europlex.ie Regards Richard Caldwell

22 years, 2 months

[linux-audio-dev] RE:linux-audio-dev digest, Vol 1 #403 - 17 msgs

by RichardC＠europlex.ie

Hello linux-audio-dev-request(a)music.columbia.edu I have received your e-mail regarding 'linux-audio-dev digest, Vol 1 #403 - 17 msgs' I will be out of the office until the 24th of March. Please refer any queries that require immediate attention to Phil Carroll @ philc(a)europlex.ie Regards Richard Caldwell

22 years, 2 months

[linux-audio-dev] ecasound 2.2.2 released

by Kai Vehmanen

1. A short summary of changes A new native Python implementation of the ECI API has been added to the package. Ecasound.el (ecasound-emacs) has been updated to version 0.8.2. Oggs and mp3s can be now streamed directly from network. Author information is now visible in the LADSPA plugin descriptions. Changes in ALSA-0.9 support improve usability of ecasound with the new ALSA dmix PCM plugin. There have been many important bugfixes including correct handling of short parameter fades, broken chainsetup level looping, problems with creating temporary files and minor build system issues. --- 2. What is ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release Full list of changes is available at <http://www.wakkanet.fi/~kaiv/ecasound/history.html>. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches Janne Halttunen (the new Python ECI implementation) Mario Lang (ecasound.el 0.8.2) Junichi Uekawa (pyecasound.so build) Kai Vehmanen (various) Bug Hunting (items closed) William Goldsmith (2) Michael Hellwig (1) Janno Liivak (1) Raoul Megelas (1) Feature requests (items implemented) Oliver Thuns (1) --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.2.2.tar.gz Distributions with maintained ecasound support: Agnula - http://www.agnula.org Debian - http://packages.debian.org/unstable/sound/ecasound2.2.html DeMuDi - http://www.demudi.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org PLD Linux - http://www.pld.org.pl PlanetCCRMA - http://www-ccrma.stanford.edu/planetccrma/software SuSE Linux - http://www.suse.de/en Contrib Packages for Distributions: Mandrake - http://rpm.nyvalls.se/sound9.0.html Note! Distributors do not necessarily provide packages for the very latest ecasound version. -- http://www.eca.cx Audio software for Linux!

22 years, 2 months

Re: [linux-audio-dev] Echo Darla/Gina/Layla/... on Linux

by Ranjit Singh

> I am a broadcast engineer by profession, but a hacker by hobby. I maintain > the PostgreSQL RPMset, the nspostgres AOLserver database driver, and do a > little bit of coding. I wouldn't consider myself fluent in C++, however. > But I enjoy learning new things.... Well, that sounds perfect to me; David and Brad have experience of Linux coding, and you have the test and packaging experience. I really want to get into Linux coding, and am quite happy to do the admin and docs as req'd. I think we could both learn some new things :) As you said, David, asm isn't really used, as the goal is portability. It might come in handy once we've got a driver working and we want to improve its latency on a specific platform. (I'm thinking Intel and ARM from my side.) Wrt pages of code per model, I agree with you that hopefully we can get round that, perhaps by having a glue layer to different cards. I don't know, it's been ages since I looked at the code. Have you seen the Echo code, Brad? I'd suggest we make sure we all have a copy, even if we can't post it to a central site, so that we are starting from the same point. We need to classify all the operations that we must provide (the API) and the operations we can build on from the cards. I'd imagine there's a core set.. What do you think? > Odd things like the top jack of a two-jack stack becoming inoperative after > plugging in the bottom plug (in balanced mode). Sounds like you've got a short in there somewhere. Regards, Ranjit.

22 years, 2 months

[linux-audio-dev] RE:linux-audio-dev digest, Vol 1 #401 - 11 msgs

by RichardC＠europlex.ie

Hello linux-audio-dev-request(a)music.columbia.edu I have received your e-mail regarding 'linux-audio-dev digest, Vol 1 #401 - 11 msgs' I will be out of the office until the 24th of March. Please refer any queries that require immediate attention to Phil Carroll @ philc(a)europlex.ie Regards Richard Caldwell

22 years, 2 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