Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

5 participants
7515 discussions

[linux-audio-dev] ANN: RTMix 0.75 released

by Ivica Bukvic

Greetings! It's my pleasure to announce immediate availability of RTMix version 0.75. RTMix is an interactive multimedia art performance, composition, and coaching interface capable of triggering various DSP applications and/or processes concurrently, as well as offering a tight coordination between computer(s) and live performers. It can also trigger real-time events utilizing MIDI and OSC protocols, and can be in theory networked from a single client with up to 1000 other RTMix clients (personally neither have I had the opportunity to try this and besides the network latency would probably get the best of it anyways). For more info on what it is, what it does, and how it does it, please see the online docs: http://meowing.ccm.uc.edu/~ico/RTMix-doc/ Changelog: *Minor bug fixes in scripting language. *Ability to connect directly to /dev/sequencer (needs to be tested -- any help in bug reporting is greatly appreciated!). This should theoretically enable users to have theoretically infinite number of MIDI devices hooked up to RTMix (using ALSA's aconnect). *UI improvements (mostly "eye-candy"). *New LED icons for improved visibility. *Improved functionality of the Console. *Full documentation included in the distribution (just in case someone missed this one from before :-). *New application icons (16x16 to 192x192). *Smaller tarball. *This is the last version before the milestone 0.8 release with that will sport a completely revamped UI and many new features. RTMix has so far been featured at ICMC 2002 conference (Sweden), SEAMUS 2003 conference (US), in the "Organised Sound" magazine (December 2002), and has been used in several of my works whose recordings are available on my website. If you happened to use RTMix in your work, I would love to hear in what ways you got to utilize its features, as well as how can I make the application better. Thanks! The tarball is available for immediate download from: http://meowing.ccm.uc.edu/~ico/rtmix-latest.tar.gz (4.07MB) For more info, please visit my website and/or the online documentation (provided above). Best wishes, Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico

21 years, 11 months

Re: [linux-audio-dev] cute idea from the VST world ...

by Dustin Barlow

>From: Paul Davis <paul(a)linuxaudiosystems.com> >Reply-To: "The Linux Audio Developers' Mailing >List"<linux-audio-dev(a)music.columbia.edu> >To: linux-audio-dev(a)music.columbia.edu >Subject: [linux-audio-dev] cute idea from the VST world ... >Date: Wed, 19 Nov 2003 23:08:06 -0500 > > http://www.fxfreeze.com/product.html Cubase SX 2.0 has the same functionality built in. Not sure whose idea it was first. _________________________________________________________________ Say goodbye to busy signals and slow downloads with a high-speed Internet connection! Prices start at less than $1 a day average. https://broadband.msn.com (Prices may vary by service area.)

21 years, 11 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

by Kjetil Svalastog Matheussen

"Jack O'Quin": > > I've been thinking about ways to use this feature to improve and > simplify the current security situation for Linux audio. No > conclusions, but here are some thoughts for discussion: > > (1) There should a simple way for the sysadmin to reliably disallow > realtime privileges. One way to allow (or prevent) access to > realtime privileges for any program is via a sysctl global variable. > Of course, loading the kernel extension is a privileged operation, > anyway. But, I prefer some positive means of blocking it. > > (2) Using sysctl, set a group id (like `audio') for which realtime > privileges are automatically granted. Then, we could just install > realtime apps with `setgid audio'. This seems much better than > opening things up to *any* application. And, audio applications > would not need root privileges any more. This would be a rather big > improvement over the current jackstart/jackd situation. > > (3) We could also define a default realtime group (gid 0 maybe), > since `audio' probably does not exist on many distributions. IIUC, > this is originally a Debian idea. I don't know how widely it has > been adopted. I like it and think it should become a universal > Linux convention, allowing access to the sound card as well as > realtime privileges. > What about this one: (4) Let the user that is currently physical logged in to the machine get realtime privileges. --

21 years, 11 months

[linux-audio-dev] ice1712 dshare asoundrc

by Garett Shulman

I would really like to do hardware mixing since my card should support it. I have been hacking away trying to google and decypher the plugin docs and have created the following asoundrc. However, when I try to run a second instance of fluidsynth on 44_2 I get the following error: ALSA lib pcm_dshare.c:800:(snd_pcm_dshare_open) destination channel specified in bindings is alread used. I'm not sure what I'm doing wrong. Is alsa simply not capable of taking advantage of the ice1712 hardware mixer? Here is the asoundrc I have so far. pcm.44_dshare { type dshare ipc_key 42892323 ipc_key_add_uid yes slave { pcm "hw:0,0" period_time 0 period_size 70 periods 24 buffer_size 1024 channels 10 } bindings { 0 0 1 1 2 2 3 3 } } pcm.44_1 { type plug ttable.0.0 1 ttable.0.1 1 slave.pcm 44_dshare } pcm.44_2 { type plug ttable.0.2 1 ttable.0.3 1 slave.pcm 44_dshare }

21 years, 11 months

