Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7440 discussions

Re: [linux-audio-dev] virtual vocalist - I think we could have something similar without much work...

by Juan Linietsky

On Thursday 20 November 2003 01:09, Paul Davis wrote: > http://news.harmony-central.com/Newp/2003/Vocaloid.html You know, FESTIVAL (the popular and quite good opensource speech synthesis package) has a mode where you can feed it data to sing. It could probably not be very hard to write a similar GUI where you edit a pianoroll to make festival sing. Seems like a very nice small project, anyone willing to take it? Juan Linietsky

20 years, 10 months

[linux-audio-dev] [kconder@interaccess.com: Free music lessons from Berklee.]

by Hans Fugal

This from the csound list. Dr. Boulanger at Berklee has indicated that he is also working on a csound course to be posted there. -- Hans Fugal | De gustibus non disputandum est. http://hans.fugal.net/ | Debian, vim, mutt, ruby, text, gpg http://gdmxml.fugal.net/ | WindowMaker, gaim, UTF-8, RISC, JS Bach --------------------------------------------------------------------- GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460

20 years, 10 months

Re: [linux-audio-dev] virtual vocalist - I think we could have something similar without much work...

by Juan Linietsky

On Sunday 23 November 2003 09:07, Luke Yelavich wrote: > At 08:56 PM 24/11/2003, Juan Linietsky wrote: > >On Thursday 20 November 2003 01:09, Paul Davis wrote: > > > http://news.harmony-central.com/Newp/2003/Vocaloid.html > > > >You know, FESTIVAL (the popular and quite good opensource speech synthesis > >package) has a mode where you can feed it data to sing. > >It could probably not be very hard to write a similar GUI where > >you edit a pianoroll to make festival sing. > > There is a much better speech synthesizer, known as DECtalk which can sing > quite well, and it is very easy to programme. The nicer thing is, it is > available for Linux as well! I have it here, so I will did up a text file, > and post the resulting OGG if anybody is interested :) As far as I know, dectalk is commercial, isnt it? Juan Linietsky

20 years, 10 months

[linux-audio-dev] oh no ... virtual vocalists ...

by Paul Davis

http://news.harmony-central.com/Newp/2003/Vocaloid.html

20 years, 10 months

[linux-audio-dev] spiral modular synth problem [libGL.so woes]

by Florian Schmidt

Hi, i tried to build the spiral modular synth [it's the same problem for cvs and release]. Builing works fine, but running afterwards throws out a bunch of error when trying to load the plugins. The errors are all similar to this one: WARNING: File /usr/local//lib/SpiralPlugins/MoogFilterPlugin.so could not be examined dlerror() output: libGL.so.1: cannot handle TLS data Ok, i see that me running the nvidia binary only drivers could have something to do with it, but i wonder why the plugions get linked agains libGL.so anyways.. Here's a link line from the build procedure: g++ -shared -o JackPlugin.so JackPlugin.o JackPluginGUI.o ../SpiralPlugin.o ../SpiralPluginGUI.o ../../ChannelHandler.o ../../Sample.o ../../RiffWav.o ../Widgets/Fl_Knob.o ../Widgets/Fl_LED_Button.o ../../../GUI/Widgets/SpiralGUI.o -L/usr/X11R6/lib -L/usr/local/lib/ -L/usr/X11R6/lib -lfltk -lXft -lpthread -lm -lXext -lX11 -lstdc++ -lGL -lXext -lX11 -ldl -lrt -ljack -lpthread I suppose it get's this flag from some library or something but i didn't suceed in finding out from where... Anyone can shed light on this issue? Flo -- music: http://www.soundclick.com/bands/9/florianschmidt.htm

20 years, 10 months

[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

20 years, 10 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.)

20 years, 10 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. --

20 years, 10 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 }

20 years, 10 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

20 years, 10 months

Jump to page:

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