[linux-audio-dev] XAP: a polemic

David Gerard Matthews dgm4+ at pitt.edu
Sat Dec 14 17:20:01 UTC 2002


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 ---
>






More information about the Linux-audio-dev mailing list