On Wed, Aug 18 2004 at 03:22:23pm -0400, Paul Davis wrote:
thats potentially a bit ugly, but in practice, its probably going to
work, especially with JACK-driven clients/hosts.
That's the idea; in fact, this was mostly triggered by the but it's
native processing! text on ardour's site.
does
On Wed, Aug 18 2004 at 04:40:04pm -0400, John Check wrote:
FWIW, I have Deb stable on my gateway, and it wouldn't build out of the box. I
haven't tried with the fixes I had a chance to apply (deprecated headers
mostly), but since the remaining showstopper is a gcc3 issue on my desktop, I
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
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
Quoting John Check [EMAIL PROTECTED]:
Google Nelson Posse Lago. He stopped posting to this list about 02.. I was
wondering if he got hit by a bus or something, but apparently not.
I'm alive
And the world shines for me today... (ELO)
Sorry, I haven't been able to keep up with the list, much
On Tue, Nov 12 2002 at 10:17:01am -0500, Paul Davis wrote:
i've read the patent.
its innovation comes from applying a pre-existing technique
(read-ahead buffering) to a new software niche. the basic idea of i
have this data on disk and i can't read it fast enough when i really
need to, so i
Replying to myself...
On Thu, Dec 12 2002 at 03:27:17pm -0200, Nelson Posse Lago wrote:
How about a (possibly diskless) computer-based sampler that takes it
samples from a network server?
Another idea: we don't prefetch, we just load everything into RAM up to a
maximum value (32Mb
On Thu, Jul 04 2002 at 03:42:11am +0100, Bob Ham wrote:
On Thu, 2002-07-04 at 03:21, Dan Hollis wrote:
Do you have a magic-enabled guitar or mixer or effects box or synth?
No. That does kind of take away my argument, really :) But then I'm
not sure why I'm having to justify myself on
On Thu, Jun 13 2002 at 11:55:11am +0200, Men Muheim wrote:
http://magic.gibson.com/
Looks interesting. Thanks for the info.
[...]
The discussion here should not be about the network but about an audio
API which is independent of the underlying network stack.
[...]
I think the first thing
On Tue, Jan 22 2002 at 10:12:20am -0500, Richard C. Burnett wrote:
I also wanted to point out for those who are not aware, be very weary of
the VIA chipset on many AMD motherboards. Apparently there are some
communication issues between the north and south bridge chips and it
causes quite
Hope I don't say anything stupid here :-)
On Mon, Dec 03 2001 at 10:01:08am +, Steve Harris wrote:
I'm not sure what the semantics of /usr/share/ladspa... v's
/usr/local/share/ladspa... are. Wouldn't it just be wether the the plugins
where vendor supplied or 3rd party?
The way I
On Sat, Nov 17 2001 at 06:31:11pm +0100, Robert Jonsson wrote:
Here are some implementation ideas I conjured from thin air a while a go
(perhaps that's all they contain), hope someone finds it interesting.
And in case it's not patented yet(in case someone would WANT to patent
it, go
On Wed, Nov 14 2001 at 10:49:39am -0500, Andy Wingo wrote:
[...] if data is read the callback is called, with a straight-up
function call. so no jumps are used in that sense.
But the point is that data is read/written at every tick, which means
every jack client must be run inside every tick;
On Wed, Nov 14 2001 at 08:28:54am -0500, Karl MacMillan wrote:
[...] Supporting basic music notation is fairly straightforward, but
providing all of the functionality to support complex, modern notation is
difficult. See Guido for a format that does a good job at the harder parts
of notation
Hi,
After reading *a lot* of the list archives and finding out that on the
LAAGA draft documentation, the exact information I wanted is marked as to
be written :-( , I decided to come to the mailing-list for help.
I'm trying to understand how JACK minimizes the number of context switches
when
On Sun, Oct 28 2001 at 12:44:15pm -0500, Paul Davis wrote:
Frankly, no. Once again, there are two different levels of operation:
working with specific samples, and working in an audio sequencer.
[...]
Compare these issues with the relatively simple task of taking the
code to an existing
18 matches
Mail list logo
