Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] ANNOUNCE: BEAST/BSE v0.6.5

by Tim Janik

BEAST/BSE version 0.6.5 is available for download at: ftp://beast.gtk.org/pub/beast/v0.6/ or http://beast.gtk.org/beast-ftp/v0.6/ This is a development version of BEAST/BSE, the BEdevilled Audio SysTem and the Bedevilled Sound Engine. BEAST is a powerful music composition and modular synthesis application released as free software under the GNU GPL and GNU LGPL, that runs under unix. The project is hosted at: http://beast.gtk.org A mailing list is available at: http://mail.gnome.org/mailman/listinfo/beast/ GUI skins, example sounds and instrumets for BEAST/BSE as well as screenshots can be found at: http://beast.gtk.org/browse-bse-files.html http://beast.gtk.org/screenshots/index.html This development series of BEAST has a lot of the internals redone, many new GUI features and a sound generation back-end separated from all GUI activities. Outstanding new features include support for skins, many sample file formats, MIDI file import abilities, an improved piano roll widget, the track editor which allows for easy selection of synthesisers or samples as track sources, loop support in songs, mixer support, unlimited Undo/Redo capabilities and MIDI automation. Overview of Changes in BEAST/BSE 0.6.5: * New supported file formats: GUS Patches - Load patchfiles as ordinary samples [Stefan Westerfeld] BseWave - A new tool bsewavetool allows creation and compression of multi-sample files which can be loaded by beast. This tool is experimental and not currently being installed, ask questions or report problems with it on beast(a)gnome.org. * New Effects: Saturator - Saturate audio signals, implements various saturation types. * New scripts: Track Busses - Automatically create mixer busses for tracks * Fixed MIDI file import to create required mixer setup * Added playback position indicator to piano roll * Fixate zoom position while zooming piano roll * Fixed saving of BseMixer state to BSE files * Improved sample file caching algorith * Improved BSE file parsing robustness * AMD64 fixes [Stefan Westerfeld] * Lots of miscellaneous bug fixes * Updated British English translation [David Lodge] * Updated Canadian English translation [Adam Weinberger] * Updated Czech translation [Miloslav Trmac] * Updated Dutch translation [Tino Meinen] * Updated Spanish translation [Jorge Gonzalez] * Added Bulgarian translation [Iassen Pramatarov] * Added Kinyarwanda translation [Steve Murphy] --- ciaoTJ

20 years, 2 months

[linux-audio-dev] [ANN] Digital Room Correction 2.5.0

by Denis Sbragion

Hello, DRC 2.5.1 is out and is available at: http://freshmeat.net/projects/drc/ Changes: A new ringing truncation stage has been added to remove excessive ringing caused sometimes by the pre-echo truncation procedure. The sliding lowpass prefiltering procedure has been rewritten to make it a bit more accurate and to make the code more readable. The postfiltering stage has been split to provide a separate stage for microphone compensation. The documentation has been vastly improved, switching to LaTeX for document generation and formatting. Many other minor bugs have been fixed. Best of listening, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it

20 years, 2 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 19, Issue 26

by Michael Ost

On Tue, 2005-04-12 at 09:02, linux-audio-dev-request(a)music.columbia.edu > I really would like to see a coherent approach defined and organized > to study and maintain VST/VSTi compatibility under Linux. Matters to be > considered include : > Keeping current with WINE development (ongoing). We at muse research have some direct experience in this area. Our VST support library is closed, but we do use and contribute to Wine. We find and fix VST related Wine bugs all the time. We are using wine-20040914 but will probably be moving to wine-20050310. Later versions do make a difference in how well plugins are supported. Support and compatibility is OK especially for the smaller, freebie plugins. For the big ones (like Native) compatibility is more problematic. We will be helping with this effort by finding and fixing Wine bugs, and significant differences between Wine and Windows. Some are fixable with Wine and some will require developer cooperation. As an example, sfz (a Soundfont player) makes an Invalidate() call during the (supposedly) realtime process() call. In Windows that's cheap, in Wine it's not. The sfz folks weren't willing to change their plugin. But the folks at BFD (Fxpansion) were. A Receptor and Wine friendly version is forthcoming. > Trying to resolve licensing issues with Steinberg (if they're > willing to alter their licensing, perhaps they just need some more > prodding?). This is a dead end. You can argue it all you want. They have no business interest in changing the terms of VST. It isn't going to happen. It's even difficult to get some of the key, larger plugin vendors to do anything for Linux but we are chipping away at it. - mo =================================== Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com

