Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

by rob buse

hey everyone! I just released a new version of seq24. Below are the features added since the 0.5.0 series: * Now uses gtkmm-2.0 or gtkmm-2.2. * New JACK Transport support. * Added Undo feature in editor. * More standard file dialogs w/ filename tracking. * Added .seq24rc file for saving options and changing key mappings. * Remote midi control for live mode finished (bpm change, screen set, mod keys) * Revamped drawing code for sequence editor. It's much faster and can draw much larger sequences. There are also new screen shots up if you just want a look: http://www.filter24.org/seq24/ cheers! rob. --------------------------------------------------- http://filter24.org art + technology

21 years

[linux-audio-dev] Plans/Roadmaps for 2005?

by Florian Schmidt

Hi, i'm writing this email, because i'm interested in what plans the different linux audio developers have for the year 2005 Any new revolutionary applications planned? Major changes to some of the existing apps? So let us know. What are your roadmaps for 2005? What are you guys up to? Where is help needed? Anyways, i start off with my own stuff: amidimon - a terminal midi monitoring app which is very incomplete, but works good for me. I will finally add the autoconnection feature somewhere in the spring of this year. I have seen some alternative midi monitoring apps on the mailing lists in the last year, so maybe i just dump the project completely instead rtc_mtc_gen - a small MTC generator app for alsa_seq. I will teach it drop modes and FPS other than 30 Session - a small gtk2 app to organize collections of programs which make up a "session". I plan to add LASH support sometime this year. I think LASH needs a major revisiting though as imho the adoption of it is rather slow. Maybe it's already too intrusive to applications (i will start another thread on LASH specifically i think)? Session is still alpha (planning stage) and if anyone wants to get involved i will be all ears to suggestions.. The 2.6.x linux audio wiki - i need to definitely update it with newer information. Sadly spammers have discovered my wiki and i had to disable public editing access. This is the first thing i'll do after i have finished some university stuff. Find my stuff here: http://www.affenbande.org/~tapas/wiki/index.php?Ware and here: http://www.affenbande.org/~tapas/linux-2.6.x-ll.html Regards, Florian Schmidt -- Palimm Palimm! http://affenbande.org/~tapas/

21 years

[linux-audio-dev] possibly OT question

by Lee Revell

Apologies if this is OT, but... I have a friend, let's call him Joe, who is something of an expert on Linux audio and specifically ALSA drivers. This person has been working full time on a specific Linux audio project for about 6 months using his own money, which is starting to run low, and has been considering going back to work as a coder or ISP sysadmin (shudder). It occurred to me that maybe there's some user or vendor out there who needs an ALSA driver written or improved and would be willing to pay him to do so. If anyone is interested please mail me privately and I'll put you in touch. Lee

21 years

[linux-audio-dev] Re: Plans/Roadmaps for 2005?

by Juhana Sadeharju

>From: Florian Schmidt > >what plans the different linux audio developers have for the year 2005? Great question! My list: -Freq/pitch spectrum display of highest quality -Pitch detection algorithm -Formant detection alg. -Pitch drawing (in Audacity, over waveform and freq spectrum displays) -Pitch curve editor (a spline curve approximating the pitch) -Cepstrum display to Audacity (a requested feature) -Audio comparison alg. (melody matching at audio signal level only, not MIDI) -Antti's Moog filter (see music-dsp list) -Parameter interpolation to my Theremin app (see gmpi and music-dsp on zipper noise) -Replace the sampled allophones with a formant tonegenerator in my Allo speech synth -Drum synth -Write GUI widgets for graphically manipulating filter parameters (see Waves, Izotope) These all are quite small projects, but we all could work together. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

21 years

[linux-audio-dev] [ANNOUNCE] hexter DSSI plugin 0.5.8

by Sean Bolton

A minor update of hexter, the Yamaha DX7 modeling DSSI plugin, is now available at: http://sourceforge.net/project/showfiles.php? group_id=104230&package_id=134428 Changes include: * Now uses GTK+ 2.x by default. GTK+ 1.2 and a minimal text- based UI are also available. * Added an output gain control, and corrected the MIDI controller 7 volume handling. * Several small bug fixes. More information about hexter and DSSI can be found at: http://dssi.sourceforge.net/hexter.html hexter is written by Sean Bolton, and copyright (c)2005 under the GNU General Public License, version 2 or later.

