Linux-audio-dev February 2006

linux-audio-dev@lists.linuxaudio.org

74 participants
63 discussions

[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)

18 years, 1 month

[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 -------------------------------------------------------

18 years, 1 month

RE: [linux-audio-dev] More about consolidation of the Linux audio online resources (was: linuxdj...)

by ico

>===== Original Message From Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> ===== >What type of hosting service does linuxaudio.org have now in terms of >space, bandwidth, accesibility of physical site admins and access for >remote site maintainers? Currently, the server hosting Linuxaudio.org has been arranged by Daniel James, so my guess is that it is hosted somewhere in UK, other info is unknown to me (ironically the site is currently inaccessible for whatever reason). Daniel? That being said, in my department (Virginia Tech) I've got an ok to offer hosting for LA purposes which would mean direct physical access to the mainframe, virtually unlimited data storage (I am not sure how much we have right now but we should have probably close to 1TB and there is plenty of empty slots left on the mainframe for more disks to be added), and most importantly unlimited bandwidth (although the actual outgoing line is limited to 100MBit from the node where the mainframe is, but the actual monthly bandwidth is unlimited). Finally, all data is backed-up weekly with one backup always being off-site in the case server melts down, dissapears, decides to grow legs and walk away, or whatever. Hope this helps! Best wishes, Ico

18 years, 1 month

[linux-audio-dev] Portable C++ MIDI libraries review

by Carlo Capocasa

Hi, I've had the pleasure and misfortune to test both of the widely known portable MIDI libraries, and now believe I have found one that works to my satisfaction. This is not a quantifiable review with benchmarking but the subjective experience of someone who has implemented a very simple yet nonetheless professionally implemented, low-latency, jitter-free and real time application. (note: to my knowledge, sched_fifo functionality has not been implemented with either library and is next on the priority list to implement in the application). The two candidates are portmidi (http://www.cs.cmu.edu/~music/portmusic/) and RtMidi (http://www.music.mcgill.ca/~gary/rtmidi/) RtMidi is part of the Synthesis Toolkit (STK) but can be obtained stand-alone. For comparison, I have chosen the following criteria: * Availability * Learning curve * Stability * Features * Real-Time performance First thing I did was download PortMidi, mainly because I didn't know what static linking was at the time and RtMidi (I had found both easily through Google) I decided I would go for the library with the smaller size. (As I later discovered RtMidi is available as a seperate library, but was not packaged for my OS, Debian Etch) Even while on the site I got a bit suspicious about PortMidi, as there were quite many 'projects that use portmidi' listed on their site, and a lot of titles and fancy names, but very little actual software. I've got a little bit of entrepreneurial experience under my belt, just enough to tell it is a bad idea to proudly display 'Future Projects' as references. Nonetheless, I decided to give portmidi a chance, in the hope things would get better. They didn't. The 'Documentation' was sparse, cryptically written, and still in the header file (IE no HTML had been generated). I found this to be quite a careless attitude but I had decided to try it out and I did. The API isn't much better. To open an interface, a six parameter function was necessary, of which two were actually relevant (device ID and stream pointer). In order to send a message it was necessary to create a 'buffer' object, write timestamp and message data to it, and pass it on to a 'write' function. Also, it was riddled with pointers-to-pointers and various combinations of references and de-references and I had to revert to plain trial and error to get it to work. It finally did, though. After a similar odyssee with the input library, which, unlike my experience with portmidi I attribute to the fact I had never programmed C++ before, the application finally stood. Pressing buttons on the keyboard generated MIDI events. How grand! However, there was a downside; somehow, pressing and holding keys generated randomly-spaced additional sounds. "How funny," I thought, "my physical keyboard must be not appropriate for such fine use." After battling with C++ polymorphism for DAYS ON END to get the plugin architecture to work I decided it was time to implement threading. Looking for a good thread class I realized that is not such a trivial thing currently. Realizing that RtMidi already had one, and that it was implemented in an audio environment, I decided to switch MIDI libraries too as the Thread class was probably optimized for RtMidi. What a world of difference! I was greeted with a very friendly page titled 'RtMidi', the author had a picture of himself on the page (it's VERY reassuring to know he is not hiding from the police) and looked like he's been meditating a lot, and had it not been for the advanced C++ functionality used in the class that I hadn't learned yet ('advanced' is relative, I mean the vector class and the concept of 'templates') I would have been done implementing in an hour or two. Seriously, RtMidi is one of the most beautifully crafted interfaces I have seen to date, with examples in the beautifully done tutorial. Unlike portmidi it was possible to create ALSA MIDI virtual devices, and the code for sending MIDI events was ONE LINE. Using references it was possible to write a callback function for application plugins that DIRECTLY affect the raw data sent. Clearly, I had a winner. When I tested it I realized what had seemed like a broken keyboard was simply how portmidi responded to repeated, fast events; I had not turned off KeyRepeat events in the event handler, and what was left of them with PortMidi were randomly spaced events between 200 and 500ms apart, somehow mangled in the obscurity of the code I can only presume. With RtMidi it was possible to recognize the events for what they were, crystal clear, fast and evenly spaced KeyRepeats clogging my synthesizer with utmost precision. I have yet to fix the KeyRepeat problem, but it tought me a lot about performance. Perhaps the 'KeyRepeat' test could evolve to a rather good rule-of-thumb benchmark for MIDI performance. And I haven't even implemented SCHED_FIFO yet. As a conclusion, I can draw the following ratings matrix for the two, I can assume the care with which documentation is crafted is a good indicator for code quality, and I can only recommend: Keep your hands of portmidi. Write a wrapper if you need to use C, but for heaven's sake if you don't want all your musical timing ruined, just don't use portmidi, period. MATRIX 1: Useless 5: Excellent portmidi RtMidi Availability 4 4 Learning curve 1 4 Stability 3 4 Features 3 4 Real-Time performance 1 5 Carlo -X-X-X- Did you think this review was helpful for you? Please give a simple 1 to 5 rating, or a quick comment. Thank you.