20 years, 2 months

Re: [linux-audio-dev] Concerning libfst, vstserver, and dssi-vst

by Kjetil Svalastog Matheussen

Paul Davis: >>One thing that distinguishes dssi-vst from vstserver and jack-fst is >>that it manages threading in the Windows parts of the code using the >>Windows threads API rather than pthreads, which means it ought not to >>be sensitive to threading-related changes in Wine. Of course, that's >>only theory. > >the way wine now handles threading makes this point mostly moot. wine >completely overrides the pthread "vfunc" table for any NPTL system and >even (i think) newer linuxthreads ones. you may think your app calls >pthread code, but if its linked using winemaker, its not (at least, >not directly) :) and of course, the new version of fst will require >winemaker compilation as well. Yes, in theory, there should be no difference. But try to compile a shared library that links to libwine and use pthread functions, without linking with libpthread. This worked with wine 9.12.2003, but not anylonger. I had to use some crazy hacks on wine to make vstserver compile for about a year ago or something. And later it got worse (unable to compile). The way wine/winemaker constantly changes is so tiresome that I just don't want to touch it anymore. (Perhaps thing have got better now, though.) --

20 years, 2 months

[linux-audio-dev] LAC2005: Don't forget to floss^H^H^H^H^Hregister!

by Frank Neumann

Hi all, the 3rd International Linux Audio Conference(*) or "LAC2005" for short is nearing (21-24 April), and if you have not registered for it yet, now would be a good time to do so. It's free, we are not selling your email addresses (honestly!), and it gives you a real bonus: After a short negotiation with ZKM, we agreed that registered participants have free admission to the ZKM Media Museum and the currently running exhibition "Making Things Public". The Media Museum is quite interesting, especially since you can see a real computer monster in live and stunning action there: Recently, they have acquired a fully working Zuse Z22 from a local college. This lady is really worth being seen. Well, I digress. We hope to see many of you next week at the ZKM in Karlsruhe! The LAC2005 Organization Team: Götz Dipper (ZKM) Frank Neumann (*) http://lac.zkm.de

20 years, 2 months

[linux-audio-dev] Extreme (midi) omni-mode

by Jens M Andreasen

Hi! Say you had an external single channel midi module, and it wakes up in omni-mode (all channels are equal), you will ofcourse expect it to make a sound, no matter the settings on your sending keyboard. Now, suppose the module is multi-timbral? What is the expected result? 16 different sounds layered?. How? Why? Prior art? -- ( ) c[] // Jens M Andreasen

20 years, 2 months

[linux-audio-dev] Re: [linux-audio-user] Concerning libfst, vstserver, and dssi-vst

by Kjetil Svalastog Matheussen

