The SooperLooper LADSPA plugin now comes with PD patches!
For those that might not remember, SooperLooper is a LADSPA plugin that
emulates the Gibson-Oberheim Echoplex Digital Pro looping sampler. Go get
more info and download it at its new address:
http://essej.net/sooperlooper/
See the
To my own surprise I have to object to the suggestion: /*
AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled
by a high time res. slider or control data, but shouldn't be connected to
the next audio signal by default. I can't think of any simple examples off
hand, but c
>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
Hi all,
Just to share the good news that Linux got some exposure in the latest
edition of the Organised Sound journal (pub. by UK's Cambridge
Journals).
Stuff covered is RTMix, as well as JACK/Linux audio. Big thanks go to
Paul Davis for the help with the benchmark info, as well as everyone
else
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 Fri, Jan 17, 2003 at 11:07:40AM +0100, Vincent Touquet wrote:
>> > Check this out:
>> >
>> > - http://www.opnlabs.com/
>> > - http://www.opnlabs.com/ekochart.php
>> > [comes with XP or LINUX !]
>>
>> HOLY CRAP
>>
>> --
>
>OMG! Where can one buy one? Couldn't find anything on the s
>k_jack is a jack reimplementation
why? given that we have not even finished the initial implementation, why?
--p
Just in case no-one else has noticed, the UK number one magazine for
professional/semi-professional/serious-amateur sound engineers has
carried a long article in their Febrary 2003 issue about using Linux
for audio and production. They cover (with links): AGNULA, Ardour,
Audacity, LADSPA, CCRMA, R
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
26 matches
Mail list logo
