Re: [linux-audio-dev] XAP: a polemic

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

Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Gerard Matthews (dgm4+@pitt.edu)
Date: Sun Dec 15 2002 - 00:20:29 EET


David Olofson wrote:

>On Saturday 14 December 2002 19.41, Tim Goetze wrote:
>
>>this is not meant to intimidate, rather to be a wake-up call.
>>
>
>[...many good points elided...]
>
>Well, considering that we seem to have virtually *no* input from
>people with solid experience with software sequencers or traditional
>music theory based processing, I suggest we either decide to build a
>prototype base on what we *know*, or put XAP on hold until we manage
>to get input from people with real experience in more fields.
>
>We do not seem to have sufficient information to answer the following
>questions:
>
> * Is an explicitly scale related pitch control type needed?
>
I would argue that it's not.

>
> * Is there a good reason to make event system timestamps
> relate to musical time rather than audio time?
>
Again, I would rather let the timestamps deal with audio time. Hosts
which work in bars/beats/frames
should be capable of doing the necessary conversion. Remember, there
are plenty of parameters which
might need some time indications but which are completely unrelated to
notions of tempo. I'm thinking
mostly about LFOs and other modualtion sources here (although there
might be good grounds for lumping
these in with frequency controlled parameters.) Just as I would rather
see pitch control make as few
assumptions as possible about tuning and temperament, I would like to
see time control make as few
assumptions as possible about tempo and duration. Sequencers generally
do operate within the
shared assumptions of traditional concepts of periodic rhythm, but in a
lot of music (from pure ambient
to many non-Western musics to much avant-garde music) such notions are
irrelevant at best.

>
> * Should plugins be able to ask the sequencer about *any*
> event, for the full length of the timeline?
>
Not sure that I grok the ramifications of this.

>
> * Is there a need for supporting multiple timelines?
>
Possibly. I would say definitely if the audio event timestamps relate
to musical time.
For example, in a sequencer, it should be possible to have different
tracks existing
simultaneously with different tempi. Obviously, if the timestamps are
derived from
audio time, then only a single timeline is needed, because you have a
single time
source which doesn't care about tempo. This hypothetical sequencer
would be
able to convert between arbirtrary representations of bpm and time
signature,
but the code for doing this would be in the host app, not the plugin.
Now, if the plugin timestamps events internally using musical time, then
multiple
timelines are necessary in the above scenario.

>And the most fundamental, and most important question:
>
> * Is it at all possible, or reasonable, to support
> sequencers, audio editors and real time synths with
> one, single plugin API?
>
Probably not. For audio editors, I think JACK is doing a very fine job.
 In fact, beginning
with FreqTweak, there seems to be some precedent for using JACK for
plugins. JACK's
biggest problem, however, is its lack of midi support. Basically, the
way I see it, XAP would
be for plugins and realtime synths hosted on a sequencer or DAW app
which uses JACK for
audio input/output.

>
>If we *had* sufficient information to answer these questions, there
>wouldn't be much of an argument after everyone understood the
>problem. The details would just have been a matter of taste.
>
>Now, we seem to have lots of ideas, but few facts, so there's not
>much point in further discussion. We need to test our ideas in real
>applications, and learn from the experience.
>
One thing which has crossed my mind: several people have brought up VST
as a frame of reference,
but has anyone looked at AudioUnits? I admit that I haven't either, but
the reference code is out there,
and perhaps it might be a good idea to take a look at it. (One
potential problem is that the example
code seems to be in Objective C.)
-dgm

>
>I guess I'm hunting for *real* problems. Please post any ideas you
>might have - I'll try to either explain the solution, implement it,
>or admit that a different design is needed.
>
>
>//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 : Sun Dec 15 2002 - 00:22:41 EET