10 Dec
2002
10 Dec
'02
4:43 a.m.
Hi everybody. I've been reading this list for a week. Thought I'd
"pitch"
in here because I'm also writing a softstudio; it's pretty far already and
the first public release is scheduled Q1/2003.
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.
On the issue of pitch: if I understood why you want a synth API I would
prefer 1.0/octave because it carries less cultural connotations. In my
system (it doesn't have a name yet but let's call it MONKEY so I won't
have to use the refrain "my system") you just give the frequency in Hz,
there is absolutely no concept of pitch. However, if you want, you can
define functions like C x = exp((x - 9/12) * log(2)) * middleA, where
middleA is another function that takes no parameters. Then you can give
pitch as "C 4" (i.e. C in octave 4), for instance. The expression is
evaluated and when the event (= modification to DSP network) is
instantiated it becomes an input to it, constant if it is constant,
linearly interpolated at a specified rate otherwise. I should explain more
about MONKEY for this to make much sense but maybe later.
Anyway, the question I'm most interested is: why a synth API?
--
Sami Perttu "Flower chase the sunshine"
Sami.Perttu(a)hiit.fi http://www.cs.helsinki.fi/u/perttu
10 Dec
10 Dec
6:42 a.m.
On Tue, 2002-12-10 at 08:38, Sami P Perttu wrote:
Hi everybody. I've been reading this list for a
week. Thought I'd "pitch"
in here because I'm also writing 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)
I've kept quiet for this thread, since i haven't had time to read all
the posts :-/ but i can see its evolving into something very different
than i had envisaged.
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
until i had a nicely written host and plugins to demonstrate it
effectively, but that could be a few more weeks - the code's there but
its a bit of a hack ATM.
It's very close to VST, and that was the idea - to make it easy to write
a plugin for both at once!
The argument against c++ has been a constantly changing ABI, but with
the release of GCC 3.2 it finally looks like G++ will have a stable API.
time will tell i guess.
Please feel free to express your opinion of 'AMP'.
-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
10:11 a.m.
The argument against c++ has been a constantly changing
ABI, but with
the release of GCC 3.2 it finally looks like G++ will have a stable API.
time will tell i guess.
i have my doubts about this. with the flexibility that c++
compile-time flags provide, i'm not sure one can ever talk about "a
stable ABI" for c++ code, even if the compiler itself never changes
it. when used with a dynamic (run-time) linker, things go wrong very
quickly unless all the binaries are known to be compiled "identically".
--p
3:54 p.m.
On Tuesday 10 December 2002 11.38, nick wrote:
[...]
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 until i had a nicely written host and plugins to
demonstrate it effectively, but that could be a few more weeks -
the code's there but its a bit of a hack ATM.
It's very close to VST, and that was the idea - to make it easy to
write a plugin for both at once!
IMHO, VST is a somewhat messy LADSPA, which now (after the addition
of some features and the event interface) is suffering severely from
being expanded in ways not originally taken in account.
I think we should learn from what VST does and how. I also think we
should *learn* from it's mistakes - not copy them!
The argument against c++ has been a constantly
changing ABI, but
with the release of GCC 3.2 it finally looks like G++ will have a
stable API.
Yeah, right! ;-)
time will tell i guess.
Indeed.
Other reasons not to use C++ for an API like this:
* C++ is major overkill for this kind of API.
* "Everyone" knows C - few know C++ well enough.
* Harder to make language wrappers.
//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 ---
7:12 a.m.
On Tue, Dec 10, 2002 at 10:38:52 +0200, Sami P Perttu wrote:
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.
For interoperability. Its defintly worth something if your synths LOF
output can drive another synths LFO input to get them running in sync.
On the issue of pitch: if I understood why you want a
synth API I would
prefer 1.0/octave because it carries less cultural connotations. In my
system (it doesn't have a name yet but let's call it MONKEY so I won't
have to use the refrain "my system") you just give the frequency in Hz,
there is absolutely no concept of pitch. However, if you want, you can
The problem with using frequency throughout is that it makes certain
common kinds of operation expensive (e.g. pitch modulation).
Perceived wisdom is that its best to work with pitch data at the
generation, sequencing and modulation stages, then convert to the
oscialtors native form internally. It reduces the number of conversions on
average.
- Steve
3:39 p.m.
On Tuesday 10 December 2002 09.38, Sami P Perttu wrote:
Hi everybody. I've been reading this list for a
week. Thought I'd
"pitch" in here because I'm also writing a softstudio; it's pretty
far already and the first public release is scheduled Q1/2003.
Sounds interesting! :-)
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.
99% of the synths people use these days are hardcoded, highly
optimized monoliths that are easy to use and relatively easy to host.
We'd like to support that kind of stuff on Linux as well, preferably
with an API that works equally well for effects, mixers and even
basic modular synthesis.
Besides, real time instantiation is something that most of us want to
avoid at nearly any cost. It is a *very* complex thing to get right
(ie RT safe) in any but the simplest designs.
On the issue of pitch: if I understood why you want a
synth API I
would prefer 1.0/octave because it carries less cultural
connotations.
Agreed. (Yes! The reasons why I want(ed) something else are purely
technical - but I think I have accepted another, equivalent solution
now.)
In my system (it doesn't have a name yet but
let's
call it MONKEY so I won't have to use the refrain "my system") you
just give the frequency in Hz, there is absolutely no concept of
pitch.
When working with musical synthesis, I find linear pitch (like
1.0/octave) much easier to deal with.
However, if you want, you can define functions like C
x =
exp((x - 9/12) * log(2)) * middleA, where middleA is another
function that takes no parameters. Then you can give pitch as "C 4"
(i.e. C in octave 4), for instance. The expression is evaluated and
when the event (= modification to DSP network) is instantiated it
becomes an input to it, constant if it is constant, linearly
interpolated at a specified rate otherwise. I should explain more
about MONKEY for this to make much sense but maybe later.
This sounds interesting and very flexible - but what's the cost? How
many voices of "real" sounds can you play at once on your average PC?
(Say, a 2 GHz P4 or someting.) Is it possible to start a sound with
sample accurate timing? How many voices would this average PC cope
with starting at the exact same time?
Anyway, the question I'm most interested is: why a
synth API?
(See above.)
You could think of our API as
* A way of running anything from a basic mono->mono
effect though complex "programs" inside any host
application that supports the API.
* In interface that inspires synth and effect
programmers to write *reusable components*, instead
of even more of these stand-alone applications that
cannot cooperate in any useful way.
* A performance hack, that gives users sample
accurate timing and lots of processing power on
affordable off-the-shelf hardware.
* An attempt to copy and improve upon designs that
have proven tremendously successful in the music
industry.
//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 ---
8075
days inactive
8075
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
David Olofson -
nick -
Paul Davis -
Sami P Perttu -
Steve Harris