What's going on with headers, docs, names and stuff?
I've ripped the event system and the FX API (the one with the state()
callback) from Audiality, and I'm shaping it up into my own XAP
proposal. There are headers for plugins and hosts, as well as the
beginnings of a host SDK lib. It's mostl
Well, this might be early, but I needed to do something slightly less
demanding for a while. So I hacked a small presentation:
http://olofson.net/xap/
Please, check facts and language (not my native tongue), and suggest
changes or additions.
(Oops! Clicked on dat doggy-like animal i
On Thursday 12 December 2002 03.10, David Gerard Matthews wrote:
> David Olofson wrote:
> >That's not rude - I don't think anyone is *totally* sure about
> > this...
> >
> >Though, you might want to note (pun not intended) that I'm really
> >talking about "continous pitch" - not note numbers, as in
David Olofson wrote:
That's not rude - I don't think anyone is *totally* sure about this...
Though, you might want to note (pun not intended) that I'm really
talking about "continous pitch" - not note numbers, as in "integer,
MIDI style". You could think of the relation as
linear_pitch = f(n
Tim Hockin wrote:
>> i'm becoming tired of discussing this matter. fine by me if
>> you can live with a plugin system that goes only half the way
>> towards usable event handling.
>
>I haven't been following this issue too closely, rather waiting for some
>decision. I have been busy incorporat
On Wednesday 11 December 2002 23.56, David Gerard Matthews wrote:
[...]
> >The need for 1.0/note or similar arrise when you want to work with
> >something like 12t without deciding on the exact tuning, and also
> >when you want to write "simple" event processor plugins that think
> > it terms of no
I (still) don't think musical time belongs in timestamps of your
average event in XAP. Those events are meant to act as an alternative
to audio rate controls or blockless processing. The host gives you a
time frame to work with (expressed as a number of audio frames), and
that's the timeframe
David Olofson wrote:
On Wednesday 11 December 2002 13.59, David Gerard Matthews wrote:
Steve Harris wrote:
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though.
Personally I'd leave scales out of the API and let the host deal
On Wednesday 11 December 2002 23.12, Tim Hockin wrote:
> > i'm becoming tired of discussing this matter. fine by me if
> > you can live with a plugin system that goes only half the way
> > towards usable event handling.
>
> I haven't been following this issue too closely, rather waiting for
> some
> i'm becoming tired of discussing this matter. fine by me if
> you can live with a plugin system that goes only half the way
> towards usable event handling.
I haven't been following this issue too closely, rather waiting for some
decision. I have been busy incorporating other ideas. What do
On Sun, 2002-12-08 at 16:14, Kai Vehmanen wrote:
> On Sun, 8 Dec 2002, Paul Davis wrote:
>
> > you also haven't addressed kernel scheduling issues; the context
> > switch doesn't happen till the kernel has decided what task is going
> > to run next. if it picks the wrong one, for whatever reason,
On Wednesday 11 December 2002 22.26, Tim Goetze wrote:
> David Olofson wrote:
> >> so eventually, you'll need a different event system for
> >> plugins that care about musical time.
> >
> >No. You'll need a different event system for plugins that want to
> >look at future events.
>
> which is an ad
David Olofson wrote:
>> so eventually, you'll need a different event system for
>> plugins that care about musical time.
>
>No. You'll need a different event system for plugins that want to
>look at future events.
which is an added level of complexity, barring a lot of ways
to head for plugins.
On Wednesday 11 December 2002 21.50, Steve Harris wrote:
> On Wed, Dec 11, 2002 at 06:49:17 +, Nathaniel Virgo wrote:
> > Sorry, I just tend to hit "reply to all" because some lists seem
> > to be set up so that "reply" doesn't go to the list.
>
> See if your mail client has a reply-to-list dea
On Wednesday 11 December 2002 21.00, Tim Hockin wrote:
> > > i'm convinced it's better to design one system that works
> > > for event-only as well as audio-only plugins and allows for
> > > the mixed case, too. everything else is an arbitrary
> > > limitation of the system's capabilities.
> >
> >
On Wednesday 11 December 2002 20.25, Sami P Perttu wrote:
[...]
> > That sounds a lot like a specialized event system, actually. You
> > have structured data - and that is essentially what events are
> > about.
>
> Hmm, that's one way of looking at it. I had thought of the subblock
> aspect as some
On Wed, Dec 11, 2002 at 06:49:17 +, Nathaniel Virgo wrote:
> Sorry, I just tend to hit "reply to all" because some lists seem to be set up
> so that "reply" doesn't go to the list.
See if your mail client has a reply-to-list deature, mutt does
(+L).
> > I like the idea of enforced "explicit
On Wednesday 11 December 2002 19.49, Nathaniel Virgo wrote:
> On Wednesday 11 December 2002 5:19 pm, David Olofson wrote:
> > (Oops. Replied to the direct reply, rather than via the list.
> > Please, don't CC me - I'm on the list! :-)
>
> Sorry, I just tend to hit "reply to all" because some lists
On Wednesday 11 December 2002 19.42, Tim Hockin wrote:
> > delays based on musical time do, whatever you like to call
> > it.
>
> I always assumed that tempo-delays and thinsg would just ask the
> host for the musical time at the start of each buffer.
That's a hack that works ok in most cases, but
> > i'm convinced it's better to design one system that works
> > for event-only as well as audio-only plugins and allows for
> > the mixed case, too. everything else is an arbitrary
> > limitation of the system's capabilities.
>
> So, you want our real time synth + effect API to also be a full-bl
On Wednesday 11 December 2002 18.54, Tim Goetze wrote:
> David Olofson wrote:
> >On Wednesday 11 December 2002 15.25, Tim Goetze wrote:
> >> David Olofson wrote:
> >> >So, sort them and keep track of where you are. You'll have to
> >> > sort the events anyway, or the event system will break down
>
On Wednesday 11 December 2002 19.32, Tim Hockin wrote:
> > This is *exactly* why I'm proposing the use of a structured text
> > file that matches the structure of the plugin's "exported" names.
> > The *structure* is what you go by; not the actual words. A host
> > would not even have to ask the pl
On Wed, 11 Dec 2002, David Olofson wrote:
> > Well, in MONKEY I have done away with separate audio and control
> > signals - there is only one type of signal. However, each block of
> > a signal may consist of an arbitrary number of consecutive
> > subblocks. There are three types of subblocks: co
On Wednesday 11 December 2002 18.26, Steve Harris wrote:
> On Wed, Dec 11, 2002 at 04:35:16 +0100, David Olofson wrote:
> > > Maybe. My objection to converters is more that they imply two
> > > parallel representations of frequency (in the broad sense of
> > > the word), which seems like a mistake.
11/12/02 18:41, Kjetil S. Matheussen wrote:
> > This is VERY important in my worldview. Assuming the work being done on a
> > VST hack on wine, a VST wrapper plugin or a LADSPA wrapper plugin makes all
> > those bits of code available.
>
> The vst ladspa plugin just makes vst plugins appear as l
On Wed, Dec 11, 2002 at 04:31:24PM +, Bob Ham wrote:
> of ladcca will have libladcca under the LGPL license. I do still not want
> cubase if it's under proprietary license, and I do still very much fear a
> linux-audio-dev world dominated by proprietary licenses, but libladcca under
> the GPL
On Wednesday 11 December 2002 5:19 pm, David Olofson wrote:
> (Oops. Replied to the direct reply, rather than via the list. Please,
> don't CC me - I'm on the list! :-)
Sorry, I just tend to hit "reply to all" because some lists seem to be set up
so that "reply" doesn't go to the list.
> I like
> delays based on musical time do, whatever you like to call
> it.
I always assumed that tempo-delays and thinsg would just ask the host for
the musical time at the start of each buffer. With sample-accurate events,
the host can change tempo even within a buffer. If a plugin is concerned
with mus
> This is *exactly* why I'm proposing the use of a structured text file
> that matches the structure of the plugin's "exported" names. The
> *structure* is what you go by; not the actual words. A host would not
> even have to ask the plugin for the english names, but just look up
> the correspo
> > This is VERY important in my worldview. Assuming the work being done on a
> > VST hack on wine, a VST wrapper plugin or a LADSPA wrapper plugin makes all
> > those bits of code available.
>
> The vst ladspa plugin just makes vst plugins appear as ladspa plugins, so
> thats not a problem.
See
On Tue, Dec 10, 2002 at 09:25:15PM +, Nathaniel Virgo wrote:
> programs. This means that if a commercial program comes along it won't be
> able to use the library, and anyone who wanted to use that program would have
> to manually keep loads of files in sync like we do now.
Like I said b
Antti Boman schrieb:
> Antti Boman wrote:
> > Frank Barknecht wrote:
> >
> >> To wet your appetite: I really should finish my PD quicktoot, which
> >> even in its current unfinished form is longer then three standard
> >> quicktoots :(
> >
> > You wet my appetite so that I have to ask if there's
David Olofson wrote:
>On Wednesday 11 December 2002 15.25, Tim Goetze wrote:
>> David Olofson wrote:
>> >So, sort them and keep track of where you are. You'll have to sort
>> >the events anyway, or the event system will break down when you
>> > send events out-of-order. The latter is what the even
On Mon, 9 Dec 2002, Tim Hockin wrote:
> > Well, why would you ever want to *change* the number of Bays of a
> > plugin? Well, consider a plugin that wraps other plugins... If
>
> This is VERY important in my worldview. Assuming the work being done on a
> VST hack on wine, a VST wrapper plugin o
On Wed, Dec 11, 2002 at 04:35:16 +0100, David Olofson wrote:
> > Maybe. My objection to converters is more that they imply two
> > parallel representations of frequency (in the broad sense of the
> > word), which seems like a mistake.
>
> They are not parallel. One actually *is* frequency, while t
(Oops. Replied to the direct reply, rather than via the list. Please,
don't CC me - I'm on the list! :-)
-- Forwarded Message --
Subject: Re: [linux-audio-dev] XAP: Pitch control
Date: Wed, 11 Dec 2002 18:05:57 +0100
From: David Olofson <[EMAIL PROTECTED]>
To: Nathaniel Virgo <
(Same thing again...)
-- Forwarded Message --
Subject: Re: [linux-audio-dev] XAP: Pitch control
Date: Wed, 11 Dec 2002 18:15:59 +0100
From: David Olofson <[EMAIL PROTECTED]>
To: Nathaniel Virgo <[EMAIL PROTECTED]>
On Wednesday 11 December 2002 18.09, Nathaniel Virgo wrote:
> On
On Wednesday 11 December 2002 4:29 pm, David Olofson wrote:
> On Wednesday 11 December 2002 13.59, David Gerard Matthews wrote:
> > Steve Harris wrote:
> > >On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
> > >>I can't really say I can think of a better way though.
> > >> Personally
On Wednesday 11 December 2002 17.17, Steve Harris wrote:
> On Wed, Dec 11, 2002 at 04:25:56 +0100, David Olofson wrote:
> > > (1/12)/note makes more sense because theres /is/ someting very
> > > 12ey about 12tET notes (the clues in the name ;), whereas there
> > > is nothing 12ey about octaves. At
On Wednesday 11 December 2002 3:41 pm, David Olofson wrote:
> On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
> > I can't really say I can think of a better way though.
> > Personally I'd leave scales out of the API and let the host deal
> > with it, sticking to 1.0/octave throughout
On Wednesday 11 December 2002 15.25, Tim Goetze wrote:
> David Olofson wrote:
> >So, sort them and keep track of where you are. You'll have to sort
> >the events anyway, or the event system will break down when you
> > send events out-of-order. The latter is what the event processing
> > loop of ev
On Wednesday 11 December 2002 17.02, Sebastien Metrot wrote:
> This doesn't work most of the time because many names can have
> multiple meanings and vice versa.
This is *exactly* why I'm proposing the use of a structured text file
that matches the structure of the plugin's "exported" names. The
On Wednesday 11 December 2002 13.59, David Gerard Matthews wrote:
> Steve Harris wrote:
> >On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
> >>I can't really say I can think of a better way though.
> >> Personally I'd leave scales out of the API and let the host deal
> >> with it, s
On Wednesday 11 December 2002 13.14, Sami P Perttu wrote:
[...]
> > This sounds interesting and very flexible - but what's the cost?
> > How many voices of "real" sounds can you play at once on your
> > average PC? (Say, a 2 GHz P4 or someting.) Is it possible to
> > start a sound with sample accur
On Wed, Dec 11, 2002 at 04:53:40 +0100, David Olofson wrote:
> That's something we might want to consider. Indeed, building names
> into binaries means we'll actually need one binary for each language
> (uurgh! reminds me of how Windoze "handles" languages...), but I'm
> not sure external files
On Wed, Dec 11, 2002 at 04:25:56 +0100, David Olofson wrote:
> > (1/12)/note makes more sense because theres /is/ someting very 12ey
> > about 12tET notes (the clues in the name ;), whereas there is
> > nothing 12ey about octaves. At all.
>
> There is nothing 12ey *at all* about notes if you're in
This doesn't work most of the time because many names can have multiple
meanings and vice versa. Also you'll have to manage encodings correctly, and
most developpers are just not aware of what an encoding really is.
Sebastien
- Original Message -
From: "David Olofson" <[EMAIL PROTECTED]>
On Wednesday 11 December 2002 12.38, Sami P Perttu wrote:
[...]
> I shall have to add something like this to MONKEY. Right now it
> supports LADSPA via a wrapper - the native API is pretty complex -
> although creating a nice GUI based on just information in a LADSPA
> .so is not possible, mainly d
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
> I can't really say I can think of a better way though.
> Personally I'd leave scales out of the API and let the host deal
> with it, sticking to 1.0/octave throughout, but I can see the
> advantages of this as well.
Problem with let
On Wednesday 11 December 2002 12.10, Steve Harris wrote:
> On Wed, Dec 11, 2002 at 01:39:12 +0100, David Olofson wrote:
> > Anyway, given that a converter plugin instance can only ever be
> > called once per buffer, and could potentially handle multiple
> > channels, I'm sure it will be quite a bit
On Wednesday 11 December 2002 12.06, Steve Harris wrote:
> On Wed, Dec 11, 2002 at 01:26:01 +0100, David Olofson wrote:
> > You're missing that I'm not talking about 1.0/octave, linear
> > pitch, but /note, *note* pitch. That means
> > /note should *always* apply, and that
> > should be constant.
David Olofson wrote:
>So, sort them and keep track of where you are. You'll have to sort
>the events anyway, or the event system will break down when you send
>events out-of-order. The latter is what the event processing loop of
>every plugin will do, BTW - pretty trivial stuff.
what you descr
On Wed, 11 Dec 2002 12:09:58 +, Steve Harris wrote
> On Wed, Dec 11, 2002 at 12:47:50 +0100, Dave Griffiths wrote:
> > It also means getting midi signal routing working, as currently ssm has no
> > polyphonic means of note signalling, but it's fairly trivial. The only thing
> > is that it will
Steve Harris wrote:
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though. Personally I'd leave
scales out of the API and let the host deal with it, sticking to 1.0/octave
throughout, but I can see the advantages of this as well.
Antti Boman wrote:
Frank Barknecht wrote:
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
quicktoots :(
You wet my appetite so that I have to ask if there's a version online
for a quick look beforehand. A qu
> > First, I don't understand why you want to design a "synth API". If
> > you want to play a note, why not instantiate a DSP network that
> > does the job, connect it to the main network (where system audio
> > outs reside), run it for a while and then destroy it? That is what
> > events are in my
On Wed, Dec 11, 2002 at 12:47:50 +0100, Dave Griffiths wrote:
> It also means getting midi signal routing working, as currently ssm has no
> polyphonic means of note signalling, but it's fairly trivial. The only thing
> is that it will break the everything plugs into anything rule :(
It shouldn't
On Tue, 10 Dec 2002 15:58:32 -0800, Paul Winkler wrote
> On Tue, Dec 10, 2002 at 11:18:53PM +, Steve Harris wrote:
> > I'm not quite sure how either of them handle that newfangled poly-phoney
> > that seems so popular these days ;)
>
> AFAICT, they both punt and do everything monophonic.
Ther
> > a softstudio; it's pretty far already and
> > the first public release is scheduled Q1/2003.
>
> for Linux, obviously? ;-)
Yes. Linux, GPL. MONKEY is about 30.000 lines of C++ at the moment. I
still have to make a final architecture revision based on some issues
reading this list has evoked, a
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
> I can't really say I can think of a better way though. Personally I'd leave
> scales out of the API and let the host deal with it, sticking to 1.0/octave
> throughout, but I can see the advantages of this as well.
We could put it
On Wed, Dec 11, 2002 at 01:39:12 +0100, David Olofson wrote:
> Anyway, given that a converter plugin instance can only ever be
> called once per buffer, and could potentially handle multiple
> channels, I'm sure it will be quite a bit faster than host callbacks
> when it actually matters: when y
On Wed, Dec 11, 2002 at 01:26:01 +0100, David Olofson wrote:
> You're missing that I'm not talking about 1.0/octave, linear pitch,
> but /note, *note* pitch. That means /note
> should *always* apply, and that should be constant.
> Changing it is totally pointless, since you'd still have note pi
Frank Barknecht wrote:
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
quicktoots :(
You wet my appetite so that I have to ask if there's a version online
for a quick look beforehand. A question mark.
-a
Hi,
Paul Winkler hat gesagt: // Paul Winkler wrote:
> PD can handle polyphony, and is about as modular as they come;
> but I don't really understand PD yet. :)
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
qui
On Wed, Dec 11, 2002 at 12:20:29AM +, Steve Harris wrote:
> On Tue, Dec 10, 2002 at 03:49:14PM -0800, Paul Winkler wrote:
> > Then JACK came along, and I decided to drop that idea and pursue
> > getting sfront to compile JACK clients. It works, mostly...
> > and one day I'll clean it up enough
I'm trying to oversample to smooth the display on my software audio
scope using band limited (sinc) interpolation. I have a quick question
to ask. Which of the following implementations is liable to take more
processing time:
1) Padding my data, and then convolving the original (non-zero) samples
w
66 matches
Mail list logo