18 years, 1 month

[linux-audio-dev] Which widgets?

by james＠dis-dot-dat.net

Hello all. I've always steered clear of writing GUIs, so my experience is pretty limited. But now I find myself needing a toolkit/widget set. What's recommended? I'd prefer not to have to move my app from C to C++ just to implement the interface, so that's quite a few out of the window. I don't really want huge dependencies for a knob, text box and a button, either. And something that's installed as default in most distros would be good, too. So, what I want is everything. And it should be simple, too. Any suggestions? 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)

18 years, 1 month

Re: [linux-audio-dev] Portable C++ MIDI libraries review

by Kjetil S. Matheussen

>Hi, > >I've had the pleasure and misfortune to test both of the widely known >portable MIDI libraries, and now believe I have found one that works to >my satisfaction. > >This is not a quantifiable review with benchmarking but the subjective >experience of someone who has implemented a very simple yet nonetheless >professionally implemented, low-latency, jitter-free and real time >application. > >The two candidates are > >portmidi (http://www.cs.cmu.edu/~music/portmusic/) > >and > >RtMidi (http://www.music.mcgill.ca/~gary/rtmidi/) Well, I guess the midishare guys should promote more... http://midishare.sourceforge.net/

18 years, 1 month

[linux-audio-dev] (no subject)

by Kjetil S. Matheussen

Lee Revell: > > On Tue, 2006-02-21 at 14:08 +0100, David Kastrup wrote: >> Who is talking about not paying? > > This whole discussion was ignited when someone advocated pirating (or > stealing, or whatever) commercial software. > Why don't you want to distinct between copyright violation (which is a gray area, different from country to country) and stealing?

18 years, 1 month

[linux-audio-dev] ICMC 2006: Extended Deadlines

by park

Please pardon cross postings and feel free to distribute this announcement. ICMC 2006: Extended Deadlines Y'all are invited to submit your best, finest, or even craziest works to the 2006 ICMC conference to be held in New Orleans, Louisiana, USA from November 6 - 11, 2006. To facilitate the submission of your works we have extended the deadlines: Music/Video/Installations: March 18 (Sat), 2006 Papers: March 11 (Sat), 2006 This conference is not only a historic collaboration between ICMA and SEAMUS (Society of Electro Acoustic Music in the US) but is also a conference that will help with the recovery of a city, its people, and its culture. We have also further updated performance resources which includes the Ensemble Surplus from Germany, NextEns from Cincinnati, Cat 5 from Mississipi, the infamous Convolution Brothers, dancers from the Tulane Theater and Dance Department, our own Tulane Music Department Musicians, Korean traditional instrumentalists from Seoul, and much more. During the conference we'll be giving away gifts and prizes (as well as lots of beads!) made possible by generous donations by our corporate sponsors such as Bias(numerous copies of Peak Pro XT), Parallax (10 BS2 boards with on board bread-boards), Mixmeister (more than $1000 worth of products), Maxim-IC (no not the magazine!), Electrotrap ($800 worth of sensors for your HCI needs), empreintes DIGITALes (special "ICMC" CD for all registered participants), Soundhack (5 copies of spectral shapers), fxpansion (one of each software type) and many more goodies. Please visit www.icmc2006.org regarding updates and details. Laissez les bon temps roulez! Sincerely, Tae Hong Park, ICMC 2006 Conference Chair

18 years, 1 month

[linux-audio-dev] ICMC 2006: Extended Deadlines

by park

Please pardon cross postings and feel free to distribute this announcement. ICMC 2006: Extended Deadlines Y'all are invited to submit your best, finest, or even craziest works to the 2006 International Computer Music Conference to be held in New Orleans, Louisiana, USA from November 6 - 11, 2006. To facilitate the submission of your works we have extended the deadlines: Music/Video/Installations: March 18 (Sat), 2006 Papers: March 11 (Sat), 2006 This conference is not only a historic collaboration between ICMA and SEAMUS (Society of Electro Acoustic Music in the US) but is also a conference that will help with the recovery of a city, its people, and its culture. We have also further updated performance resources which includes the Ensemble Surplus from Germany, NextEns from Cincinnati, Cat 5 from Mississipi, the infamous Convolution Brothers, dancers from the Tulane Theater and Dance Department, our own Tulane Music Department Musicians, Korean traditional instrumentalists from Seoul, and much more. During the conference we'll be giving away gifts and prizes (as well as lots of beads!) made possible by generous donations by our corporate sponsors such as Bias(numerous copies of Peak Pro XT), Parallax (10 BS2 boards with on board bread-boards), Mixmeister (more than $1000 worth of products), Maxim-IC (no not the magazine!), Electrotrap ($800 worth of sensors for your HCI needs), empreintes DIGITALes (special "ICMC" CD for all registered participants), Soundhack (5 copies of spectral shapers), fxpansion (one of each software type) and many more. Please visit www.icmc2006.org for details on updates and conference information. Laissez les bon temps roulez! Sincerely, Tae Hong Park, ICMC 2006 Conference Chair

18 years, 1 month

[linux-audio-dev] Linux soundapps pages updated

by Dave Phillips

Greetings: And another one hits the information goatpath : http://linuxsound.atnet.at (Europe) http://linuxsound.jp (Japan) http://linux-sound.org (USA) Best, dp

18 years, 1 month

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 February 2006