[linux-audio-dev] cross-toolkit host/plugins: significant news

by Paul Davis

its been a productive evening/night. or has it? i hacked up a small test that runs Qt as a host, and loads a shared object that uses GTK+ as its GUI. the host loads the shared object, and runs its GUI, in addition to its own. cool, eh? well, not so fast. i am now wondering what in the hell all the fuss was about in the first place. and as the main progenitor of "you can't do this", i feel responsible for cleaning up the mess. why? i don't see anything in what i've done that is at all clever. the only slightly tricky part is running the GTK+ GUI in its own thread, and routing requests to instantiate a new GUI to that thread via a pipe that is hooked into the GTK+ event loop. i can't see any reason why *any* toolkit couldn't be used in this way (assuming it can do this kind of "add an fd to the event loop" thing, and AFAIK they all can). i even removed all the stuff i added to open a dedicated X Display - it just isn't necessary. Qt and GTK+ both have their own connection to the X Server, and there are separate event loops handling windows created by each toolkit, each running in its own thread. all you have to avoid is a plugin calling QApplication::exec() or gtk_main() etc., which will different and odd effects on each toolkit. AFAICT, there are two things the host can't really do. one is to snoop on events for other toolkit's loops. so, a host that relies on snooping keyboard events (e.g. ardour) is out of luck when it comes to events occuring in plugin GUI windows using a non-host-toolkit. the host also cannot get access to the toplevel windows of the non-host-toolkit, so it can't add the kind of generic widgets that you tend to see on TDM/VST plugin GUIs for "bypass", "save" and so forth. but to return to the core issue here. what the f*ck have i been ranting on about all this time? unless its just the issue of globals in Xlib, but i really don't believe they are there anymore, at least not in XFree86 ... yes, the toolkits can't share an X Display, but fer chrissakes! they don't even try to!! to put in bluntly, it appears that i have been totally and utterly full of crap, and have unnecessarily delayed the advent of decent plugin GUIs on linux by a year or more. if anybody wants to see the code for my little demo, i'll tar it up. i hate the way Qt takes over the build process. It reminds me too much of Oracle in this respect. Anyway, i need to get to bed. I feel glad that this can be made to work, but embarrased about what i may have done here. --p

21 years, 11 months

[linux-audio-dev] cute idea from the VST world ...

by Paul Davis

http://www.fxfreeze.com/product.html

21 years, 11 months

[linux-audio-dev] Great news for JACK & KDE

by Ivica Bukvic

Hi guys, check out this one (this may be old news for some and for that I do apologize): http://developer.kde.org/development-versions/kde-3.3-features.html Seems like Arts already has a JACK output plugin finished and ready for the 3.3 KDE release! Yay! Ico

21 years, 11 months

[linux-audio-dev] modular synth GUI status?

by Juhana Sadeharju

Hello. Who of us are working on a modular synth GUI where user grab&drag modules and connects them with cables? I'm myself interested in the editor GUI development --- there already are many modular audio engines, but not particularly good GUIs (Quasimodo might be an exception if I remember correctly). Below is a short list of modular synths. I'm still searching for more. I will mail an updated list later, but at meanwhile you could help me ;-) Regards, Juhana == cut == Name Author Has cable-GUI Has script-GUI ----------------------------------------------------------------------------- Nord Modular Clavia Yes No Harmonizer/Vsig Eventide Yes Yes Oasys Korg ? ? Csound Barry Vercoe No Yes Cmusic ? No Yes Quasimodo Paul Davis Yes No PD Miller Puckette Yes No PSK ? No Yes jmax ? ? ? Nyquist (1) R.B. Dannenberg No Yes SAOL ? No Yes ?? Creamware Yes No Arts ? Yes No Vaz Modular ? Yes No Reaktor ? Yes No Tasman ? ? ? SyncC modular ? ? ? BlockCompiler Matti Karjalainen No Yes == cut ==

21 years, 11 months

[linux-audio-dev] Introduction to building MIDI controllers?

by Adam King

Hi all, I was just wondering if anyone knows of any good resources for an introduction to building hardware MIDI controllers? Any recommendations for books or online references would be appreciated. I've been looking at Digital Projects for Musicians by Craig Anderton on amazon, but the reviews seem to be pretty negative. Any advice? - Adam

21 years, 11 months

Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24

by Stefan Nitschke

>BTW: There is a prefech bug on AMD processors - try to run it recompiled >with less optimization, newer kernels have workarounds. > >Another thing to try is to run memtest86 (SuSE has it in Lilo menu) >let it run for a while (full night) > I solved the freezing problem by compiling jack to use a tmpfs for its temp files! BTW to get low latency working on that machine I had to switch down from IDE DMA100 to DMA66 mode. Now I am sure that there is a nasty bug with my ASUS A7V-266E board. Nice to see that it is solved by just adding: tmpfs /tmp/ramdisk/ tmpfs size=5M,nr_inodes=1k,mode=777 0 0 to fstab:) Which RAM disk size is OK for jack? - Stefan _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

21 years, 11 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