I'm pleased to announce the beta release of Rivendell v0.9.0. Rivendell is a
complete, GPLed radio broadcast automation solution, with facilities for the
acquisition, management, scheduling and playout of audio content. Further
information, screenshots and download links can be found at:
http://www.salemradiolabs.com/rivendell/
This release marks a significant milestone in the project in that Rivendell is
now feature-complete, with all functionality required for basic broadcast
operation. Some of the new features of this beta release include:
1) Binary RPM support for SuSE 9.1.
2) An automatic log generation and import utility, RDLogManager.
RDLogManager supports integration with virtually all third-party traffic and
music scheduler packages in use today.
3) Enhanced support for the JACK Audio Connection Kit, allowing reliable
operation with standard 'garden variety' sound cards using the Linux ALSA
driver.
4) Improved stability and useability in virtually all components.
Cheers!
|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Director of Broadcast Software Development |
| | Salem Radio Labs |
|-------------------------------------------------------------------------|
| All great ideas are controversial, or have been at one time. |
| -- Anonymous |
|-------------------------------------------------------------------------|
Quoting Dave Robillard <drobilla(a)connect.carleton.ca>:
> I still say networked audio belongs in jack, not a plugin.
It belongs in both:
- If you want to use the network to increase your total processing
power, you probably just want to offload some plugins to a remote
machine. Sure, you may run jack-rack remotely and send/receive
the data through a jack client locally, but this may become a
mess in some situations if you need the plugin to be run "inside"
an app. It also prevents you from using any kind of plugin
automation. Therefore, is such cases it is more interesting to
use ladspa for the distributed processing.
- OTOH, if you need something more complicated to be done remotely
(like disk I/O or running a complete instance of ardour), using
jack (as both me and Steve Harris described in other messages)
may be better.
> I guess a VST solution existing would suggest otherwise
VST System Links works on top of ASIO, not VST. Don't know about
FX-Teleport.
> I think it's a stupid idea well outside the realm of plugins (especially
> LADSPA, which shouldn't be sending things over a network)
It is a hack, but a useful one.
> your patches are going to have to be specifically
> set up to be sending crap over the network (ie they'll have to have a
> special plugin loaded, and all the audio going into that).
And why is that a problem? You just load a special plugin that appears
to be the plugin you intended. The app can't tell the difference.
> If it was Jack, everything in every app could be set up just as usual,
> and it would be sent over the network by jack, unbeknownst to the app.
In my system, everything is completely transparent to the app.
See ya,
Nelson
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
On Aug 18, 2004, at 2:15 AM, Paul Davis wrote:
> and in fact, jlc and i have done some tentative experiments with
> *live network audio* using jackd and ices w/jack support using only
> our DSL connectivity. the model that ices uses is more or less
> perfect, i think. just a client with some ports that happen to send
> audio to the rest of the world. only the user knows that, other apps
> just think its a regular client. jack doesn't care either, so everyone
> who has a different idea of how to actually connect the endpoints can
> do their own thing and everyone can coexist.
I'd really suggest considering the pros of integrating IETF tools
(SIP, RTSP, RTP) into this scheme. You could use still use jack
as your application later, but instead of engineering your own
transport layers for session management (SIP, RTSP) and media
(RTP), you'd use IETF protocols -- just like you use TCP instead of
re-inventing it for each app that needs a reliable bytestream.
We're seeing the IETF stack used this way more and more in the
commercial world -- the wireless audio servers (Apple Airport
Express, etc) use RTSP and RTP.
Good reasons to do this:
-- You may think you're trying to solve a small well-defined problem,
but if Jack is a success, people are going to extend it to work in
all sorts of domains. The IETF toolset has been stretched in lots
of ways by now -- interactive and content-streaming, unicast and
multicast, LAN and WAN, lossy and lossless networks, etc -- and
its known to adapt well. Traditional go-it-alone companies, like
Apple,
use it all over the place -- iChat AV and Quicktime both use RTP,
iChat AV uses SIP, Quicktime uses RTSP.
-- Modern live-on-stage applications use video, and RTP has a
collection of video codecs ready to go. Ditto for whatever other
sort of uncompressed or compressed media flow you need.
-- There are tools for synchronization (RTCP mappings of NTP
and RTP timestamps), tools for security (SRTP), tools for
all sorts of things someone might need to do someday.
-- The IPR situation is relatively transparent -- you can go to the
IETF
website and look at IPR filings people have made on each
protocol, and at least see the non-submarine IPR of the people
who actually developed the protocols -- you can't be a WG member
and keep submarine patents away from the IETF.
-- Most of the smart people who work on media networking in all of
its forms do not subscribe to LAD. The easiest way to tap into
their
knowledge is to use their protocols. And likewise, the smart
people
here can take their results and turn them into standards-track
IETF
working group items, and help make all media apps work better.
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
Hi,
Jackbeat 0.3.0 is available at : http://www.xung.org/jackbeat
This is a development release of my little-but-yet-flexible JACK sequencer.
Drummachine-like, shrinkable, scalable, unstable (oops... did I write that? :-)
I rewrote almost everything. This is mainly focused at providing pattern nesting
("buses", somehow), better IPC implementation, and an elegant song file
format based on xml and tar, as discussed in here, on LAD.
In the above statement, please do not miss "focused"... that is : the TODO
file in another major feature of this release.
--
og
"Make music, not war" -- me, today.
Hello, I would like to do a fft on an mp3 in python. I beleive I have
all of the fft stuff straight in my mind but am not sure of the best way
to get the sample data into a python array. I ran accross a web site a
while back which suggested using sox to convert a wav file into a raw
sample file and then open the raw file with python. However, I did not
bookmark this site when I came accross it and cannot seem to find it
now. If anyone has any suggestions as to a good way to get sample data
out of an mp3 and into a python array for an fft I would greatly
appreciate your suggestions. Thanks a lot. -Garett
Download from http://www.notam02.no/arkiv/src/snd/
Screenshot: http://www.notam02.no/arkiv/src/snd/snd-ls-0.9.1.png
Snd-ls v0.9.1
-------------
Released 17.8.2004
Contains
--------
Snd v7.6 from 2.8.2004
About
-----
Snd-ls is a distribution of the sound editor Snd. Its target is
people that don't know scheme very well, and don't want
to spend too much time configuring Snd. It can also serve
as a quick introduction to Snd and how it can be set up.
Install
-------
1. Edit the file config.scm, for configuration settings.
2. Run ./build
3. Run ./install as root.
Its not necessarry to uninstall any previously installed versions of
Snd. Snd-ls should not interfere with already installed versions.
After installing, the name of the executable is "snd-ls".
To uninstall, run ./uninstall
Required packages
-----------------
guile
gtk-2
jack
libsamplerate
ladspa
liblrdf
fftw3
(guile-devel, gtk-2-devel and liblrdf-devel is also needed at runtime)
Changes
-------
0.9.0 -> 0.9.1:
-Official announced.
-Upgraded SND from 20.7.2004 to 2.8.2004
-Huge amount of testing at Notam by 14 unexperienced guinea pigs for
a whole week; many bugs fixed.
Links
-----
Snd: http://ccrma.stanford.edu/software/snd/
Guile: http://www.gnu.org/software/guile/guile.html
Credits
-------
Snd is made by Bill Schottstaedt. This small package is put
together by Kjetil Matheussen / Notam, with consulting
help from Bill Schottstaedt.
--
Once again, I'm cross posting this to the users list in case anybody
is interested in fooling around with the demo apps.
I'm pleased to announce the release of PHAT, the Phat Audio Toolkit,
version 0.2.0. PHAT is a collection of GTK+ widgets that may prove
useful to audio applications.
New to this release is a shameless ripoff of Blender's "sliderbutton"
widgets. I like 'em more than regular GtkSpinButtons. Also, there
have been sundry improvements to the fansliders, and all widgets are
now mousewheelable and focusable, and they respond to sensitivity
changes (i.e. they're well behaved).
After installing, you'll have two demo apps at your disposal:
phatsliderbutton
phatfanslider
(A few) more details are available at www.gazuga.net/phat.php
Enjoy.
--
Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
TAP-plugins 0.7.0 released.
Homepage: http://tap-plugins.sf.net
Reminder: the docs are in a separately downloadable package, get it
from the same place!
New plugins (as always, check the docs for detailed usage info):
* TAP Chorus/Flanger
An implementation capable of creating traditional Chorus and Flanger
effects, spiced up a bit to make use of stereo processing. It sounds
best on guitar and synth tracks.
* TAP Sigmoid Booster
This plugin applies a time-invariant nonlinear amplitude transfer
function to the signal. Depending on the signal and the plugin
settings, various related effects (compression, soft limiting,
emulation of tape saturation, mild distortion) can be achieved.
* TAP TubeWarmth
Adds the character of vacuum tube amplification to your audio tracks
by emulating the sonically desirable nonlinear characteristics of
triodes. In addition, this plugin also supports emulating analog
tape saturation.
Fixes:
* Caught denormal problem causing large CPU peaks in TAP Stereo Echo.
Hopefully there are no more infected plugins in my collection; I
carefully inspected all feedback loops in all plugins. But that
don't mean a thing; please do not hesitate to complain if you still
experience such bad behaviour in any plugin.
Hope you enjoy this release. Please report any problems.
Tom
At Mon, 16 Aug 2004 10:47:53 +0200,
Wolfgang Woehl wrote:
>
> Hi Pete, make stumbles over
>
> phatsliderbutton.c: In function `phat_slider_button_init':
> phatsliderbutton.c:638: warning: implicit declaration of function
> `gtk_entry_set_alignment'
> make[2]: *** [libphat_la-phatsliderbutton.lo] Error 1
>
> Is that my box or is it phat?
Theoretically your box, specifically your GTK+ version. That function
is defined in GTK+-2.0, but it might not have been introduced until
the recent 2.4 release, and you might be running the more popular 2.2.
This isn't noted in the developer docs, so I'm not sure. I'll verify
this later today by seeing if I can compile on Fedora Core 1, which is
2.2 based.
--
Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
The current top Ethernet standard specifies max transmission speed of
10GBit/sec - 1394b is 800MBit/sec.
You can also run Ethernet over Firewire. IIRC the max. number of
devices on a 1394 chain is 63 making Ethernet more suitable for large
clusters of interconnected MIDI workstations.
But to an extent arguing over which PHY layer is like a Vi / Emacs
flamewar.
[plug]
For a working example of a MIDI over Ethernet (and UDP) have a look at
IEEE P1639 (was called DMIDI):
www.plus24.com/ieeep1639
This acts as a bridge between ALSA and the network so all MIDI apps can
bounce MIDI data between remote machines without any code changes.
I'm also working on an embedded Linux for clustering audio workstations,
Live CD available (USB mouse support broken just for now, PS/2 OK):
www/plus24.com/m-dist
This is also a call for participation in the final development of the
standard as well as application development.
Regards
Phil
On Sunday, August 15, 2004, at 09:36 am, Steve Harris wrote:
But if youre going to do that, why use ethernet? You'd need dedicated
NICs
and switches, so you may as well use firewire, which has dedicated
realtime channels, more bandwidth and doesnt require switching. 400meg
Firewire cards are down to about 7 or 8 euros in the UK now.
The only disadvantage is that you can't (right now) cheaply run firewire
over long distances, but taht will change once firewire over CAT5 cards
come down in price, and this is rarely an issue with clusters anyway.