21 years

[linux-audio-dev] [ANNOUNCE] Xsynth-DSSI 0.9.0

by Sean Bolton

Announcing the latest release of Xsynth-DSSI, version 0.9.0. New features since the last general release include: * Anti-aliased, hard-sync-capable, minBLEP-based oscillators, including a new variable-slope triangle mode. (LADSPA versions of these oscillators are in the works.) * Velocity sensitive envelopes. * An additional filter mode: Fons Adriaensen's MVCLPF-3. * Much improved (but still plain-looking ;-) GUI, now using GTK+ 2.x. * Polyphonic glide, tuning, and pitch bend range controls. * Updated patch set, and better documentation. Xsynth-DSSI 0.9.0 is available at: http://sourceforge.net/project/showfiles.php? group_id=104230&package_id=124101 About Xsynth-DSSI ================= Xsynth-DSSI is a classic-analog (VCOs-VCF-VCA) style software synthesizer which operates as a plugin for the Disposable Soft Synth Interface (DSSI). DSSI is a plugin API for software instruments (soft synths) with user interfaces, permitting them to be hosted in-process by Linux audio applications. More information on DSSI can be found at: http://dssi.sourceforge.net/ Xsynth-DSSI is written by Sean Bolton, and copyright (c)2004 under the GNU General Public License, version 2 or later. Xsynth-DSSI retains the basic synthesis model of Steve Brooke's Xsynth 1.0.2, while adding the following features: - operation as a DSSI plugin, - polyphonic operation, - band-limited oscillators, - a new, more stable filter mode, and - velocity-sensitive envelopes.

21 years

[linux-audio-dev] interesting read

by Lee Revell

So I decided to try reverse engineering a Windows driver yesterday, and came across this om Microsoft's site. It's a preliminary audio driver writer's guide for the Longhorn low latency audio system, they call it WaveRT. Anyway if it works like they claim, it implies the middle layer is quite powerful. It's a fascinating read. The really interesting stuff is in the Word document. http://www.microsoft.com/whdc/device/audio/wavertport.mspx http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a67… Lee

21 years

[linux-audio-dev] announce-list policy

by Kai Vehmanen

Hello everybody, when linux-audio-announce was created, it was agreed that announcements should be crossposted to all three lists. The reasoning was that this way people wouldn't have to subcsribe to LAA if they were already on LAD+LAU. Now when you look at LAA archives, some people post only to LAA, some (like me) to all three lists, and some to either LAA+LAD or LAA+LAU. My suggestion is that we drop this policy altogether: announcements should be sent to LAA and optionally to LAD and/or LAU. At least I've always had the nasty feeling that I'm spamming LAD+LAU with my Ecasound release announcements. Of course, when announcing conferences, major new versions (JACK-1.0.0 maybe? :)), etc, I see no harm in cross-posting to all the three lists. So in other words, if you really want to see _all_ the announcements, you should subcsribe to LAA. Any comments? If no objections, at least I will from now on send non-major release announcements only to LAA. -- http://www.eca.cx Audio software for Linux!

21 years

[linux-audio-dev] Re: [linux-audio-user] KX Audio capabilities for Linux EMU10k1 [was Plans/Roadmaps for 2005?]

by Lee Revell