Dave Phillips: > > Greetings: > > Users are constantly wrestling with issues surrounding the software > mentioned in the subject line, and I would like to find out what > directions are planned for those projects. Here's what I see now: > > 1. The vstserver project is functionally dead. It cannot work with > newer versions of WINE, and it appears that Kjetil does not plan to keep > it updated to accommodate the new versions. Alas, this also means that > his nice vsti, ladspavst, and k_vst~ projects are also unusable. :( > Vstserver does actually works very fine with newer versions of wine, at least the ones I have tried. But for compiling up vstserver, you need the 9.12.2003 version. And worse, the 9.12.2003 version doesn't work with newer versions of Linux, or something like that. (Ie. the workaround is that you first have to install wine 9.12.2003 to be able to compile vstserver, then install a newer versions of wine. The plugins will then use the newest version of wine). I think there exist a patch or something for the 9.12.2003 version of wine to make it compile with newer versions of linux (not sure which part). If anyone has such a patch, it would be nice if someone sent it to me. I'm still on Redhat 8 myself, so I don't know what the problem is exactly. > 3. The dssi-vst bridge is still unknown to me because of issues with > RH9, and I've not had time to test it on FC3. But is there any general > feeling that dssi-vst is a better route to take, at least for the normal > user ? Btw, I like the DSSI API, but it seems slow in catching on with > developers. Is that perception correct ? > I think dssi-vst looks very nice too (although I haven't tried it), and its very similar to the way vstserver works. It should not be much work to make vsti, ladspavst and k_vst~ work with dssi-vst instead of vstserver. But I don't have the time / other more interesting projects. > Please understand that I'm in no way criticising the work done on > these projects so far. In point of fact, I'm extremely happy they exist, > but I'm also in considerable doubt whether they can continue to be > useful without further maintenance. Users are writing to other users to > figure out how to fix small problems (usually with libfst), but these > repairs are not making their way back into the codebase, which seems > rather non-optimal to me. I'm also aware that the greater problems exist > because of WINE's inherent instability (WRT its development, not > necessarily its usability) and that Linux audio developers can't be > responsible for WINE fixes too. Perhaps more crosstalk between the WINE > developers and the LAD folk (similar to the recent discussion re: the > kernel list and LAD) would help smooth the way for a more consistent and > more manageable VST/VSTi bridge for Linux ? > > So, any comments or useful suggestions ? > There are two fundamental different ways to get vst plugins to work in linux with the help of wine. The fst-way and the vstserver/dssi-vst way. Both "ways" are needed. One of them is very fast, but hard to set up (fst). The other one is safer and slower, and a little bit less hard to set up. Problem is, that the releases most probably does now depend on a spesific version of wine, or will depend on a spesific version of wine in the future. It would be nice if the three projects (or at least fst and dssi-vst) was coordinated to use only _one_ version of wine, and that this version of wine is downloaded from one place, for example a sourceforge project place. But for this to happen, some person needs to step up, set up a sourceforge account, do some coding, coordinate the coders, release things, do some work. It might not seem like Thorben, Paul, Chris or myself is the right person right now. Perhaps there is some coder with some free time that wants to do this stuff? --

20 years, 2 months

[linux-audio-dev] qjackctl feature request

by Lee Revell

I've been testing jack.udp lately which involves running qjackctl on each machine over a remote X11 connection. However it's impossible to tell which qjackctl is running on which machine. I'd like to request that the hostname be added to the window title. Lee

20 years, 2 months

[linux-audio-dev] [ANN] jack-udpsync + second soundcard client

by torbenh＠gmx.de

hi... just some code i hacked the last 2 weekends. you know jack.udp ? this is jack.udp without wordclock reqirement. slaves one jackd to another. dig around in jack-dev list for more info. i am very interested in osx ports and PPC -> x86 tests. what is still missing is JackTransport propagation through the net. this is tested with -p 128 i dont know if MTU will get in your somewhen. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

20 years, 2 months

[linux-audio-dev] compiling LADSPA for Mac OS X

by James McDermott

Hi all, has anyone compiled the LADSPA sdk for Mac OS X? I expect lots of people have, and that it's very easy..! In the src directory, I type make and get this: ld: unknown flag: -shared The targets in the makefile are: ../plugins/%.so: plugins/%.c ladspa.h $(CC) $(CFLAGS) -o plugins/$*.o -c plugins/$*.c $(LD) -o ../plugins/$*.so plugins/$*.o -shared ../plugins/%.so: plugins/%.cpp ladspa.h $(CPP) $(CXXFLAGS) -o plugins/$*.o -c plugins/$*.cpp $(CPP) -o ../plugins/$*.so plugins/$*.o -shared So I guess ld is different on OS X, and looking at the ld man page, I guess maybe I need -dylib instead: ../plugins/%.so: plugins/%.c ladspa.h $(CC) $(CFLAGS) -o plugins/$*.o -c plugins/$*.c $(LD) -o ../plugins/$*.so plugins/$*.o -dylib ../plugins/%.so: plugins/%.cpp ladspa.h $(CPP) $(CXXFLAGS) -o plugins/$*.o -c plugins/$*.cpp $(CPP) -o ../plugins/$*.so plugins/$*.o -dylib But now I get this error: ld: plugins/amp.o illegal undefined reference for multi module MH_DYLIB output file to symbol: dyld_stub_binding_helper from section (__DATA,__la_symbol_ptr) relocation entry: 0 and that's where I give up! But I guess there's a solution which is obvious to anyone who knows about dynamic libraries on a Mac?

20 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