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.
>
>
> --
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.
--
>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
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
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
Hello.
I would like to clarify that the project originally was not about
writing a common modular synth patch editor. The idea was not that
we would have a common modular synth patch format.
The idea was to have an editor which anyone could take and configure
for their own system (audio, graphics). All the whistles and bells
would be there to re-implement the existing editors.
All individual software would still be individual software having
nothing common. Search for the ultimate modular synth system would
still continue. It certainly is easier to extend the existing modular
synths if the editor supports the features.
However, this development could lead to a standard module GUI system.
After the project is finished we would have:
-Discussions, ideas
-Technical information
-Example implementations
-A code library
-Complete editor
Maybe.
Regards,
Juhana
JACK RELEASE 0.94.0
JACK is a low-latency audio server, written primarily for the GNU/Linux
operating system. It can connect a number of different applications to
an audio device, as well as allowing them to share audio between
themselves. Its clients can run in their own processes (ie. as normal
applications), or can they can run within the JACK server (ie. as a
"plugin").
JACK is different from other audio server efforts in that it has been
designed from the ground up to be suitable for professional audio work.
This means that it focuses on two key areas: synchronous execution of
all clients, and low latency operation.
JACK's webpage is at http://jackit.sf.net .
CHANGES:
Mostly minor, internal changes.
* Added missing extern "C" {} for better C++ support.
* Added missing copyright header.
* Better placement of watchdog check so it doesn't interfere with
freewheeling mode.
* Fixed option parsing problems
* ALSA driver reports actual samplerate, not requested samplerate.
* Handles hardware where playback and capture rates differ better.
* Support for native endian S24_3 format used by USB soundcards.
* jack_metro example ported to new transport API.
* cleaned up prototype declarations for jack_initialize_shm() and
jack_cleanup_shm().
* Eliminated calls to jack_error() when jack_client_new() fails
because the server was not running.
* Eliminated other calls to fprintf() in libjack.
* Won't try and compile iec61883 if libraw1394 is below
version 0.10.0.
* Internal bug fixes.
* Updated documentation.
Taybin Rutkin
On Sun, 2004-01-18 at 13:05, iriXx wrote:
> Marek Peteraj wrote:
>
> >On Sun, 2004-01-18 at 12:27, iriXx wrote:
> >
> >
> >>Marek Peteraj wrote:
> >>
> >>
> >>
> >>>On Sun, 2004-01-18 at 03:22, iriXx wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>>It should become another LAD event where the linux audio developers
> >>>>>present their work(such as ZKM LAD conference, LinuxTag LAD booth).
> >>>>>
> >>>>>comments?
> >>>>>
> >>>>>Marek
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>yes.
> >>>>there are people /other/ than linux audio developers who will be on the
> >>>>stand at Sounds Expo. its not just an audio development forum.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>such as?
> >>>
> >>>
> >>>
> >>>
> >>myself.
> >>
> >>
> >
> >Cool. Are you a visitor? Are you a sponsor? Are you leading a oss linux
> >audio project? are you contributing to such projects?
> >
> >
> >
>
> i'm a performer, composer, singer,
That means that you're a Linux Audio User.
> and a leading lobbyist for Free
> Software
Isn't Richard Stallman a leading lobbyist?
> and for the use of Free licensing in music. i'm also part of
> iCommons - the project to port Creative Commons to compatibility with EU
> law. check out www.copyleftmedia.org.uk.
The term 'copyleft' definitely isn't compatible with EU law, whether
it's copyright law or any other part of intellectual property law.
> i'll be there demonstrating
> live vocal improvisation with plugins, and portable setups for live
> improvisation, working alongside Steve and Daniel.
That means you and Daniel are going to help out the Linux Audio
Developers on that stand.
How is Sounds Expo different from ZKM or LinuxTag? *What* *exactly* are
we trying to promote? Shouldn't we all promote and protect the things we
value the most - oss linux audio projects? Are private mailing lists and
sudden consortiums the way it's done?
Marek
On Sun, 2004-01-18 at 12:27, iriXx wrote:
> Marek Peteraj wrote:
>
> >On Sun, 2004-01-18 at 03:22, iriXx wrote:
> >
> >
> >>> It should become another LAD event where the linux audio developers
> >>> present their work(such as ZKM LAD conference, LinuxTag LAD booth).
> >>>
> >>> comments?
> >>>
> >>> Marek
> >>>
> >>>
> >>yes.
> >>there are people /other/ than linux audio developers who will be on the
> >>stand at Sounds Expo. its not just an audio development forum.
> >>
> >>
> >
> >such as?
> >
> >
>
> myself.
Cool. Are you a visitor? Are you a sponsor? Are you leading a oss linux
audio project? are you contributing to such projects?
>
> >
> >
> >>> I propose the following - on sounds expo we should promote LAD and
> >>> oss, linux audio projects such as:
> >>>
> >>> (in no particular order)
> >>>
> >>> *Ardour *ALSA *Jack *JAMin *LADSPA+swh-plugins *LinuxSampler
> >>> *Lilypond etc
> >>>
> >>> Linux audio distros such as AGNULA, dyne:bolic etc
> >>>
> >>>
> >>i believe Daniel is planning the event....
> >>
> >>
> >
> >So then let him speak for himself.
> >
> >
>
> why are you replying offlist?
I'm not. I accidentally hit 'reply to all' - that's why you got a cc.
Marek