Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7501 discussions

[linux-audio-dev] Errors trying to build dssi-vst 0.4 ... any help?

by Mr Machine

hi, i've been waiting for some help on building dssi-vst 0.4 (recently released), but thought i'd ask around some more ... On Wed, 2006-03-01 at 13:17 +0000, Chris Cannam wrote: > dssi-vst: a DSSI plugin wrapper for Win32 VST plugins > ===================================================== > > dssi-vst 0.4 is now available. > > The main change since the 0.3.1 release is that dssi-vst now builds with newer > versions of the Wine tools. Wine 0.9.5 or newer is now required. > > This release also builds with version 2.4 of the VST SDK, although it should > still work with the older 2.3 as well. > > Download it from: > http://sourceforge.net/project/showfiles.php?group_id=104230&package_id=127… > > You will also need the VST SDK, from: > http://www.steinberg.de/Steinberg/Developers8b99.html > > More information about DSSI: > http://dssi.sourceforge.net/ > oh, i've been waiting for this ... thanks for updating to be compatible with latest Wine!!! unfortunately, i get errors when trying to build: [mrmachine@machine dssi-vst-0.4]# make g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall remotepluginclient.cpp -c g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall remotepluginserver.cpp -c g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall -c -o rdwrops.o rdwrops.cpp g++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall -c -o paths.o paths.cpp ar r libremoteplugin.a remotepluginclient.o remotepluginserver.o rdwrops.o paths.o ar: creating libremoteplugin.a wineg++ -I./vstsdk2.4/pluginterfaces/vst2.x -Wall dssi-vst-server.cpp -o dssi-vst-server -L. -lremoteplugin dssi-vst-server.cpp: In member function ‘virtual void RemoteVSTServer::hideGUI()’: dssi-vst-server.cpp:566: warning: unused variable ‘fd’ dssi-vst-server-5Pa9Gf.o(.text+0x147e): In function `RemoteVSTServer::process(float**, float**)': dssi-vst-server.cpp: undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status winegcc: g++ failed. make: *** [dssi-vst-server.exe.so] Error 2 i'm using a CCRMA-enabled Fedora Core 4. shayne

19 years, 3 months

[linux-audio-dev] Karlsruhe

by Lee Revell

So it looks like I may be at LAC2006. I was thinking of bringing my SO and spending a few days sightseeing after the conference, since we've never been to Germany. Any recommendations for interesting stuff to do in the area? We are into nature hikes, history, good restaurants - pretty boring actually ;-) Lee

19 years, 3 months

[linux-audio-dev] Re: stuff I've done

by Maluvia

Wow - that's quite a backlog of work. The software looks fascinating - and the bush-o-matic is priceless! Loved the personal stuff - you have a beautiful family. Thanks for sharing, Brad. :) - Maluvia >Hey everyone -- > >Sorry about the multiple postings, but I figured what the heck... > >I've just put on-line a whole lot of work I've done; papers, pieces, >software, etc. Here's the link for the 2-3 people (beyond my immediate >family) who might be interested: >There's a fair amount of unix/linux work scattered throughout, including >the big "My Music Book" thing I did a few years ago. > >Hope you enjoy this!

19 years, 3 months

Re: [linux-audio-dev] Juce now has ALSA support!

by Pedro Lopez-Cabanillas

On Wednesday 01 March 2006 12:51, Julian Storer wrote: > James Courtier-Dutton wrote: > > "default" means just that. use the name "default" instead of > > plughw:.... or hw:0,0 [...] > > Ok, at the risk of "spreading the myth" that the ALSA documentation is > bad... is this stuff actually explained anywhere?? It took me a day of > googling just to find out what the two numbers after "hw" meant! I never > saw anything mention "default" or "plug:front", etc. http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_dev_names Regards, Pedro

19 years, 3 months

[linux-audio-dev] [admin] reminder: no html postings on linux-audio-*

by Joern Nettingsmeier

hi everyone! just a quick heads-up: html postings or other "enriched" atrocities are banned on linux-audio-*. unfortunately, the mailman response "message has a suspicious header" is less than helpful. if you see your postings bounce with this error, in 99 of 100 cases you are trying to send either html or binary attachments. this warning applies especially to our friends at gmail.com / googlemail.com. their web interface seems to send out dodgy mails by default. best, jörn -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 if you are a free (as in "free speech") software developer and you happen to be travelling near my home, drop me a line and come round for a free (as in "free beer") beer. :-D

