Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7440 discussions

[linux-audio-dev] Ron Parker and Mirror Image in Sound on Sound

by Daniel James

Hello all, The feature I wrote on Ron Parker's studio starts on page 208 of the February 2004 issue of Sound on Sound magazine, out today. It also has a section featuring Mark Knecht, and contributions from Steve Harris. The article is mostly about using Ardour, JACK and JAMin together. The article is also on the SoS website, but it is only available to subscribers for the first six months. http://www.soundonsound.com/sos/feb04/articles/mirrorimage.htm Cheers Daniel

20 years, 8 months

[linux-audio-dev] New name for ladcca?

by Bob Ham

Hi all, The name "LADCCA" was always intended to be a working name but even though there's a long way to go, it's out there and people seem to be using it. I wouldn't worry about it that much, but the first thing anyone seems to say about LADCCA is "what a horrible name" :) I'm crap at thinking up stuff like this (JACK Rack was originally called "JACK LADSPA Host" :) so if anyone has any decent ideas, please let me know. Cheers, Bob -- Bob Ham <rah(a)bash.sh> "At some point, keystroke recorders got installed on several machines at Valve. Our speculation is that these were done via a buffer overflow in Outlook's preview pane." -- Gabe Newell on the Half-Life 2 source leak

20 years, 8 months

Re: [linux-audio-dev] Re: linuxaudio.org

by iriXx

