Re: [LAD] Sek'd Prodif 96
Reid Fletcher wrote: I have a couple of sound adapters labeled Sek'd Prodif 96 They are known to be a good card. However I have been unable to find any drivers for Linux for these. sound/pci/Kconfig says: | config SND_RME32 | tristate RME Digi32, 32/8, 32 PRO | help | Say Y to include support for RME Digi32, Digi32 PRO and | Digi32/8 (Sek'd Prodif32, Prodif96 and Prodif Gold) audio | devices. | | To compile this driver as a module, choose M here: the module | will be called snd-rme32. Regards, Clemens ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] I'd like to jump in
Hello Gabriel, After looking at the composite website, the code and my time constraints (PhD, Familly), I would like to join forces with you on Composite. What is there to be done? On the long run I would like to take some technology of tX into Composite, especially the turntable-feeling and the scratching ability. This could be done by creating a new window, where the instruments/samples are portrayed as turntables which can be scratched either by mouse or external hardware. What do you think? Regards, Gerald ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Sek'd Prodif 96
On Mon, Apr 4, 2011 at 1:17 AM, Reid Fletcher fletc...@uwyo.edu wrote: I have a couple of sound adapters labeled Sek'd Prodif 96 as noted by clemens, these are essentially rebranded RME Digi card. this is good and bad - you get support, but actually the h/w for these cards is not very well designed. they were designed just before RME had their epiphany and realized how to do bus mastering and really get stuff right. they will work, but they are not very CPU efficient and probably won't support low latencies as well as the Digi9652 and later RME devices. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] ANN: upcoming L2Ork performances and a new pd-l2ork software release
Dear Friends and fellow L2Ork and Pd enthusiasts, I would greatly appreciate it if you would please distribute the following announcement. The spring is in the air, which means it is time for the spring DISIS (http://disis.music.vt.edu) and L2Ork (http://l2ork.music.vt.edu) events. To start the season right, this past Friday L2Ork had a sneak preview performance at Roanoke College. More so, this coming weekend we are having a truly special series of events with the return of the Boys Girls Club laptop orchestra whom we've been working with this semester. In addition, the spring DISIS event will also include guest artists and scholars Ron Coulter, Brad Garton, Peter Kirn, and Dave Phillips. The upcoming events include: Thursday April 7 @ 3:30-4:45pm in DISIS presentation by Brad Garton Friday 10am-1pm lectures in the Arts Armory by Brad Garton, Peter Kirn, and Dave Phillips (free admission) Friday April 8 @ 7pm in Dumas Center (Roanoke, VA) children's concert featuring Boys Girls Club laptop orchestra and L2Ork Saturday April 9 @ 7pm in Squires Recital Salon children's benefit concert (an Arts Fusion event) featuring Boys Girls Club laptop orchestra and L2Ork followed by a hands-on laptop orchestra demo session for kids and families ($5 general, $3 children/students/seniors, with all proceeds benefiting Boys Girls Club) Saturday April 9 @ 8pm in Squires Recital Salon benefit concert (an Arts Fusion event) featuring Ron Coulter, Brad Garton, Peter Kirn, Dave Phillips, and L2Ork ($5 general, $3 children/students/seniors, with all proceeds benefiting Boys Girls Club) This year we've also partnered up with the Virginia Tech Kids' Tech University program to expand our outreach to young audiences. For additional info on the upcoming events, please visit our Events page or our Facebook Event page (http://www.facebook.com/event.php?eid=136468179758733). To keep up with the latest updates, join us on Facebook (http://www.facebook.com/group.php?gid=117918141555131). As if that weren't exciting enough, earlier this weekend we've made yet another public release of pd-l2ork (http://l2ork.music.vt.edu/main/?page_id=56) with even more cool features and fixes (changelog: http://l2ork.music.vt.edu/data/pd/Changelog). Our site has been also updated with the new promotional materials and photos. Yet, in the spirit of Steve Jobs' keynote speeches we've left the best for last. Stay tuned for more exciting updates soon ;-) For additional info on L2Ork, visit http://l2ork.music.vt.edu. Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On 03/04/11 04:34 AM, Stefano D'Angelo wrote: 2011/4/2 Tim Goetzet...@quitte.de: [Stefano D'Angelo] 2011/3/29 Tim Goetzet...@quitte.de: It is very unfortunate that such a change might break the way your bridge code works, Stefano, and I would like to apologise in advance. (If the addition of a 'version' symbol exported by caps.so is any help, I'll be happy to add that.) [...] Regarding the addition of a symbol, introducing something into LADSPA (because if we agree on something, it's probably going to become a generic mechanism in the end) is really something I would avoid. It kind of both defeats the purpose of doing bridging well (i.e., no need to make changes to existing stuff) and also it would be unfair to recommend an addition to LADSPA without agreement from the whole LADSPA community. Thanks Stefano, this extra symbol wouldn't be an addition to LADSPA itself. Instead, it would be one private to caps.so, completely independent of the plugin standard. Like so, for example: void * h = dlopen (/path/to/caps.so, RTLD_LAZY); /* assuming h is valid, check for caps */ const int * caps = (const int *) dlsym (h, __caps_version__); if (caps) printf (found caps version %d.%d.%d, caps[0], caps[1], caps[2]); Should you consider special-casing for individual plugin libraries a pragmatic and viable approach, I'd imagine something like this to be helpful. (Put together, the caps library version and the UniqueID of a plugin guarantee a stable port signature.) Ok, it seems like this is the best way to do it after all... in the hope that this does not become a trend among LADSPA plugin authors. Best regards, Stefano P.S.: using two version numbers instead of three could be of help in my case... Global identifiers beginning with __ are reserved for the C implementation... Might as well just use LADSPA as a prefix instead of CAPS, in case this needs doing somewhere else... though this whole thing is extremely awful, and I really hope that is not the case... Another less awful option would be to somehow add the information to the library that the port is connectionOptional... -dr P.S. Just to verify, the new port index will be a new index greater than all the old ones, right? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