On Sat, 2005-01-08 at 10:17 +1100, Shayne O'Connor wrote: > Lee Revell wrote: > > >On Fri, 2005-01-07 at 15:40 +0100, Florian Schmidt wrote: > > > > > >>i'm writing this email, because i'm interested in what plans the > >>different linux audio developers have for the year 2005 Any new > >>revolutionary applications planned? Major changes to some of the > >>existing apps? So let us know. What are your roadmaps for 2005? What are > >>you guys up to? > >> > >> > > > >I plan to get my patch adding multichannel support to the emu10k1 ALSA > >driver merged, then work on a real hwdep mixer app (probably by > >extending ld10k1/qlo10k1). As many of you know I'm a big fan of these > >cards, they are extremely cheap and (with good driver support) perfect > >for an entry level DAW, like a portastudio or something. Anyone who has > >used the kX drivers on Windows knows how much potential this device has, > >and unfortunately the Linux support is still a joke compared to the kX > >driver can do. But, that is all about to change, as the two crucial > >features (the DSP patch loader and "kX ASIO", aka the full duplex > >multichannel/low latency PCM device) now exist on Linux. > > > > oh my god, are you serious? i was using the kx drivers when i was on > windows, and i gotta say they were the best thing since sliced bread!!! > it turned my soundblaster live platinum into a BEAST of a music machine > (well, compared to what it was) ... > Heh, I still use them, all the time. I have to admit when it's time to make music I still use Windows. This is actually what got me interested in Linux audio, as soon as I realized how far ahead the kX project was, I quit my day job (was sick of it anyway) to work on this project. Now it's 6 months later, I'm a lot poorer, but it works dammit! > when i switched to linux, one of my biggest dissapointments was the > dismal support for the emu10k1 .... especially lack of multi-channel - > by multi-channel support, do you mean that you are able to use the rear > output channel independently of the front channel (at the moment my > front and rear channels are basically inextricably linked)? Yup. If you have the livedrive you can use all those jacks as independent ports. My Audigy2 ZS has something like 6 channels of analog in and 8 out, enough to record a band. And there's nothing like zero latency hardware DSP... I have to admit I still use Windows with the kX drivers when it's time to make music. It will be a great day when I can do the same with Linux. > that is > exactly what i've been trying to get happening for a while now, which i > need for dj mixing work (so's i can have an independent "preview" > channel for cueing music) .... > > the dsp configuration in kx audio was the killer ... are you saying > there is support NOW for use of this kind of feature in linux ...where > can i get the patch? > I actually got a lot more responses than I was expecting. I have been posting about this to the alsa lists for months, and no one but me and Peter Zubaj seemed to care. I think they didn't take me seriously at first, even when I posted the kX stuff, Linux users are conditioned to think these cards are junk. Windows people know better ;-) I will post the patch somethime this weekend. It would be great to have more people test it before I submit it to alsa-devel. In the meantime while I have been focused on multichannel Peter Zubaj has been working on the DSP part. Check it out: http://ld10k1.sf.net Screenshot of the DSP manager: http://ld10k1.sourceforge.net/screenshots/qlo10k1_20040706.png > this sounds very exciting to me! Thanks, hope it works for you. Lee

21 years

[linux-audio-dev] Modular Synth OSC API

by Dave Robillard

Hi all, As many of you know (hi #lad) I'm working on an OSC controlled modular synth called Om. I'm just finishing up subpatching and polyphony now, so things have hit the stage where the OSC "API" is important, and needs to be thought about and stabilized. What exists right now is just randomly added commands to get functionality working, so I won't even mention it here. Best to start from basics. I think I'll tacke it one issue at a time, and make a final RFC kinda proposal for people to comment on. The reason it's important is that I intend for Om to be useful from scripting languages for algorithmic composition / soundmangling / experimentation / etc - not just one 'official' client. So the API needs to be clean and clear as possible, since real people are going to be dealing with it directly. So. First issue, "command" versus "object" namespace. Right now the API is like so (roughly): /patch/connect patch1 osc1 out lpfilt in /patch/set_control foopatch osc1 freq 440.0 etc. The reason for this is simple: liblo didn't have pattern matching support when I wrote it. I think it would be clearer to have paths for the node/patch names rather than as parameters, ie /patches/patch1/nodes/osc/set_control freq 440.0 Another minor thing would be to possibly distinguish commands from object by the use of a # symbol, as in http://www.opensoundcontrol.org/papers/query_system/ making: /patches/patch1/nodes/osc/#set_control freq 440.0 /patches/patch1/#add_node foo bar baz I don't think anyone would really disagree this is cleaner than the command-based version but I have one concern: performance. I don't know if the pattern matching in liblo would have a significant enough overhead to introduce any latency. These commands are used to control everything in realtime, so latency absolutely must be as low as possible. (Steve?) Comments? (There will be more issues to come, assuming anyone cares) -DR-

21 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