19 years, 3 months

[linux-audio-dev] zthreads realtime

by Carlo Capocasa

Hi there! Does anyone have any experience with zthreads for linux realtime audio software? Carlo

19 years, 3 months

Re: [linux-audio-dev] Juce now has ALSA support!

by Sampo Savolainen

Quoting Julian Storer <jules(a)rawmaterialsoftware.com>: > Hi folks > > A while ago there was some talk on the newsgroup about my Juce library, > and people were asking if/when I'd add support for audio under Linux.. > well it's taken me a while to get round to it, but I finally battled > through the hostile, undocumented jungle of ALSA, and the latest Juce > release does finally make a noise under Linux! This is truly great news. I really appreciate the effort you have put into the port, and to supporting Linux. Alas, ALSA. It's very unfortunate that you chose ALSA as the API for Linux. For me, applications without jack support are of zero interest. I live in a world where i can just connect every soft synth and drum machine and midi sequencer via jack to ardour, sync them via jack transport, do mastering inside this environment with Jamin. I'm capable of exporting & mastering faster-than-realtime, because all the software inside the "jack loop" will all run in perfect sync, in-time & on-time with jack instead of the soundcard. These are the benefits from jack. This is why I will give almost no consideration for an application which isn't jackd compatible. The worst thing that can happen is that you get disencouraged. I really do hope you won't get. Like Paul said, the jackd api is super-simple, you should have no trouble at all making a driver for JUCE which uses jackd. Please, pretty please, with sugar, whip cream and a coctail cherry on top. Don't give up! :) (And i guess you've already worked through the GUI & input issues of porting JUCE to Linux, so one more driver should be a breeze) Sampo

19 years, 3 months

[linux-audio-dev] [ANN] sverb 0.90

by Cedric Roux

Dear Linux audio people, sverb 0.90 is out at: http://sed.free.fr/sverb sverb is an order 15 cfdn reverb. Changes: More presets were added. If someone wants to contribute a ladspa support, it's welcome. We could have one effect for each preset (with names like "short reverb 1", "huge reverb"). Then, for each preset, we can control the reverb with two parameters (t60(0) and t60(pi)), which would make a nice and tiny GUI. (Maybe also add a dry/wet control.) We also need to handle stereo, with a basic decorrelation for example (different delays for left and right channel). Since sverb has three internal operating modes (float, int, asm), I think three .so would be nice. For the asm and int libraries, we could add a third control for the bit resolution (or leave it to a default, currently 14, but which could be set at compile time why not). Before going to 1.0, I need some feedback about the quality of the various reverbs (I know that big 2 is not that good). Also, if someone knows how to define good parameters (by hand or algorithmically) for the delay lines, help is very welcome. Take care of yourself, Cedric.

19 years, 3 months

[linux-audio-dev] [ANN] arcangel (and result of widget discussion)

by james＠dis-dot-dat.net

Howdy peeps, arcangel is a very simple distortion jack-enabled effect. It sounds warm and crunches nicely when you turn it up. If there was a competition for the simplest non-demo jack app, this would probably win. http://www.dis-dot-dat.net/index.cgi?item=/code/arcangel/ There's a demo mp3, too. If someone feels like playing a guitar through it for a new demo, let me know. My playing isn't up to scratch. And I'd love to hear a bass guitar through it... Thanks to all the people on the LAD list that made suggestions on widget sets. It was much appreciated. In the end, I went with xforms because it was so simple and small, although I might play with GTK at some point. James -- "I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you." (By Vance Petree, Virginia Power)

19 years, 3 months

[linux-audio-dev] Fwd: OT -- USB History

by Christoph Eckert

