>> >Next question is who would take the initiative
>> >to spearhead this. Don't look at me. :-)
>>
>> i'll be happy to organize it if and when the time comes. its not time
>> yet. i am sure there will be some technicalities to address. tom white
>> at the mma seemed like a reasonable guy, however.
On Tue, Jan 21, 2003 at 10:31:56 -0500, Paul Davis wrote:
> >Next question is who would take the initiative
> >to spearhead this. Don't look at me. :-)
>
> i'll be happy to organize it if and when the time comes. its not time
> yet. i am sure there will be some technicalities to address. tom white
>Next question is who would take the initiative
>to spearhead this. Don't look at me. :-)
i'll be happy to organize it if and when the time comes. its not time
yet. i am sure there will be some technicalities to address. tom white
at the mma seemed like a reasonable guy, however.
--p
>> BTW, that's rather interesting, put in relation to the number of
>> Linux audio hackers as well. How many and how long does it *really*
>> take to create a complete Linux based studio solution?
>
>Bizarrely, I think we actually spend more time reinventing the wheel than
>the commercial guys. W
David Olofson wrote:
The very AU interfaces looked a *lot* like Objective C to me in the
docs, but maybe I wasn't reading carefully enough...
I'm hardly an Objective-C expert, but I'm pretty sure that it's just
Apple-flavored OO-style C.
-dgm
On Tuesday 21 January 2003 23.04, Will Benton wrote:
> On Tue, Jan 21, 2003 at 09:57:59PM +, Steve Harris wrote:
> > On Tue, Jan 21, 2003 at 10:00:13PM +0100, David Olofson wrote:
> > > As to AU, I think the use of Objective C is a serious obstacle.
> > > I also dislike the way they handle sche
On Tuesday 21 January 2003 22.57, Steve Harris wrote:
> On Tue, Jan 21, 2003 at 10:00:13PM +0100, David Olofson wrote:
> > As to AU, I think the use of Objective C is a serious obstacle. I
> > also dislike the way they handle scheduling, and the general lack
> > of consideration for API overhead...
On Tue, Jan 21, 2003 at 09:57:59PM +, Steve Harris wrote:
> On Tue, Jan 21, 2003 at 10:00:13PM +0100, David Olofson wrote:
> > As to AU, I think the use of Objective C is a serious obstacle. I
> > also dislike the way they handle scheduling, and the general lack of
> > consideration for API o
On Tue, Jan 21, 2003 at 10:00:13PM +0100, David Olofson wrote:
> As to AU, I think the use of Objective C is a serious obstacle. I
> also dislike the way they handle scheduling, and the general lack of
> consideration for API overhead... But that's another topic!
I dont know that much about AU.
On Tue, Jan 21, 2003 at 12:41:21PM -0500, Paul Davis wrote:
> the biggest issue right now is just what happens next. the MMA is
> going to sponsor a mailing list. the initial requirements gathering
> phase of the process will be open to the public, but the current
> thinking is that the design phas
On Tue, Jan 21, 2003 at 10:00:13PM +0100, David Olofson wrote:
> Well, I have slightly mixed feelings, but an MMA membership probably
> wouldn't hurt, even if this particular project fails. If nothing
> else, it might make us look slightly better in the eyes of those that
> still think "it can't
On Tuesday 21 January 2003 18.41, Paul Davis wrote:
[...]
> it was not clear whether any of these steps would be accomplished.
> ron noted that expected the whole thing to take several (1-3)
> years.
Ouch. Well, as we all know, this kind of stuff takes time - and
having all that people in the dis
>On Tue, Jan 21, 2003 at 11:24:20 -0500, Paul Davis wrote:
>> some guys from ohm force mentioned at the unified plugin api meeting
>> on sunday that they and a number of other people on the music-dsp (or
>> perhaps some other list) have written a 60 page document on proposals
>> for a plugin API. t
On Tuesday 21 January 2003 17.59, Steve Harris wrote:
> On Tue, Jan 21, 2003 at 05:20:56 +0100, David Olofson wrote:
> > Note that while this fixes the broken 0 duration case, it also
> > has the side effect that RAMP(value, 0) becomes equivalent to
> > SET(value). So, you don't really need to use
On Tuesday 21 January 2003 17.24, Paul Davis wrote:
> some guys from ohm force mentioned at the unified plugin api
> meeting on sunday that they and a number of other people on the
> music-dsp (or perhaps some other list) have written a 60 page
> document on proposals for a plugin API. they left th
On Tue, Jan 21, 2003 at 11:24:20 -0500, Paul Davis wrote:
> some guys from ohm force mentioned at the unified plugin api meeting
> on sunday that they and a number of other people on the music-dsp (or
> perhaps some other list) have written a 60 page document on proposals
> for a plugin API. they l
On Tue, Jan 21, 2003 at 05:20:56 +0100, David Olofson wrote:
> Note that while this fixes the broken 0 duration case, it also has
> the side effect that RAMP(value, 0) becomes equivalent to SET(value).
> So, you don't really need to use the SET event explicitly at all.
Not quite, RAMP(new_val, 0
On Tuesday 21 January 2003 10.19, Steve Harris wrote:
[...]
> > Another idea:
> > Since we need that (duration == 0) test anyway, why not have it
> > explicitly stop ramping as well, so we can connect non-ramped
> > outputs to ramped inputs and vice versa?
>
> I'd say that has different semantics,
some guys from ohm force mentioned at the unified plugin api meeting
on sunday that they and a number of other people on the music-dsp (or
perhaps some other list) have written a 60 page document on proposals
for a plugin API. they left the meeting before i could get a url (they
had a copy with the
On Tuesday 21 January 2003 10.18, Steve Harris wrote:
> On Tue, Jan 21, 2003 at 05:09:34 +0100, David Olofson wrote:
> > For example, setting the initial level of an envelope and then
> > setting up the delay or attack phase won't work, unless you wait
> > for one frame before sending the RAMP even
On Tue, Jan 21, 2003 at 06:17:40 +0100, David Olofson wrote:
> On Tuesday 21 January 2003 05.09, David Olofson wrote:
> > So, it seems like we'll need that 0 test anyway. It should
> > obviously apply the target value instantly, so that later events
> > will work even if they land at the same times
On Tue, Jan 21, 2003 at 05:09:34 +0100, David Olofson wrote:
> For example, setting the initial level of an envelope and then
> setting up the delay or attack phase won't work, unless you wait for
> one frame before sending the RAMP event for the delay or attack
> phase. Similarly, an attack dur
On Tuesday 21 January 2003 05.09, David Olofson wrote:
> So, it seems like we'll need that 0 test anyway. It should
> obviously apply the target value instantly, so that later events
> will work even if they land at the same timestamp. It doesn't have
> to set the delta at all, as sending a 0 durat
On Tuesday 21 January 2003 00.41, David Olofson wrote:
[...]
> > > So, alternative 1; RAMP events only:
[...]
> > No branch is needed,
>
> Excellent! :-)
I just realized something that might be worth pointing out.
If you send multiple RAMP events for the same control at the same
timestamp, only
On Monday 20 January 2003 18.59, Steve Harris wrote:
> On Mon, Jan 20, 2003 at 06:08:48 +0100, David Olofson wrote:
> > > but the cases I can think of it wont hurt:
> > >
> > > notched switches: will always jump to the target value anyway,
> > > so wont have to do any interpolation.
> >
> > RAMP is
On Mon, Jan 20, 2003 at 06:08:48 +0100, David Olofson wrote:
> > but the cases I can think of it wont hurt:
> >
> > notched switches: will always jump to the target value anyway, so
> > wont have to do any interpolation.
>
> RAMP is always interpreted as SET? Not the best way to fake ramping,
> b
On Monday 20 January 2003 16.15, Steve Harris wrote:
> On Mon, Jan 20, 2003 at 04:13:17 +0100, David Olofson wrote:
> > 5) A more serious issue is that if control events are not
> >allowed while ramping, except at the time of the aim
> >point, there is no way to avoid sending on
On Mon, Jan 20, 2003 at 04:13:17 +0100, David Olofson wrote:
> 5) A more serious issue is that if control events are not
> allowed while ramping, except at the time of the aim
> point, there is no way to avoid sending one RAMP event
> for each block while ramping. Y
I realized a few more things about ramping when messing with
Audiality's voice mixers:
1) The STOP event *is* rather handy, as it has no value
argument to be calculated or processed. If you're doing
internal ramping (or coefficients) instead of using the
29 matches
Mail list logo