Marek Peteraj wrote: > Suddenly you're now speaking as the representative of the whole Linux > >audio community. But you're not. Neither am I. The only true >representatives of the Linux Audio community are the Linux Audio >Developers. > ehh?? where's the logic in that?? as a composer, i say: what good is my writing music without an audience to hear it? what good is it writing applications, if there is noone to use them? what good is a body, if every part of it wanted to be a hand, or a foot? it would not function without eyes, nose, ears... you speak as if the Linux Audio Developers are some kind of gods... but none of us would exist in this community without each other. thats what c-o-m-m-u-n-i-t-y means. m~ -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. --Benjamin Franklin |\ _,,,---,,_ ZZZzz /,`.-'`' -. ;-;;,_ HTTP 503: Too Busy |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) fL .::. www.iriXx.org .::. www.copyleftmedia.org.uk .::.

20 years, 8 months

[linux-audio-dev] [ANN] TimeMachine 0.2.1

by Steve Harris

http://plugin.org.uk/timemachine/ * Now uses GTK, instead of SDL to draw the window, hopefully a bit more friendly on maintainers. * Meters. * Now records up to 8 channels (use the -c flag). * Can set the output directory/file prefix (-p flag). * Hiting the window close icon now makes sure you have all the data written to disk. I've a feeling that someone mailed me a patch and I've lost it and not included it, so if its you please mail me again. Enjoy, Steve

20 years, 8 months

[linux-audio-dev] Two or more monitors) Re: Project: modular synth editor

by gml＠xs4all.nl

A) Xinerama _does_ support open GL, at least with my matrox card, I can have openGL on one monitor of the two. That is a limitation of the card hardware, AFAIK, not of X. Still there are a lot of these cards around so openGL would not be very useful. B)ergonomics Mutli head setups are extremely useful. I can easily see both monitors without turning my head, and in a glance I can see the state of several applications. Or I have the documentation in a browser on one monitor and the app on another. Much easier on the brain than constantly switching workspaces back and forth. In a studio there is also a lot of other gear that needs to be watched; mixing-desk, outboard equipment, talent etc. Using a multihead setup you can put the transport and the metering on a monitor near the console, and the editor window on a monitor optimally placed for "desk-work" ergonomics (eye height, keyboard at the right place etc) It is also adviced to move your eyefocus around during work to prevent RSI. (look out a window etc.) Focusing to much on a relatively tiny area all the time is very bad ergonomics. So head movement by itself is not bad, the opposite in fact. Gerard > From: Kjetil Svalastog Matheussen <k.s.matheussen(a)notam02.no> > Benjamin Flaming: >> >> "People without working hardware acceleration" includes anyone >> using more >> than one monitor. X refuses to allow hardware acceleration with >> Xinerama. >> Since multiple monitors are central to my working style (and that of >> many >> recording studios), using OpenGL could have serious drawbacks. >> > > Programs where it makes sense using two or more monitors are in my opinion > seriously crippled. Its about 2.3 million times faster (rough guess) to > press a key (to switch to another view) than to turn your head. In > addition, you can get wiplash (or something similar) by turning your head > too much. Please explan why I'm wrong, if I am. > > > --

20 years, 8 months

[linux-audio-dev] (Two or more monitors) Re: Project: modular synth editor

by Kjetil Svalastog Matheussen

Benjamin Flaming: > > "People without working hardware acceleration" includes anyone using more > than one monitor. X refuses to allow hardware acceleration with Xinerama. > Since multiple monitors are central to my working style (and that of many > recording studios), using OpenGL could have serious drawbacks. > Programs where it makes sense using two or more monitors are in my opinion seriously crippled. Its about 2.3 million times faster (rough guess) to press a key (to switch to another view) than to turn your head. In addition, you can get wiplash (or something similar) by turning your head too much. Please explan why I'm wrong, if I am. --

20 years, 8 months

[linux-audio-dev] Creative goes PRO

by Jan Weil

http://uk.europe.creative.com/press/detail.asp?ref=2013&prcoun=16 Not yet mentioned on http://opensource.creative.com , though. ;)

20 years, 8 months

[linux-audio-dev] Re: Project: modular synth editor

by Juhana Sadeharju

>From: Dave Robillard <drobilla(a)connect.carleton.ca> > >I don't really understand what this software would actually do. Seems >like such an overly-broad generic idea.. audio, graphics, modular >synths, software, hardware, editor ?? Yes, it is generic idea because visual programming (icons + wires) is used everywhere. I planned that our editor would support specially audio related applications: Nord Modular type, Reaktor type, and simpler type editors. Graphics related editor for, e.g., Cinepaint would be much simpler than Nord Modular type editor. The editor would only give the graphical graph/dataflow editor: icons + wires, subgraphs, export/import. People still would have to write software to give meaning to the graph/dataflow. I find it very difficult to code the graphical editors and other GUIs. Mostly I write C code without GUI. Now if there already would be a generic editor available, I would take one and write suitable callbacks, and have the GUI in a few hours. Glade, a GUI builder, can help but it fails badly for what really would be usable. They should go a far beyond the widget level. Note, we do have such graph editors (in PD, in Quasimodo, etc.) but the problem is that they are limited to some particular concept. I want use all concepts in the same editor. Regards, Juhana

20 years, 8 months

[linux-audio-dev] qsynth configure script fails on debian [qt]

by Florian Schmidt

Hi, i just compiled qsynth-0.1.0 and i would lie to report on my findings: On Debian, the qt-libs are installed to /usr/lib/ and the headers to /usr/include/qt3 There's no QTDIR per se. So i exported it to be /usr. This way, the configure script finds the lib, but the following test fails: checking whether QTDIR environment variable is set... /usr/ checking for Qt library... qt-mt checking for Qt library version >= 3.1.1... no; Qt 3.1.1 or greater is required the entry from config.log: ---- configure:1167: c++ -o conftest -g -O2 -I/usr//include conftest.C -L/usr//lib -L/usr/X11R6/lib 1>&5 configure:1157:21: qglobal.h: No such file or directory configure:1161:2: #error Qt library 3.1.1 or greater required. configure: failed program was: #line 1156 "configure" #include "confdefs.h" #include "qglobal.h" int main() { #if QT_VERSION < 0x030101 #error Qt library 3.1.1 or greater required. #endif ; return 0; } ---- Hmm, looking at the commandline to compile this, it cannot work, since the include path is /usr/lib. so i changed this in the configure script: #include "confdefs.h" #include "qglobal.h" to #include "qt3/confdefs.h" #include "qt3/qglobal.h" Then i get an error again: cannot find confdefs.h. So i check my qt3 include dir and it is not there. so i removed the line from the qt3 test program from configure. And now the test runs fine and the program compiles nicely.. My suggestion: Add a --with-qt-inc-dir and a --with-qt-lib-dir switch to the configure script, so "non standard" [though the qt way itself is non standard] qt installations can be found, to. I still wonder where that confdefs header file lives on my computer. gonna start a find / now ;) Maybe there's a more grcefule way to handle this configure problem. /me doesn't know it.. Flo -- music: http://www.soundclick.com/bands/9/florianschmidt.htm

20 years, 8 months

[linux-audio-dev] Re: Project: modular synth editor

by Juhana Sadeharju

Hello. NMEdit was mentioned in my list. I'm in their devel list but it has been quite quiet. I will check Graphviz better in a few days but can one make Quasimodo or Nord Modular type "graphs" with it? In a quick look I saw some composite icons (not widgets?), but I feel Graphviz is not very usable for us. -*- Both the standalone editor and the embedded editor would be needed. Standalone editor could use sockets and shared memory for communicating between the editor and application. Embedded editor could be launch by filling in a callback table and calling the editor: GtkWidget *editor; editor = editor_create(callbacktable); gtk_widget_show(editor); It could be slightly more complex if GTK is not the only supported toolkit. We also could have editor_menu_create() if one wants attach the editor related menu to application's menubar. -*- Should we provide a standard (XML script?) for building module interfaces? New GUI widgets would be included as soon as somebody writes them. This kind of approach would be needed in creating plugin GUIs and environments (a la Logic Audio). Should we allow module author to code the GUI for the module using directly GTK? How GMPI handles the plugin GUIs? I see that we would do an overlapping work here. -*- Assume I have written a module GUI with GTK. I load the calling function to the editor and create the GUI with modulewidget = mymodule_create_gui(); gtk_widget_show(modulewidget); Now, can I trace the whole widget hierarchy starting from "modulewidget"? In GTK, can one attach names to the widgets? E.g., I have a small pixmap of a connector where a cable is plugged in. I want name all these widgets as "connector". Then in the editor I would search all connectors by tracing the widget hierarchy and looking for "connector" names. We need to know where these connectors are located because we want be able to plug the cables in. Alternatively we could describe the locations in a file, but then we would be bound to the fixed shape GUIs. -*- In gtk related mailing lists I have already suggested a general way how to implement a zoom in the editor (Widget Portal). If that is not possible in GTK, then I see no other way than write new widgets with a zoom ability. Regards, Juhana

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