Linux-audio-dev November 2003

linux-audio-dev@lists.linuxaudio.org

84 participants
92 discussions

[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, 1 month

[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, 1 month

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

by Paul Davis

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

21 years, 1 month

[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, 1 month

[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, 1 month

[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, 1 month

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, 1 month

[linux-audio-dev] oss driver for jack 0.90 rev3

by Jussi Laako

Now the oss driver for jack 0.90 starts to shape up. This could be considered as alpha version. Changes: - Conditionally compiled two thread implementation for NPTL (possibly also works with LinuxThreads, untested) - Fixed a load of bugs This version has been tested with CMI8738, ENS1371 and M-Audio Delta1010. (OSS 3.9.8a) This version has been tested to work under load up to 8-in, 8-out, 24-bit 96 kHz with period size of 128. Patch available at http://www.sonarnerd.net/linux/jack_oss.patch and RPMs and tarball at http://www.sonarnerd.net/linux/ Someone familiar with autoconf/automake could see the drivers/oss/Makefile.am for some better way of enabling NPTL/barrier stuff... ;) -- Jussi Laako <jussi.laako(a)pp.inet.fi>

21 years, 1 month

[linux-audio-dev] plugin GUIs

by Paul Davis

the following is tiny example to show that its possible to use XEMBED or just native X Window IDs to create host-managed plugin GUIs. GTK+2 and Qt3 both support XEMBED; GTK+2 supports use of native X Window ids when creating new top level windows, i am not sure about Qt (does anybody here know how to do it). this means that a GTK host can manage a Qt GUI or vice versa, without any toolkit specific hacks in the host or in a library linked by the host. i offer this as a proof of concept. i believe that our problems with GUIs for plugins are pretty much over, modulo defining some standards as per another recent from me. --p ---------------------------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include <gtk/gtk.h> #include <gdk/gdkx.h> gboolean button_pressed (GtkWidget *widget, GdkEventButton *event, gpointer user_data) { fprintf (stderr, "host: button press at %g,%g\n", event->x, event->y); return TRUE; } gboolean delete_event (GtkWidget* widget, GdkEvent* event, gpointer user_data) { fprintf (stderr, "host: window delete event\n"); gtk_main_quit (); return TRUE; } gboolean plugin_button_pressed (GtkWidget *widget, GdkEventButton *event, gpointer user_data) { fprintf (stderr, "plug: button press at %g,%g\n", event->x, event->y); return TRUE; } gboolean plugin_delete_event (GtkWidget* widget, GdkEvent* event, gpointer user_data) { fprintf (stderr, "plug: window delete event\n"); gtk_main_quit (); return FALSE; } int plugin_main (GdkNativeWindow window_id) { GtkWidget* embedded_parent; GtkWidget* dummy_label; GdkWindow* foreign_window; int argc = 1; char **argv = (char **) malloc (sizeof (char*)); argv[0] = "plugin"; gtk_init (&argc, &argv); #ifdef USE_XEMBED embedded_parent = gtk_plug_new (window_id); #else embedded_parent = gtk_window_new (GTK_WINDOW_TOPLEVEL); foreign_window = gdk_window_foreign_new (window_id); gtk_widget_set_parent_window (embedded_parent, foreign_window); #endif dummy_label = gtk_label_new ("This is a LADSPA Plugin GUI"); gtk_container_add (GTK_CONTAINER(embedded_parent), dummy_label); gtk_signal_connect (GTK_OBJECT(embedded_parent), "button-press-event", GTK_SIGNAL_FUNC (plugin_button_pressed), NULL); gtk_signal_connect (GTK_OBJECT(embedded_parent), "delete-event", GTK_SIGNAL_FUNC (plugin_delete_event), NULL); gtk_widget_add_events (GTK_WIDGET (embedded_parent), GDK_BUTTON_PRESS_MASK|GDK_BUTTON_RELEASE_MASK); gtk_widget_show (embedded_parent); gtk_widget_show (dummy_label); } int main (int argc, char *argv[]) { gtk_init (&argc, &argv); GtkWidget* embedded_parent; GtkWidget* embedded_window; embedded_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); #ifdef USE_XEMBED embedded_parent = gtk_socket_new (); gtk_container_add (GTK_CONTAINER(embedded_window), embedded_parent); gtk_widget_show (embedded_parent); #endif gtk_signal_connect (GTK_OBJECT(embedded_window), "button-press-event", GTK_SIGNAL_FUNC (button_pressed), NULL); gtk_signal_connect (GTK_OBJECT(embedded_window), "delete-event", GTK_SIGNAL_FUNC (delete_event), NULL); gtk_widget_add_events (GTK_WIDGET (embedded_window), GDK_BUTTON_PRESS_MASK|GDK_BUTTON_RELEASE_MASK); gtk_widget_set_size_request (GTK_WIDGET(embedded_window), 100, 100); gtk_window_set_title (GTK_WINDOW(embedded_window), "A Plugin"); gtk_widget_show (embedded_window); gtk_widget_realize (embedded_window); #ifdef USE_XEMBED plugin_main (gtk_socket_get_id (GTK_SOCKET(embedded_parent))); #else plugin_main (GDK_WINDOW_XID (embedded_window->window)); #endif gtk_main (); }

21 years, 1 month

[linux-audio-dev] ANNOUNCE: QSynth 0.0.1 - Qt interface to fluidsynth

by Chris Cannam

[This has been announced on LAA already, but I gather crossposts are expected.] We'd like to announce the first alpha release of QSynth, an attractive Qt front-end to fluidsynth. QSynth is brought to you by Rui Nuno Capela, developer of qjackctl, together with Richard Bown and Chris Cannam of the Rosegarden team. QSynth provides a simple front and configuration interface to the fluidsynth software synthesiser to allow persistent storage of fluidsynth configuration (and soundfonts) as well as providing visual feedback and front panel controls for software synthesiser parameters. QSynth can be used either as a standalone player or in conjunction with any compatible sequencers. For more details, screenshots, mailing list details and to download the source code please visit: http://qsynth.sourceforge.net Requirements are Qt3.1.1 and libfluidsynth. Please let us know how you get on with it! Chris

21 years, 1 month

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 November 2003