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
31 matches
Mail list logo
