11 Dec
2002
11 Dec
'02
7:43 a.m.
a softstudio;
it's pretty far already and
the first public release is scheduled Q1/2003.
for Linux, obviously? ;-) First, I
don't understand why you want to design a "synth API". If you
want to play a note, why not instantiate a DSP network that does the job,
connect it to the main network (where system audio outs reside), run it
for a while and then destroy it? That is what events are in my system -
timed modifications to the DSP network.
because a standard API is needed for a dynamically loaded plugins!
LADSPA doesnt really cater for event-driven processes (synths) For a complete contrast, please look over
http://amsynthe.sourceforge.net/amp_plugin.h which i am still toying
with as a(nother) plugin api suitable for synths. I was hoping to wait
I like this better than the more complex proposal being worked on, except
that I don't much care for MIDI myself. But I also realize the need for
the event/channel/bay/voice monster because it is more efficient and
potentially doesn't require plugins to be instantiated while a song is
playing. I don't think one API can fit all sizes.
--
Sami Perttu "Flower chase the sunshine"
Sami.Perttu(a)hiit.fi http://www.cs.helsinki.fi/u/perttu
11 Dec
11 Dec
11:58 a.m.
On Wednesday 11 December 2002 12.38, Sami P Perttu wrote:
[...]
I shall have to add something like this to MONKEY.
Right now it
supports LADSPA via a wrapper - the native API is pretty complex -
although creating a nice GUI based on just information in a LADSPA
.so is not possible, mainly due to lack of titles for enums.
That's something we might want to consider. Indeed, building names
into binaries means we'll actually need one binary for each language
(uurgh! reminds me of how Windoze "handles" languages...), but I'm
not sure external files are worth the extra complexity...
How about just having english in the source, and then add XML
translations later on, if desired? (Support is optional to host, and
plugins won't know about it.)
You could just hack an "application" that loads and queries plugins
and outputs XML containing all names found in a structure
corresponding to that of the plugin. Then you copy and translate that
for each new langugage. If plugin are named <plugin>.so, name these
<plugin>_<language acronym>.xml or something.
//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 ---
12:07 p.m.
This doesn't work most of the time because many names can have multiple
meanings and vice versa. Also you'll have to manage encodings correctly, and
most developpers are just not aware of what an encoding really is.
Sebastien
----- Original Message -----
From: "David Olofson" <david(a)olofson.net>
To: <linux-audio-dev(a)music.columbia.edu>
Sent: Wednesday, 11 December, 2002 16:53
Subject: Re: [linux-audio-dev] Re: Synth APIs, pitch control
On Wednesday 11 December 2002 12.38, Sami P Perttu
wrote:
[...]
I shall have to add something like this to
MONKEY. Right now it
supports LADSPA via a wrapper - the native API is pretty complex -
although creating a nice GUI based on just information in a LADSPA
.so is not possible, mainly due to lack of titles for enums.
That's something we might want to consider. Indeed, building names
into binaries means we'll actually need one binary for each language
(uurgh! reminds me of how Windoze "handles" languages...), but I'm
not sure external files are worth the extra complexity...
How about just having english in the source, and then add XML
translations later on, if desired? (Support is optional to host, and
plugins won't know about it.)
You could just hack an "application" that loads and queries plugins
and outputs XML containing all names found in a structure
corresponding to that of the plugin. Then you copy and translate that
for each new langugage. If plugin are named <plugin>.so, name these
<plugin>_<language acronym>.xml or something.
12:47 p.m.
On Wednesday 11 December 2002 17.02, Sebastien Metrot wrote:
This doesn't work most of the time because many
names can have
multiple meanings and vice versa.
This is *exactly* why I'm proposing the use of a structured text file
that matches the structure of the plugin's "exported" names. The
*structure* is what you go by; not the actual words. A host would not
even have to ask the plugin for the english names, but just look up
the corresponding position in the XML and get the name from there
instead.
Also you'll have to manage
encodings correctly, and most developpers are just not aware of
what an encoding really is.
Then don't try to write a host that supports non-english languages.
Just use what the plugins give you (english) and be happy.
//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 ---
2:37 p.m.
This is *exactly* why I'm proposing the use of a
structured text file
that matches the structure of the plugin's "exported" names. The
*structure* is what you go by; not the actual words. A host would not
even have to ask the plugin for the english names, but just look up
the corresponding position in the XML and get the name from there
instead.
You've basically described gettext(), which happens to be the standard way
of doing localization in modst code.
The plugin can be aware of it, if they want, or not. Let's assume not, and
they just get translated.
Plugin has English strings.
Host reads English strings.
Host examines some environment variables set by user to ID their locale.
Host looks up English string in the $locale specific hash.
English works.
Other Latin languages works.
Other character set languages work, if no one tries to index into strings.
I had thought about making reccomendations about this, but decided there was
no need. Plugins don't display anything themselves (modulo UIs which we
haven't even breached, and let's not, yet). Leave loclaization to the host
and the translators.
Tim
3:36 p.m.
On Wednesday 11 December 2002 19.32, Tim Hockin wrote:
Yes, then there is no problem, is there?
[...]
This is
*exactly* why I'm proposing the use of a structured text
file that matches the structure of the plugin's "exported" names.
The *structure* is what you go by; not the actual words. A host
would not even have to ask the plugin for the english names, but
just look up the corresponding position in the XML and get the
name from there instead.
You've basically described gettext(), which happens to be the
standard way of doing localization in modst code. I had thought about making reccomendations about this,
but decided
there was no need. Plugins don't display anything themselves
(modulo UIs which we haven't even breached, and let's not, yet).
Leave loclaization to the host and the translators.
Exactly.
//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 ---
12:27 p.m.
On Wed, Dec 11, 2002 at 04:53:40 +0100, David Olofson wrote:
That's something we might want to consider.
Indeed, building names
into binaries means we'll actually need one binary for each language
(uurgh! reminds me of how Windoze "handles" languages...), but I'm
not sure external files are worth the extra complexity...
How about just having english in the source, and then add XML
translations later on, if desired? (Support is optional to host, and
plugins won't know about it.)
Of course RDF can handle all this cleanly and extensibly.
- Steve
12 Dec
12 Dec
5:01 p.m.
On Wed, 2002-12-11 at 11:38, Sami P Perttu wrote:
Yes. Linux, GPL. MONKEY is about 30.000 lines of C++ at the moment. I
still have to make a final architecture revision based on some issues
reading this list has evoked, and prepare the whole thing for release.
I'm looking forward to it :-)
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.
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?
/end rant
-nick
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
a softstudio; it's pretty far already and
the first public release is scheduled Q1/2003.
for Linux, obviously? ;-) For a complete
contrast, please look over
http://amsynthe.sourceforge.net/amp_plugin.h which i am still toying
with as a(nother) plugin api suitable for synths. I was hoping to wait
I like this better than the more complex proposal being worked on, except
that I don't much care for MIDI myself. But I also realize the need for
the event/channel/bay/voice monster because it is more efficient and
potentially doesn't require plugins to be instantiated while a song is
playing. I don't think one API can fit all sizes.
5:49 p.m.
On Thursday 12 December 2002 21.56, nick wrote:
[...]
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.
Well, it's just that MIDI is rather hairy to deal with when it comes
to continous pitch, individual control of voices and stuff like that
- and obviously, 95% of plugin developers refuse to implement any of
that, as a result. (Look at VST.)
Thus, I think it's a better idea to look at the features we need, and
then implement a clean, simple API that's actually an *API* - not a
wire protocol for ultra low bandwidth connections.
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?
In fact, a Port is not even a pointer in some cases, but rather an
abstract object that you refer to using a cookie given to you by the
plugin. XAP Audio Ports will almost definitely just be pointers, as
anything else brings a bunch of non-obvious issues and no real
advantages.
These Ports, Channels, Bays etc we're talking about are either
abstract objects or init time "metadata". When you actually have your
plugin instantiated, there are only Event Queues and Audio Ports on
the API level. Anything else is entirely up to the plugin and host
designers.
//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 ---
13 Dec
13 Dec
5:47 a.m.
On 12 Dec 2002, nick wrote:
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. 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... like you, I would really like to have something that is
usable yesterday but it's not going to happen, sigh.
http://amsynthe.sourceforge.net/amp_plugin.h which i
am still toying
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.
--
Sami Perttu "Flower chase the sunshine"
Sami.Perttu(a)hiit.fi http://www.cs.helsinki.fi/u/perttu
6:45 a.m.
On Fri, Dec 13, 2002 at 11:42:39AM +0200, Sami P Perttu wrote:
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. 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... like you, I would really like to have something that is
usable yesterday but it's not going to happen, sigh.
We allready have an API for sequencers, alsa-seq, I've never used it but
it seems to work well.
- Steve
9:59 a.m.
On Friday 13 December 2002 10.42, Sami P Perttu wrote:
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 ---
On 12 Dec 2002, nick wrote:
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.
>
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. 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.
10:56 a.m.
On Fri, 13 Dec 2002, David Olofson wrote:
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.
It's no use trying yet, I wouldn't know where to begin. I have to write a
sequencer first to understand these things. At least I'm too far gone to
stop now - I've already spent a year writing GluttonAudio :). But I'm
going to shut up about GA now, too much talk and no source code.
Re: pull model, an alternative to supporting pull in XAP is to just say
that such plugins should act as hosts.
--
Sami Perttu "Flower chase the sunshine"
Sami.Perttu(a)hiit.fi http://www.cs.helsinki.fi/u/perttu
12:42 p.m.
On Friday 13 December 2002 15.51, Sami P Perttu wrote:
[...]
Re: pull model, an alternative to supporting pull in
XAP is to just
say that such plugins should act as hosts.
That's not much better than not having a plugin API at all. To
support direct-from-disk sampling, the host would have to be a
*sampler*. Why have an *instrument* plugin API, then? It doesn't make
much sense to me to run synths inside a sampler... :-)
//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 ---
3:19 p.m.
On Fri, 13 Dec 2002, David Olofson wrote:
On Friday 13 December 2002 15.51, Sami P Perttu
wrote:
[...]
But... running synths inside a granular synthesizer makes sense. Besides,
it's not just an instrument API, there's bound to be a white noise plugin
:).
--
Sami Perttu "Flower chase the sunshine"
Sami.Perttu(a)hiit.fi http://www.cs.helsinki.fi/u/perttu
Re: pull model, an alternative to supporting pull
in XAP is to just
say that such plugins should act as hosts.
That's not much better than not having a plugin API at all. To
support direct-from-disk sampling, the host would have to be a
*sampler*. Why have an *instrument* plugin API, then? It doesn't make
much sense to me to run synths inside a sampler... :-)
4:24 p.m.
On Friday 13 December 2002 20.14, Sami P Perttu wrote:
On Fri, 13 Dec 2002, David Olofson wrote:
Yes... But does the API prevent that? (Note that plugins can host
plugins...)
On Friday 13 December 2002 15.51, Sami P Perttu
wrote:
[...]
But... running synths inside a granular synthesizer makes sense. Re: pull model, an alternative to supporting pull
in XAP is to
just say that such plugins should act as hosts.
That's not much better than not having a plugin API at all. To
support direct-from-disk sampling, the host would have to be a
*sampler*. Why have an *instrument* plugin API, then? It doesn't
make much sense to me to run synths inside a sampler... :-) Besides, it's not just an instrument API,
there's bound to be a
white noise plugin
:).
A white noise generator isn't an instrument? If you can turn it on
and of in a somewhat rhythmical sense, I'd say it is! ;-)
//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 ---
7940
days inactive
7942
days old
linux-audio-dev@lists.linuxaudio.org
15 comments
6 participants
participants (6)
-
David Olofson -
nick -
Sami P Perttu -
Sebastien Metrot -
Steve Harris -
Tim Hockin