Hi,
One of the things that I came away from the meeting in Germany with was
a sense that the LASH protocol used for client<->server communication
needed to be better defined, both on the wire and in the api. What is
really necessary is a network protocol and api designed to allow
high-level ideas like sessions to be represented in a simple format.
The properties that I had been working on have become gobjects and what
was to be a new networking system is a seperate, gobject-based library
to provide a high-level networking api (eg, session_scan(),
session_join(), etc)
The TLA OSC has been banded about quite a bit, and this is not out of
the question; it would be in a set of usable lower-level protocols (or
perhaps the set :)
Bob
--
Bob Ham <rah(a)bash.sh>
/-\
\ / Gay Whales
X Against Racism
/ \
Hello,
An updated version (1.0.1) of libclalsadrv is now available on
<http://users.skynet.be/solaris/linuxaudio>
Changes w.r.t. 1.0.0:
snd_pcm_prepare() is no longer called when the alsa device is
started, only when it is restarted after an xrun. This seems
to solve some problems with 2.6 kernels. Thanks to Matthias
Nagorni and Takashi Iwai for finding this out.
--
FA
Thorsten Wilms:
>
> Additions to the Announcement:
>
> Holding down ctrl freezes the precision axis, so
> only the value can be changed.
>
> Holding down shift freezes the value axis, so
> that you can scale the fan up without worying
> about unintended value change.
>
>
> There will be a context menu with copy, paste,
> (reset to) default, center, previous value
> (like undo).
>
>
> Sine the standard middle click action will not
> work that good with sliders, we thought about
> using it for reset to default or center. But
> we would like to see some standardization here,
> so what other actions are assigned to middle
> click in other (linux) audio apps, and what
> does everybody think about this?
>
I don't think you should use the middle button for anyting.
With scroll-button mouses (which everyone should use), the
middle button is very unconfortable. What about
some creative use of the scroll-wheel instead? The obvious
use is of course to change the value with the scroll-wheele.
I think that would be nice.
>
> There have been some drawing errors happening
> when moving the fan out to one side and then
> the other in one go. But they are actualy hard
> to trigger, so please stress test the demo and
> report to Pete, so we might find out where the
> problem lies.
>
I can't trigger that, but the flickering is annoying.
How about double-buffering the thing?
Another thing, in some situations, I think I would prefer
that the fan is always at maximum size. Could that be
made as an option in the API?
Besides from that, very very nice! I'm thinking about using
it in my configuration code for SND. But the flickering
needs to be fixed.
--
I'm pleased to annouce, after a solid month of heated debate with X11,
the initial public release of PHAT, the PHat Audio Toolkit. From the
website (www.gazuga.net/phat.php):
"PHAT is a collection of GTK+ widgets geared toward pro-audio
apps. The goal is to eliminate duplication of effort and provide some
standardization (well, at least for GTK+ apps). It's open source
software, licensed under the GNU GPL, version 2.0 or later."
The debut and flagship widget is the fanslider, designed by Thorsten
Wilm's. The LAU folks may not be too interested in the library as
such, but might like to play around with this widget (hence the cross
post). It comes with a demo program, "phatfantest," which displays
the sliders in all their glory.
Tarball: www.gazuga.net/phat-0.1.0.tar.gz
Docs: www.gazuga.net/phat/index.html
Let's actually go somewhere with all this debate about widgets and
standards and such. Contributions are welcome (hint hint). I hope we
can put an end to the Linux Usability Curse, at least in our own
little neck of the woods.
--
Pete
www.gazuga.net
=====================================================================
"I saw the movie 'I, Robot' recently, a film based loosely on a book
written by science fiction author Isaac Asimov. In case you're not
familiar with Asimov's writing, here's a list of things the movie had
in common with the book:
* The title."
[maddox.xmission.com]
=====================================================================
Sounds neat. Are there any screenshots?
Taybin
-----Original Message-----
From: Pete Bessman <ninjadroid(a)gazuga.net>
Sent: Jul 31, 2004 9:39 PM
To: linux-audio-user(a)music.columbia.edu, linux-audio-dev(a)music.columbia.edu
Subject: [linux-audio-dev] [ANN] PHAT version 0.1.0
I'm pleased to annouce, after a solid month of heated debate with X11,
the initial public release of PHAT, the PHat Audio Toolkit. From the
website (www.gazuga.net/phat.php):
"PHAT is a collection of GTK+ widgets geared toward pro-audio
apps. The goal is to eliminate duplication of effort and provide some
standardization (well, at least for GTK+ apps). It's open source
software, licensed under the GNU GPL, version 2.0 or later."
The debut and flagship widget is the fanslider, designed by Thorsten
Wilm's. The LAU folks may not be too interested in the library as
such, but might like to play around with this widget (hence the cross
post). It comes with a demo program, "phatfantest," which displays
the sliders in all their glory.
Tarball: www.gazuga.net/phat-0.1.0.tar.gz
Docs: www.gazuga.net/phat/index.html
Let's actually go somewhere with all this debate about widgets and
standards and such. Contributions are welcome (hint hint). I hope we
can put an end to the Linux Usability Curse, at least in our own
little neck of the woods.
--
Pete
www.gazuga.net
=====================================================================
"I saw the movie 'I, Robot' recently, a film based loosely on a book
written by science fiction author Isaac Asimov. In case you're not
familiar with Asimov's writing, here's a list of things the movie had
in common with the book:
* The title."
[maddox.xmission.com]
=====================================================================
ROSEGARDEN GOES BETA! - 0.9.9 RELEASED
The Rosegarden team are delighted to announce the 0.9.9 release of
Rosegarden 4, an audio and MIDI sequencer and musical notation editor
for Linux.
http://www.rosegardenmusic.com/
This release is feature complete for 1.0 and marks the start of
official beta testing.
Rosegarden is one of the most comprehensive Linux music software
projects, and is the only Linux application to offer full composition
and recording capabilities to musicians who prefer to use classical
notation. We encourage anyone who may be interested in using the 1.0
release to try out 0.9.9 and provide bug reports and other feedback
via the mailing lists and bug trackers.
http://www.rosegardenmusic.com/getting/http://www.rosegardenmusic.com/support/
New features of the 0.9.9 release include:
o Plugin synth support using the DSSI system (http://dssi.sf.net/).
Rosegarden now comes with integrated sample-synchronous synth
support, with LADSPA effects and mixer routing for synth tracks,
and configuration both through the built-in plugin GUI and plugins'
own native GUIs.
o Triggered segments for pattern sequencing & performable ornaments
o New menu layout, many new keyboard shortcuts for everyday usability
o Recording from multiple MIDI sources
o Cautionary accidentals and configurable key-signature cancellations
o Pedal marks, mordents, trill lines, repeat bars
o Fine positioning and visibility control of notation elements
o Visual metronome
o Several new example files
Other features of interest include:
o Piano-roll, score, event list and track overview editors
o MIDI and audio playback and recording with ALSA and JACK
o JACK transport support for synchronisation with other software
o Ability to build and run without JACK support for MIDI-only use
o Audio plugin support using LADSPA
o Score interpretation of performance MIDI data
o MIDI and Hydrogen file import
o MIDI, Csound, Lilypond and MusicXML file export
o Clear, consistent and polished user interface
o Shareable device (.rgd) files to ease MIDI portability
o User interface in Russian, Spanish, German, French, Welsh,
Italian, Swedish and Estonian, as well as UK and US English.
Rosegarden is Free Software under the GNU General Public License.
Chris
ladspar is a Ruby module for using LADSPA plugins. Here's a short
example:
---
require 'ladspa'
require 'narray'
# load the CMT library
cmt = LADSPA.load_library('cmt')
# get an instance of the amp_mono plugin
amp_mono = cmt.plugins.find {|p| p.label == 'amp_mono'}.instantiate(44100)
# The ports are Gain, Input, and Output.
amp_mono.ports[0].connect_port(1.5) # gain
input = NArray.sfloat(44100)
amp_mono.ports[1].connect_port(input)
output = NArray.sfloat(44100)
amp_mono.ports[2].connect_port(output)
amp_mono.activate if amp_mono.has_activate
# prep the input data ...
amp_mono.run
amp_mono.deactivate if amp_mono.has_deactivate
amp_mono.cleanup
---
This is the first release of ladspar; I consider it beta quality. I have
put it through its paces (more test code than swig code), but I am the
only one to have tested it. Nevertheless I think it is usable, and I am
eager to fix any bugs you may find.
Go grab it at http://rubyforge.org/projects/ladspar
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
>From: Dave Robillard <drobilla(a)connect.carleton.ca>
>
>The question is, which implementation is best? All I can find is
>Steve's liblo, libosc++, and the 'official' OSC kit. What are the
>advantages/drawbacks of each? I can find very little information on any
>of them.
Last I checked OSC, it had Lisp/Scheme like syntax. Don't know
if that is a drawback --- anyone?
Has anyone used MPI (Message Passing Interface) for this?
People use these for high performance parallel computations
in Linux clusters. MPI itself is a standard supported by academic
and by vendors. MPI is used, e.g., in supercomputers.
See, e.g.,
http://www.csc.fi/reports/pc-cluster/Finalreport.pdf
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
This bit ardour a little while ago when one plugin author changed the number or ordering of their ports without changing the ID number.
Taybin
-----Original Message-----
From: Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>
Sent: Jul 29, 2004 4:00 AM
To:
The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu>
Subject: Re: [linux-audio-dev] LADSPA "Unique" IDs
On Thu, Jul 29, 2004 at 09:17:03AM +0100, Chris Cannam wrote:
> On Thursday 29 Jul 2004 12:42 am, Dave Robillard wrote:
> > I vaguely remember a discussion here about LADSPA ID's (unsigned
> > long UniqueID) not actually being globally unique to a plugin like
> > the header implies, but I can't find it in the archives.
> >
> > So.. unique or not? Basically I need to know what the "proper"
> > information is to send a synth in order to load a plugin.
>
> The outcome was that (i) LADSPA _does_ appear to specify that the
> unique ID should be globally unique, but (ii) it's not in practice
> easy to guarantee that, for generated or wrapper plugins (e.g. a vst
> wrapper that doesn't know how many plugins will be in the .so until
> it's counted your VSTs), and (iii) some plugin developers (Steve!)
> thought the LADSPA docs said differently anyway, so it's possible
> they may have made plugins with duplicate IDs.
Personally I've only done that by accident! But it has happened. My buil
process now has a bozosity checker run, that looks for silly mistakes,
like two plugins with the same ID. I do learn eventually :)
> /* This identifier can be used as a unique, case-sensitive
> identifier for the plugin type within the plugin file. Plugin
> types should be identified by file and label rather than by index
> or plugin name, which may be changed in new plugin
> versions. Labels must not contain white-space characters. */
>
> To me this makes it pretty plain that filename and label is at least
> intended to be a valid unique ID within your filesystem, and in
> practice I'd expect it to be an effective id for the plugin anywhere
> in the world.
I think it should be: local filenames are unique, and labels are
required to be unique in the file.
A problems with using UIDs for this kind of thing is that they dont have
to change with plugin versions, so you can end up with two plugins iwth
the same ID and ports, but different paths nad different effects/bugs, and
you dont know which one to load.
> One problem is that there seems to be an informal understanding that
> if you change the port specifications for a plugin you should also
> change its unique ID, but I don't think there's any such
> understanding for labels, so you don't have the reassurance of
> knowing you're using the version you actually intended.
All this and more :)
- Steve