Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

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 (); }

22 years, 2 months

[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

22 years, 2 months

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

by Stefan Nitschke

>But you do have it recompiled for the right CPU architecture >and not only moved? Yes of course. >BTW: There is a prefech bug on AMD processors - try to run it recompiled >with less optimization, newer kernels have workarounds. I will try that... but I get the freezes only with jack. ALSA applikations run just perfect in rt mode. >Another thing to try is to run memtest86 (SuSE has it in Lilo menu) >let it run for a while (full night) I will do... and if nothing helps I will get a new mainboard ;-) - Stefan _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

22 years, 2 months

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

by Roger Larsson

On Tuesday 18 November 2003 20.57, Stefan Nitschke wrote: > >ping is answered = IRQs live. > >Could you please try this. > >Start rt_monitor in a text console CTRL-ALT-F1 > > > >Start your client, return to console - what does rt_monitor print? > > > >(It could be the memory leak and mlockall(FUTURE) problem, > >As I do not check that yet. > >Another alternative is a fast forking client - they are hard to stop) > > OK, I tested it. There is no output at all from rt_monitor. > I used the following: > - starting rt_monitor in a console as root > - ssh login from remote machine > - starting jack > - starting a jack client What client? Any client? > > after a few seconds the machine was froozen and no output > from rt_monitor. Hmm... > I assume its a hardware bug. On my Inspiron 8500 with nearly > the same linux-2.4.19.SuSE kernel (plus patch for speed-step) > I dont have any freezes at all. But you do have it recompiled for the right CPU architecture and not only moved? 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) /RogerL -- Roger Larsson Skellefteå Sweden

22 years, 2 months

[linux-audio-dev] ecasound 2.3.1 released

by Kai Vehmanen

1. A short summary of changes Ecasound's emacs mode, ecasound.el, has been updated to version 0.8.3. Due to severe bugs found in the native Python ECI implementation, the C implementation has been again set as the default. Minor interoperability problems with older JACK releases and Ecasound have been fixed. A bug that caused builds against an external libreadline to fail, has been fixed. Also recording problems with the WinTv 401Dbx and other bt878-based devices have been fixed. This release is compatible with the upcoming alsa-lib-1.0 releases. --- 2. What is Ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release Full list of changes is available at <http://www.wakkanet.fi/~kaiv/ecasound/history.html>. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches - Accepted code, documentation and build system changes Mario Lang (ecasound.el updated to 0.8.3, doc typo fixes) Junichi Uekawa (ecasound makefile bug, doc generation using Hevea) Kai Vehmanen (various) Bug Hunting - Reports that led to bugfixes (items closed) Hirendra Hindocha (2) -- recording problems with WinTv 401dbx, ecacontrol.py bugs Stefan Bundt (1) -- ecacontrol.py breaks under heavy load Dave Phillips (1) -- errors in EIAM help Junichi Uekawa (1) -- compability bug with older JACK versions --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.3.1.tar.gz Distributions with maintained Ecasound support: Agnula - http://www.agnula.org Debian - http://www.debian.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org PLD Linux - http://www.pld.org.pl SuSE Linux - http://www.suse.de/en Contrib Packages and Add-On Distributions: AudioSlack for Slackware - http://www.audioslack.com PlanetCCRMA for RedHat/Fedora - http://www-ccrma.stanford.edu/planetccrma/software Thac's RPMs for Mandrake - http://rpm.nyvalls.se Apps.kde.com packages for Mandrake/Redhat/SuSE - http://apps.kde.com/rf/2/info/id/2146 Note! Distributors do not necessarily provide packages for the very latest Ecasound version. -- http://www.eca.cx Audio software for Linux!

22 years, 2 months

[linux-audio-dev] [PATCH] oss driver for jack 0.90.0 - the actual patch :)

by Jussi Laako

Looks like I forgot to attach the patch... -- Jussi Laako <jussi.laako(a)pp.inet.fi>

22 years, 2 months

[linux-audio-dev] [PATCH] oss support for jack

by Jussi Laako

Hi, I've written preliminary OSS driver for JACK. Patch for jack 0.80 attached. This is by no means final, this is something pre-alpha, but seems to work at least with alsaplayer. It's likely to contains errors in jack driver implementation. All comments/patches/anything is welcome.. If you are compiling with OSS Lite, please comment out the non-S16 formats. RedHat RPMs and patch available at http://www.sonarnerd.net/linux/ , SuSE 9 packages coming. -- Jussi Laako <jussi.laako(a)pp.inet.fi>

22 years, 2 months

[linux-audio-dev] and just to finalize ...

by Paul Davis

what would all this mean for LADSPA? 1) there would need to be a way to associate plugins+GUIs since we probably don't want them in the same object. - could be done using LRDF or a dir search path combined with the plugin ID. 2) the GUI would have to declare which toolkit it was using so that the host could ensure support for it (i.e. fire up a thread that will run the equivalent of gtk_main or QApplication::exec()) and ask the relevant toolkit thread to call the primary entry point to the GUI. how does it declare this? a well known symbol? is it a char* or a function call? is it in the LRDF entry, or the filename, or what? 3) adopt a standard for how the entry point is to be called. presumably it should get a pointer to the plugin instance, but what (if anything) else? oh yes, a return value that provides a way to terminate the GUI. 4) the names of toolkits would have to be standardized and possibly include version information. "GTK+:2.2" or "Qt:3.1" might work, for example. 5) a small library (which i have more or less started already) to provide simple C functions to offer per-toolkit support. a host would look at the pluginGUI toolkit, call the support function with the .so name, and the right things would happen. the library needs an ancillary function to kill the GUI when the time is right. 6) [ only if we really wanted hosts to have a "real" handle on the plugin GUI window ] the library would need to contain a way to pass in an X "Window", and wrap it up as a native drawing area for each toolkit. i would prefer not to do this for now, if ever. --p

22 years, 2 months

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

by Stefan Nitschke

>BUT, I think a userspace daemon that starts at boot time and protects >against lockups (rt_monitor) would be a very good thing to have. > Yes indeed, but on my XP machine which freezes after a few seconds after a client had connected to jack even rt_monitor did not helped, the machine keeped totally locked. Ping is still answered but thats it. - Stefan _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

22 years, 2 months

[linux-audio-dev] Ann. Vstserver V0.2.8 and Ladspavst V0.1.5

by Kjetil Svalastog Matheussen

These updates makes it possible to use windows vst plugins in linux applications getting very descent realtime performance. I have successfully ran vst plugins in ardour with 2.66 ms latency. Sources: http://www.notam02.no/arkiv/src/ Linux Vst Compatibility Page http://80.61.20.184/vst/ Tutorial: http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/ Mandrake binaries: (not the latest versions (yet)) http://rpm.nyvalls.se/sound9.1.html Vstserver 0.2.7 -> 0.2.8: ------------------------- -Added SCHED_FIFO priority and locking all mem (mlockall) to the processing thread. Can be used without being root by for example using the givertcap program by Tommi Ilmonen http://www.tml.hut.fi/~tilmonen/givertcap/ To turn off realtime priority, start the vstserver with either the "-NRT" or "--nonrealtime" flag. vst ladspa plugin v0.1.5 - stable ---------------------------------- -Fixed the worst nonrealtimeness for the default mode. When using realtime priority on the vstserver, it should not be necesarry to set LADSPAVST_RT to "1". --

22 years, 2 months

Jump to page:

2026

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