This whole thing is shady as hell. You can't copyright a user interface.
We've been through that already (see
http://lpf.ai.mit.edu/Copyright/copyright.html). You can copyright
specific graphics, but Reborn only looks similar to that other program.
In fact, there are explicit facilities for making
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 -- especi
On Wed, 14 Aug 2002 18:35:20 -0400 (EDT)
Taybin Rutkin <[EMAIL PROTECTED]> wrote:
> On Wed, 14 Aug 2002, n++k wrote:
>
> > |>What? It's a shame he won't fight this. INAL, but isn't the
> > |user>interface non-copyrightable?
> > |
> > |well i guess his next version will be even better :)
> >
>
I wrote a little truncating gate as a Ladspa plugin for my own use that
is designed to function somewhat like ecasound's -gc: gate, but with the
ability to reopen. It's quite simple, as I designed it to be fed from an
effects type noise gate plugin, so it only looks for a string of zero's
in a row
On Wed, 2002-08-14 at 23:39, [EMAIL PROTECTED] wrote:
> > i plan to remove trim mode completely, as suggested by gerard, and use
> > handles at the ends of the region(view). sx does this, and it was so
> > much easier to use than the current trim model in ardour.
>
> it appears to me that the PT
> i plan to remove trim mode completely, as suggested by gerard, and use
> handles at the ends of the region(view). sx does this, and it was so
> much easier to use than the current trim model in ardour.
it appears to me that the PT trim mode is _very_ quick (depending
on whether you have to swit
On Wed, Aug 14, 2002 at 05:16:43PM -0400, Paul Davis wrote:
> ... tempo sync a delay plugin ...
Eh? can't you just have a control port on the plugin for
tempo (a float), and apply some multiplier to that,
invert it and bingo, delay time in seconds. what am I missing?
you want it automatic? well,
On Wed, 14 Aug 2002, n++k wrote:
> |>What? It's a shame he won't fight this. INAL, but isn't the user
> |>interface non-copyrightable?
> |
> |well i guess his next version will be even better :)
>
> My first thought when i saw the screenshot was that considering it
> seems he took the origina
/wrote "Stefan Nitschke" <[EMAIL PROTECTED]> [Wed, 14 Aug 2002
20:48:21 +]
|>On Wed, 14 Aug 2002 [EMAIL PROTECTED] wrote:
|>
|> > 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
|>
|>Wh
>> in the future, it hopefully won't be necessary to do this. instead,
>> you can go and look at rosegarden, muse, ardour, ecasound etc. and ask
>> "how do they do it?"
>
>Inside 90.000 lines of code ? without doc ? , without any aparent order ?
when people like jesse chappel (who also wrote th
>On Wed, 14 Aug 2002 [EMAIL PROTECTED] wrote:
>
> > 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
>
>What? It's a shame he won't fight this. INAL, but isn't the user
>interface non-copyrig
On Wed, 14 Aug 2002 [EMAIL PROTECTED] wrote:
> 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
What? It's a shame he won't fight this. INAL, but isn't the user
interface non-copyrightable?
Ta
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
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
On Wed, Aug 14, 2002 at 04:40:38 +0200, Anders Torger wrote:
> Wouldn't it be possible to make an API where you report the latency to
> Jack, and then Jack automatically aligns all applications? There is
> probably a bunch of problems doing so, I have not given it any deeper
> thought.
That al
>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 feasibl
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?
>
>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() callba
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 PR
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 gion
> 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),
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
>> 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 ou
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 sampl
>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
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 overh
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
27 matches
Mail list logo
