Hey all,
I was out of town last week, and no inet access. I'll catch up again this
week.
With all the elaborate discussions we've been having, I decided that BEFORE
I work on the header any more, I should spec all the details.
I've begun transforming the overview I posted a while back into a mo
I am not dead, I am moving house. :) I have not lost interest. I have a
new draft of the header and I am incorporating many discussed items. I will
be very busy this month, but I will try to post a new version soon. I move
next week, and am out for one week this month.
Just so no one wonders w
On Monday 16 December 2002 12.36, Steve Harris wrote:
> On Sun, Dec 15, 2002 at 09:12:55 +0100, David Olofson wrote:
> > > > I don't get it. If you're supposed to place the scale
> > > > converter *first*, then how are you supposed to be able to
> > > > apply anything like traditional music theory,
On Sun, Dec 15, 2002 at 09:12:55 +0100, David Olofson wrote:
> > > I don't get it. If you're supposed to place the scale converter
> > > *first*, then how are you supposed to be able to apply anything
> > > like traditional music theory, rather than pure, continous pitch
> > > based theory? You wil
Thanks a lot for your answers, it does clarify your points a lot.
I can say I understand your point of view now.
Sebastien
- Original Message -
From: "David Olofson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, 16 December, 2002 01:15
Subject: Re:
On Sunday 15 December 2002 22.46, Sebastien Metrot wrote:
> Sorry to step in this very interesting discution but I have one
> question regarding this floating point note/pitch thing.
At least, *I* don't mind. :-)
> Floating
> point is great for DSP code as it makes our lives quite easy. On
> the
ginal Message -
From: "David Olofson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, 15 December, 2002 21:12
Subject: Re: [linux-audio-dev] XAP status : incomplete draft
>
> You're still missing the point. Note pitch is /note, which
> is a linear s
On Sunday 15 December 2002 18.31, Steve Harris wrote:
> On Sat, Dec 14, 2002 at 06:49:01PM +0100, David Olofson wrote:
> > I don't get it. If you're supposed to place the scale converter
> > *first*, then how are you supposed to be able to apply anything
> > like traditional music theory, rather th
On Sat, Dec 14, 2002 at 06:49:01PM +0100, David Olofson wrote:
> I don't get it. If you're supposed to place the scale converter
> *first*, then how are you supposed to be able to apply anything like
> traditional music theory, rather than pure, continous pitch based
> theory? You will have to k
On Saturday 14 December 2002 16.13, Steve Harris wrote:
> On Sat, Dec 14, 2002 at 03:35:41 +0100, David Olofson wrote:
> > > Er, well, most people will just let the host do the wiring for
> > > them. So it will all work fine.
> >
> > ...as long as they put the plugins in the right order.
>
> Well y
On Sat, Dec 14, 2002 at 03:35:41 +0100, David Olofson wrote:
> > Er, well, most people will just let the host do the wiring for
> > them. So it will all work fine.
>
> ...as long as they put the plugins in the right order.
Well you will almost allways use a external device -> pitch converter, so
On Saturday 14 December 2002 11.15, Steve Harris wrote:
> On Sat, Dec 14, 2002 at 02:44:48 +0100, David Olofson wrote:
> > > Right, so dont allow plugins to talk notes... I still dont
> > > think its necceasry, its just programmer convienvence.
> >
> > It's actually more *user* convenience than pro
On Sat, Dec 14, 2002 at 02:44:48 +0100, David Olofson wrote:
> > Right, so dont allow plugins to talk notes... I still dont think
> > its necceasry, its just programmer convienvence.
>
> It's actually more *user* convenience than programmer convenience.
> Programmers that work with traditional th
On Saturday 14 December 2002 00.25, Steve Harris wrote:
> On Fri, Dec 13, 2002 at 11:47:13 +0100, David Olofson wrote:
> > And note that this problem occurs even in a pure 12tET net! You
> > *cannot* mix plugins that thin in notes/scales with linear pitch
> > based plugins in just any order, and th
On Friday 13 December 2002 23.42, Tim Hockin wrote:
[...]
> > > > > int xap_n_ports;
> > > > > XAP_port **ch_ports;
> > > >
> > > > What are these for? Shortcut to avoid the more complex system
> > > > below, when you don't really need it?
> > >
> > > Audio ports - master audio ports.
>
On Fri, Dec 13, 2002 at 11:59:52 +0100, David Olofson wrote:
> On Friday 13 December 2002 21.13, Steve Harris wrote:
> [...]
> > > What's missing? I thought about state() and decided this was
> > > complete. Did I miss something?
> >
> > I think large numbers of states are overcomplicated myself.
On Fri, Dec 13, 2002 at 11:47:13 +0100, David Olofson wrote:
> And note that this problem occurs even in a pure 12tET net! You
> *cannot* mix plugins that thin in notes/scales with linear pitch
> based plugins in just any order, and there is no way whatsoever the
> host or users can be informed
On Friday 13 December 2002 21.13, Steve Harris wrote:
[...]
> > What's missing? I thought about state() and decided this was
> > complete. Did I miss something?
>
> I think large numbers of states are overcomplicated myself.
Yes - and the ones you have should be very strictly defined. The hard
On Friday 13 December 2002 20.41, Nathaniel Virgo wrote:
> On Friday 13 December 2002 7:05 pm, David Olofson wrote:
> > On Friday 13 December 2002 19.01, Steve Harris wrote:
> > > But it duplicates pitch. If you dont allow note_pitch then you
> > > dont miss out on anything, all the plugins that wo
> I'd still like to see a list of fully compliant compilers. IIRC, I've
It's easy enough to get stdint.h from somewhere, too. I'll try not to rely
on it too much :)
> > > > int xap_n_ports;
> > > > XAP_port **ch_ports;
> > >
> > > What are these for? Shortcut to avoid the more c
On Friday 13 December 2002 20.28, Tim Hockin wrote:
> > This should not be allowed, if you want to run the instrument at
> > a different rate, reinstantiate it.
>
> This makes the API simpler (one less function call). Are there any
> drawbacks to it? Or conversely, are there any drawback to havin
On Friday 13 December 2002 20.24, Tim Hockin wrote:
> > > #include
> >
> > I'm thinking about using that as well - but how portable is it
> > these days? (No big deal, though. Just get one, or hack a fake if
> > you platform shouldn't support it for some strange reason.)
>
> C99 is here, use it :)
On Fri, Dec 13, 2002 at 11:24:33 -0800, Tim Hockin wrote:
> > Why the xap_ prefix on all the fields in the struct?
>
> Old habit - prefixing struct fields with soemthing to identify the struct.
> Makes it trivial to search for all uses of ->xap_label as opposed to ->label
> (which exists in severa
On Fri, Dec 13, 2002 at 11:28:59 -0800, Tim Hockin wrote:
> > This should not be allowed, if you want to run the instrument at a
> > different rate, reinstantiate it.
>
> This makes the API simpler (one less function call). Are there any
> drawbacks to it? Or conversely, are there any drawback t
On Friday 13 December 2002 7:05 pm, David Olofson wrote:
> On Friday 13 December 2002 19.01, Steve Harris wrote:
> > But it duplicates pitch. If you dont allow note_pitch then you dont
> > miss out on anything, all the plugins that would be possible still
> > are, it just makes a small number of sp
> This should not be allowed, if you want to run the instrument at a
> different rate, reinstantiate it.
This makes the API simpler (one less function call). Are there any
drawbacks to it? Or conversely, are there any drawback to having a
set_rate() method which is only ever called from the inac
> > #include
>
> I'm thinking about using that as well - but how portable is it these
> days? (No big deal, though. Just get one, or hack a fake if you
> platform shouldn't support it for some strange reason.)
C99 is here, use it :)
> > /*
> > * The current version of the API: read as "major
On Friday 13 December 2002 19.01, Steve Harris wrote:
> On Fri, Dec 13, 2002 at 05:22:06 +0100, David Olofson wrote:
> > > > ...and the optional "NOTE_PITCH" that no one will ever use,
> > > > of course. ;-)
> > >
> > > And many of us still think doesn't belong in the API... :)
> >
> > Well, my rem
On Fri, Dec 13, 2002 at 05:22:06 +0100, David Olofson wrote:
> > > ...and the optional "NOTE_PITCH" that no one will ever use, of
> > > course. ;-)
> >
> > And many of us still think doesn't belong in the API... :)
>
> Well, my remaining point is basically this: Should we have that kind
> of argu
On Friday 13 December 2002 15.08, Steve Harris wrote:
> Generally I agree with David, but there are a few things wher I
> dont:
>
> On Fri, Dec 13, 2002 at 02:30:32 +0100, David Olofson wrote:
> > >* The label is a file-unique, non-whitespace, string
> > > identifier for * the plugin. Hosts ca
Generally I agree with David, but there are a few things wher I dont:
On Fri, Dec 13, 2002 at 02:30:32 +0100, David Olofson wrote:
> > * The label is a file-unique, non-whitespace, string identifier
> > for * the plugin. Hosts can use the filename and label to identify
> > a * plugin uniquel
On Friday 13 December 2002 09.55, Tim Hockin wrote:
[...]
> #include
I'm thinking about using that as well - but how portable is it these
days? (No big deal, though. Just get one, or hack a fake if you
platform shouldn't support it for some strange reason.)
> /*
> * The current version of th
Here is a draft incorportaing a lot of what we've talked about. It is
missing a lot, and some is probably wrong/inconsistent. We've been talking
a LOT. :)
Notes:
* All VVID stuff is missing
* All pitch stuff is missing
* Currently uses a monolithic ChannelType for channels until actual answer
i
On Thursday 12 December 2002 09.32, Tim Hockin wrote:
> > What's going on with headers, docs, names and stuff?
>
> I'm incorporating - I keep bringing up things that need to be
> decided. We NEED to hammer out this Bays, Channels, etc crap.
Yes. I'll have a complete proposal ready soon - hopeful
> What's going on with headers, docs, names and stuff?
I'm incorporating - I keep bringing up things that need to be decided. We
NEED to hammer out this Bays, Channels, etc crap. Once that is out, I will
have a new header, well commented out for review hopefully this weekend.
Work has suddenly p
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
36 matches
Mail list logo
