On Tue, Aug 13, 2002 at 10:53:11AM +0200, Robert Jonsson wrote:
Great stuff!
thanks, and to everyone who's been involved so far, and to the rest of you
who will contribute soon ;-)
More information is available at:
http://www.metadecks.org/software/sweep/
Thanks to Pixar
On Tue, Aug 13, 2002 at 09:25:45PM +0200, Ingo Oeser wrote:
(cut)
Ok, I grasp your intent,
its a good idea.
Letting a DSP idle is not the best idea,
so if you can use it for specific computations,
that would be nice.
Could you tell me exactly what you would
do with this board and how that
Steve Harris wrote:
On Tue, Aug 13, 2002 at 12:23:28 +0200, günter geiger wrote:
Actually I think for output only applications you could get off without a
redesign. Just write your data to a buffer and wait until the process()
fetches it. This will introduce a buffer copy, but the overhead is
If I understand Paul Davis' arguments correctly, the main motivation
for the Jack design instead of the read/write approach is improved
latency.
well, its not really that by itself. r/w-designs can do just as
well. the real goal is sample synchronous execution *with* low
latency. if you allow
On Wednesday 14 August 2002 14.21, you wrote:
If I understand Paul Davis' arguments correctly, the main motivation
for the Jack design instead of the read/write approach is improved
latency.
well, its not really that by itself. r/w-designs can do just as
well. the real goal is sample
sync. this is a natural consequence to using a push model (i'm the
client, and i'll work when and for as long as i choose) as opposed
to a pull model (hey client: do this much work right now).
How does the pull model work with block-based algorithms that cannot
provide any output until it
On Wednesday 14 August 2002 15.23, you wrote:
sync. this is a natural consequence to using a push model (i'm
the client, and i'll work when and for as long as i choose) as
opposed to a pull model (hey client: do this much work right
now).
How does the pull model work with block-based
How does the pull model work with block-based algorithms that cannot
provide any output until it has read a block on the input, and thus
inherently has a lower bound on delay?
I'm considering a redesign of I/O handling in BruteFIR to add Jack
support (I/O is currently select()-based), but
On Wed, Aug 14, 2002 at 03:13:12 +0200, Anders Torger wrote:
I'm considering a redesign of I/O handling in BruteFIR to add Jack
support (I/O is currently select()-based), but since it is processes in
blocks, perhaps it is not feasible?
It makes it trickier. If the jack period size is giong
On Wed, 2002-08-14 at 13:21, Paul Davis wrote:
a pull model (hey client: do this much work right now).
Should the this much work be constant? Ie, should I be dealing with
midi events (of which there may or may be some) inside or outside the
process callback?
Bob
--
Bob Ham: [EMAIL
On Wed, 2002-08-14 at 13:21, Paul Davis wrote:
a pull model (hey client: do this much work right now).
Should the this much work be constant? Ie, should I be dealing with
midi events (of which there may or may be some) inside or outside the
process callback?
the process() callback is the
On Wednesday 14 August 2002 15.51, you wrote:
On Wed, Aug 14, 2002 at 03:13:12 +0200, Anders Torger wrote:
I'm considering a redesign of I/O handling in BruteFIR to add Jack
support (I/O is currently select()-based), but since it is
processes in blocks, perhaps it is not feasible?
It
On Wednesday 14 August 2002 15.51, you wrote:
On Wed, Aug 14, 2002 at 03:13:12 +0200, Anders Torger wrote:
I'm considering a redesign of I/O handling in BruteFIR to add Jack
support (I/O is currently select()-based), but since it is
processes in blocks, perhaps it is not feasible?
It
Maybe we should invite the author for this discussion. He probably would
be interested in finding out what other linux audio guys think about the
product.
On Tue, 13 Aug 2002, Steve Harris wrote:
That was my thought too. As we have seen before, when software is designed
with OSS in mind it
Hi
I jsut went to finally give it a try, and found out there is no more
reborn, it has been shut down.
I wish I hade downloaded when I hade the time
FT
This smells funny. Unfortunately, because the UI is infringing, I
can't distribute the source. There are so many ways around that that
it's not funny, starting with the most basic -- removing the
reborn.rma file from the distribution. I don't want to question
this fellow's motives --
16 matches
Mail list logo
