Re: [linux-audio-dev] Re: Synth APIs, pitch control

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: Synth APIs, pitch control
From: David Olofson (david_AT_olofson.net)
Date: Fri Dec 13 2002 - 15:53:54 EET


On Friday 13 December 2002 10.42, Sami P Perttu wrote:
> On 12 Dec 2002, nick wrote:
> > > > http://amsynthe.sourceforge.net/amp_plugin.h which i am still
> > > > toying
> >
> > My whole idea with it was to make it as simple as possible.
> > Bearing in mind that many people have learned MIDI already, it
> > makes sense to me to use it. Another cool thing is that you could
> > in theory write a sequencer as a plugin for it - since it can
> > output midi data as it wishes. Other plugins such as midi
> > arpeggiators could easily be written. All the timing is catered
> > for since you know the number of frames elapsed in this
> > process_**() call.
>
> Even as a control language MIDI has a lot of shortcomings that it's
> time to get rid of: note pitch values, low precision most
> everywhere.

Indeed.

> We might as well design a format ourselves. XAP can
> probably accommodate simple "musical" plugins but we really need
> another plugin system for the sequencer...

Yes... XAP will have to be designed with real time in mind, or it
will not be able to handle real time properly. If it can handle some
nonlinear off-line stuff as well without lots of added complexity,
that is to be regarded as an extra bonus.

> like you, I would really
> like to have something that is usable yesterday but it's not going
> to happen, sigh.

Well, who's stopping you from proposing a Sequencer DataBase API, or
whatever is needed for this? We real time guys will need that as
well, for sequencing and editing, so it's not like we don't care
about it; we're just trying to solve *our* most important problems
first.

> > Also I find the whole notion of 'ports' just complicates the
> > whole issue - the plugin is simply a piece of DSP code which
> > processes buffer(s) of audio data. why is anything more than a
> > pointer needed for this?
>
> Ports could support a pull model where plugins request data when
> they want it. Imagine a granular synthesizer that has, say, 16
> audio ports that it uses to render grains.

This is very interesting stuff indeed, and it also applies to things
like direct-from-disk samplers. I intended to support that kind of
stuff directly in MAIA, but the protocols I came up with are really
rather hairy. I don't think anything like that is going into XAP, but
you never know. After all, it would be an optional part of the API,
so you wouldn't even have to know about it. (The protocol needs no
host support beyond the audio buffer allocation already proposed.
It's just a thing between certain plugins.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Dec 13 2002 - 15:59:14 EET