Hi all, sorry for cross posting, but I found the following info very interesting when discussing about USB 1.1 vs. USB 2.0 stuff. Some of us (including me) would like to see a USB 2.0 breakout box which grants more than 2x2 channels while using a standard USB 2.0 protocol. Bruce Wahler politely agreed to spread his info to our lists, so all credits go to Bruce. ce ---------- ---------- Subject: OT -- USB History Date: Donnerstag, 16. Februar 2006 18:12 From: Bruce Wahler <desp(a)mm.ed> To: access-list(a)ampfea.org Hi All, [Warning: This post has little to do with the Virus TI per se. It might be of interest to some of you, though.] I was involved in the early USB efforts, working for a major PC manufacturer. The 3-tier speed approach of USB is a confusing -- and necessary -- part of the design. Early USB appealed to two groups: 1) manufacturers who wanted to simple, cheap way to untangle the rat's nest of wires that were growing behind computers; and 2) developers who wanted a better, more flexible connection than serial and parallel ports provided. In addition, the creators of USB had this grand vision of "USB everything": kitchen appliances, phones, televisions, you name it. USB attempts to satisfy all of these needs, but the goals of different markets are sometimes at odds with each other. Devices like mice can't afford to add even $1.00-2.00USD of product cost, because their customer base won't accept the price increase. On the other end, there's no such a thing as "too fast" for disk drives and networks. USB 1.0 (and 1.1) came out with Low- and Full-Speed specifications to try to bridge the needs of these two camps. Same connectors, same (or similar) cables, same hardware at the host (computer) end; all of the higher-speed functions had to be a layer on top of the basic ones. At the time of USB 1.0 (1995), the practical limit for cables and such was considered to be somewhere in the range of 10-15Mbit/sec. This wasn't a PHYSICAL limitation; it was governed by the cost of hardware (cables, connectors, ICs, etc.) compared to the amount of data being sent (<1GB). Unfortunately, USB 1.x took several years to gain acceptance. (PCs had the USB ports back in 1995, but there were no real peripherals nor OS support for 3-4 more years. One of my bosses used to refer to it as the "Useless Serial Bus.") By the USB really took hold (2000? 2004?), there were enough advances in technology and manufacturing to up the speed a great deal. Add to that the need to transfer more data, and the fear that FireWire would eclipse USB, and "Hi-Speed USB" was born. Hi-Speed USB follows the same rules as USB 1.0: faster protocols must work around the limits of slower ones, so nothing becomes truly obsolete. This is why a 12Mbit/sec Virus TI is still "USB 2 compliant." Some important things to know about Hi-Speed USB: 1. The GUARANTEED cable length is shorter (5m vs. 2m). With a quality cable, you might run further, but there's no whining if it doesn't work. This certainly limits the ability to use the Virus TI as both a recording platform and a performance synth at the same time. 2. Raw bandwidth numbers of Hi-Speed USB are deceptive. (This is also true of FireWire.) While the cable and ICs can support 480Mbit/sec., it takes great drivers, proper interrupt selection, and a relatively unused computer to use that bandwidth. Otherwise, it's a game of "hurry-up-and-wait." Sharing USB with slower devices also clouds the picture. 3. USB 2.0 enhancements focused on data storage. There weren't any high-speed audio extensions added. If Access had wanted to use 480Mbit USB audio, they would have had to develop and support it from scratch -- on both the Mac and PC. So, it's not just a case of adding a little product cost; it's a large development and testing challenge, too. Why weren't there audio extensions? Probably because the two "official" audio uses for USB -- Internet phones and digital USB audio -- didn't need them. The first one is fine with 12Mbit/sec, and the second one never really caught on. 4. The USB specifications were mostly written by big companies like Microsoft, IBM, Intel, and Compaq. They sunk a lot of resources into USB, and so their needs took top priority. None of those companies is known for professional audio gear -- they're computer companies, and USB audio was and still is a bit of an afterthought. (Quick: Name me one 'major' US PC manufacturer who sells a true MPC in their standard line? Anyone?) So, why not add the hardware (ICs) now, and write the OS support later? The approach rarely works, IMHO. Even in the computer industry, known for technology advances, hardware that is unused at product launch often remains forever unused. Why? Remember the old adage, "If it ain't broke, don't fix it" ? Well, updating software or firmware requires breaking that rule. And anyone who's written software will tell you that bugs crop up in the strangest places. While the updates are cool, there's often very little evidence that the efforts resulted in big sales increases. Thus, a small company like Access must be choosy when planning product updates. Regards, -BW -- Bruce Wahler Design Consultant Ashby Solutions http://consult.ashbysolutions.com 978.386.7389 voice/fax bruce(a)ashbysolutions.com _______________________________________________ access-list mailing list access-list(a)ampfea.org http://www.ampfea.org/mailman/listinfo/access-list <--- SUBSCRIBE/UNSUBSCRIBE DETAILS HERE Patches: http://www.ampfea.org/cool/stuff/access-list -------------------------------------------------------

19 years, 3 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