For my college final project, I'm embarking on a very similar idea. My
project advisor has me implementing a wavelet transform in python, and
displaying a waterfall in tcl/tk. GRanted, I've never programmed in either
language; I'm not even sure either of those are efficient enough to
handle it
michael tewner wrote:
For my college final project, I'm embarking on a very similar idea. My
project advisor has me implementing a wavelet transform in python, and
displaying a waterfall in tcl/tk. GRanted, I've never programmed in either
language; I'm not even sure either of those are efficient
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
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
Quoting Steve Harris [EMAIL PROTECTED]:
I disagree, its not the wrong model - the master node (with the audio i/o)
run a normal jack driver, and all the slave nodes run a network jack
driver that read/writes from the network.
Yes, I believe this is the way to do it. Has anybody played with
Quoting Dave Robillard [EMAIL PROTECTED]:
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
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
Quoting Paul Davis [EMAIL PROTECTED]:
wrong model. a given jackd has a single driver. a new jack client,
sure.
I believe the way to do this is to have one remote jackd with a driver
that sends/receives data through UDP and one local jack client that
interacts with this remote server.
There
Hi,
Have you ever wondered if it is possible to escape the limits imposed
by your cpu to the number of ladspa plugins you can run simultaneously,
while keeping latency low? Well, yes, there is.
This email is to let you know about DLADSPA (Distributed LADSPA). While
there are a few rough edges on
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:
- the system needs every period to be the same size (unless you are not
running in real-time or the remote load is *very* low, but then what
is the point?).
thats potentially a bit ugly, but in practice, its probably going to
work, especially with JACK-driven clients/hosts.
- The system
On Tuesday 17 August 2004 08:19 pm, Dave Robillard wrote:
On Tue, 2004-08-17 at 16:50, John Check wrote:
On Tuesday 17 August 2004 12:53 pm, Ralf Beck wrote:
Am Dienstag, 17. August 2004 01:47 schrieb Lee Revell:
On Mon, 2004-08-16 at 19:24, Dan Hollis wrote:
On Mon, 16 Aug 2004,
On Aug 18, 2004, at 12:38 PM,
[EMAIL PROTECTED] wrote:
-- 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.
this does seem very useful. there's no way to transport
Am Mittwoch, 18. August 2004 19:36 schrieb Nelson Posse Lago:
Quoting Paul Davis [EMAIL PROTECTED]:
wrong model. a given jackd has a single driver. a new jack client,
sure.
I believe the way to do this is to have one remote jackd with a driver
that sends/receives data through UDP and one
On Tuesday 17 August 2004 06:43 pm, Paul Winkler wrote:
On Tue, Aug 17, 2004 at 05:11:35PM -0400, John Check wrote:
Heheh, I didn't think of i18n until you said it.
sure you did!
From your post:
The only text input will be for URLs. This should minimize
grammatical and language issues
On Tuesday 17 August 2004 08:13 pm, Dave Robillard wrote:
On Tue, 2004-08-17 at 17:14, John Check wrote:
group (tautological, I know, but bear with me). Both perspectives are
equally valid, and since they aren't mututally exclusive, let's be
nice to each other.
This is pretty sweet,
On Wed, Aug 18, 2004 at 02:36:10 -0300, Nelson Posse Lago wrote:
oh, and a small correction. VST System Link has basically nothing to
do with networked audio. [...] it does *not* distribute audio
across the network at all.
If I understood it correctly, yes it does, but their concept of a
Hello, I have been googleing around trying to find information on raw
pcm data. Does anybody know of any tutorials or references on raw pcm
data? I am most curious about different storage types (2s complement,
etc), and how multiple channels are stored. Thanks. -Garett
On Wed, Aug 18, 2004 at 02:41:26PM -0600, Garett Shulman wrote:
Hello, I have been googleing around trying to find information on raw
pcm data. Does anybody know of any tutorials or references on raw pcm
data? I am most curious about different storage types (2s complement,
etc), and how
Steve Harris [EMAIL PROTECTED] writes:
On Wed, Aug 18, 2004 at 02:36:10 -0300, Nelson Posse Lago wrote:
If I understood it correctly, yes it does, but their concept of a
network is somewhat weird: it allows you to send data from one
machine to the other for remote processing, but it uses
On Wed, 2004-08-18 at 21:27, John Check wrote:
Con: Sending data for each single plugins produces more overhead and
thus takes up more cpu power on the host.
Well there is Moore's law *ducks*
BZZT, wrong. This kind of thinking leads to having to upgrade every few
years just to have
21 matches
Mail list logo
