On Wed, Dec 11, 2002 at 12:20:29AM +, Steve Harris wrote:
On Tue, Dec 10, 2002 at 03:49:14PM -0800, Paul Winkler wrote:
Then JACK came along, and I decided to drop that idea and pursue
getting sfront to compile JACK clients. It works, mostly...
and one day I'll clean it up enough to
Hi,
Paul Winkler hat gesagt: // Paul Winkler wrote:
PD can handle polyphony, and is about as modular as they come;
but I don't really understand PD yet. :)
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
Frank Barknecht wrote:
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
quicktoots :(
You wet my appetite so that I have to ask if there's a version online
for a quick look beforehand. A question mark.
-a
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though. Personally I'd leave
scales out of the API and let the host deal with it, sticking to 1.0/octave
throughout, but I can see the advantages of this as well.
We could put it to
a softstudio; it's pretty far already and
the first public release is scheduled Q1/2003.
for Linux, obviously? ;-)
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
On Wed, Dec 11, 2002 at 12:47:50 +0100, Dave Griffiths wrote:
It also means getting midi signal routing working, as currently ssm has no
polyphonic means of note signalling, but it's fairly trivial. The only thing
is that it will break the everything plugs into anything rule :(
It shouldn't
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 -
Antti Boman wrote:
Frank Barknecht wrote:
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
quicktoots :(
You wet my appetite so that I have to ask if there's a version online
for a quick look beforehand. A
Steve Harris wrote:
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though. Personally I'd leave
scales out of the API and let the host deal with it, sticking to 1.0/octave
throughout, but I can see the advantages of this as
On Wed, 11 Dec 2002 12:09:58 +, Steve Harris wrote
On Wed, Dec 11, 2002 at 12:47:50 +0100, Dave Griffiths wrote:
It also means getting midi signal routing working, as currently ssm has no
polyphonic means of note signalling, but it's fairly trivial. The only thing
is that it will break
David Olofson wrote:
So, sort them and keep track of where you are. You'll have to sort
the events anyway, or the event system will break down when you send
events out-of-order. The latter is what the event processing loop of
every plugin will do, BTW - pretty trivial stuff.
what you describe
On Wednesday 11 December 2002 12.06, Steve Harris wrote:
On Wed, Dec 11, 2002 at 01:26:01 +0100, David Olofson wrote:
You're missing that I'm not talking about 1.0/octave, linear
pitch, but something/note, *note* pitch. That means
something/note should *always* apply, and that something
On Wednesday 11 December 2002 12.10, Steve Harris wrote:
On Wed, Dec 11, 2002 at 01:39:12 +0100, David Olofson wrote:
Anyway, given that a converter plugin instance can only ever be
called once per buffer, and could potentially handle multiple
channels, I'm sure it will be quite a bit
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though.
Personally I'd leave scales out of the API and let the host deal
with it, sticking to 1.0/octave throughout, but I can see the
advantages of this as well.
Problem with
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
On Wed, Dec 11, 2002 at 04:25:56 +0100, David Olofson wrote:
(1/12)/note makes more sense because theres /is/ someting very 12ey
about 12tET notes (the clues in the name ;), whereas there is
nothing 12ey about octaves. At all.
There is nothing 12ey *at all* about notes if you're into
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
On Wednesday 11 December 2002 13.14, Sami P Perttu wrote:
[...]
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
On Wednesday 11 December 2002 13.59, David Gerard Matthews wrote:
Steve Harris wrote:
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though.
Personally I'd leave scales out of the API and let the host deal
with it, sticking to
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
On Wednesday 11 December 2002 15.25, Tim Goetze wrote:
David Olofson wrote:
So, sort them and keep track of where you are. You'll have to sort
the events anyway, or the event system will break down when you
send events out-of-order. The latter is what the event processing
loop of every
On Wednesday 11 December 2002 3:41 pm, David Olofson wrote:
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though.
Personally I'd leave scales out of the API and let the host deal
with it, sticking to 1.0/octave throughout, but
On Wednesday 11 December 2002 17.17, Steve Harris wrote:
On Wed, Dec 11, 2002 at 04:25:56 +0100, David Olofson wrote:
(1/12)/note makes more sense because theres /is/ someting very
12ey about 12tET notes (the clues in the name ;), whereas there
is nothing 12ey about octaves. At all.
On Wednesday 11 December 2002 4:29 pm, David Olofson wrote:
On Wednesday 11 December 2002 13.59, David Gerard Matthews wrote:
Steve Harris wrote:
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though.
Personally I'd leave
(Same thing again...)
-- Forwarded Message --
Subject: Re: [linux-audio-dev] XAP: Pitch control
Date: Wed, 11 Dec 2002 18:15:59 +0100
From: David Olofson [EMAIL PROTECTED]
To: Nathaniel Virgo [EMAIL PROTECTED]
On Wednesday 11 December 2002 18.09, Nathaniel Virgo wrote:
On
(Oops. Replied to the direct reply, rather than via the list. Please,
don't CC me - I'm on the list! :-)
-- Forwarded Message --
Subject: Re: [linux-audio-dev] XAP: Pitch control
Date: Wed, 11 Dec 2002 18:05:57 +0100
From: David Olofson [EMAIL PROTECTED]
To: Nathaniel Virgo
On Wed, Dec 11, 2002 at 04:35:16 +0100, David Olofson wrote:
Maybe. My objection to converters is more that they imply two
parallel representations of frequency (in the broad sense of the
word), which seems like a mistake.
They are not parallel. One actually *is* frequency, while the
On Mon, 9 Dec 2002, Tim Hockin wrote:
Well, why would you ever want to *change* the number of Bays of a
plugin? Well, consider a plugin that wraps other plugins... If
This is VERY important in my worldview. Assuming the work being done on a
VST hack on wine, a VST wrapper plugin or a
David Olofson wrote:
On Wednesday 11 December 2002 15.25, Tim Goetze wrote:
David Olofson wrote:
So, sort them and keep track of where you are. You'll have to sort
the events anyway, or the event system will break down when you
send events out-of-order. The latter is what the event
Antti Boman schrieb:
Antti Boman wrote:
Frank Barknecht wrote:
To wet your appetite: I really should finish my PD quicktoot, which
even in its current unfinished form is longer then three standard
quicktoots :(
You wet my appetite so that I have to ask if there's a version online
On Tue, Dec 10, 2002 at 09:25:15PM +, Nathaniel Virgo wrote:
programs. This means that if a commercial program comes along it won't be
able to use the library, and anyone who wanted to use that program would have
to manually keep loads of files in sync like we do now.
Like I said
This is VERY important in my worldview. Assuming the work being done on a
VST hack on wine, a VST wrapper plugin or a LADSPA wrapper plugin makes all
those bits of code available.
The vst ladspa plugin just makes vst plugins appear as ladspa plugins, so
thats not a problem.
Seeing the
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
delays based on musical time do, whatever you like to call
it.
I always assumed that tempo-delays and thinsg would just ask the host for
the musical time at the start of each buffer. With sample-accurate events,
the host can change tempo even within a buffer. If a plugin is concerned
with
On Wednesday 11 December 2002 5:19 pm, David Olofson wrote:
(Oops. Replied to the direct reply, rather than via the list. Please,
don't CC me - I'm on the list! :-)
Sorry, I just tend to hit reply to all because some lists seem to be set up
so that reply doesn't go to the list.
I like the
On Wed, Dec 11, 2002 at 04:31:24PM +, Bob Ham wrote:
of ladcca will have libladcca under the LGPL license. I do still not want
cubase if it's under proprietary license, and I do still very much fear a
linux-audio-dev world dominated by proprietary licenses, but libladcca under
the GPL
11/12/02 18:41, Kjetil S. Matheussen wrote:
This is VERY important in my worldview. Assuming the work being done on a
VST hack on wine, a VST wrapper plugin or a LADSPA wrapper plugin makes all
those bits of code available.
The vst ladspa plugin just makes vst plugins appear as ladspa
On Wednesday 11 December 2002 18.26, Steve Harris wrote:
On Wed, Dec 11, 2002 at 04:35:16 +0100, David Olofson wrote:
Maybe. My objection to converters is more that they imply two
parallel representations of frequency (in the broad sense of
the word), which seems like a mistake.
They
On Wed, 11 Dec 2002, David Olofson wrote:
Well, in MONKEY I have done away with separate audio and control
signals - there is only one type of signal. However, each block of
a signal may consist of an arbitrary number of consecutive
subblocks. There are three types of subblocks: constant,
On Wednesday 11 December 2002 19.32, Tim Hockin wrote:
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
On Wednesday 11 December 2002 18.54, Tim Goetze wrote:
David Olofson wrote:
On Wednesday 11 December 2002 15.25, Tim Goetze wrote:
David Olofson wrote:
So, sort them and keep track of where you are. You'll have to
sort the events anyway, or the event system will break down
when you
i'm convinced it's better to design one system that works
for event-only as well as audio-only plugins and allows for
the mixed case, too. everything else is an arbitrary
limitation of the system's capabilities.
So, you want our real time synth + effect API to also be a full-blown
On Wednesday 11 December 2002 19.42, Tim Hockin wrote:
delays based on musical time do, whatever you like to call
it.
I always assumed that tempo-delays and thinsg would just ask the
host for the musical time at the start of each buffer.
That's a hack that works ok in most cases, but it's
On Wed, Dec 11, 2002 at 06:49:17 +, Nathaniel Virgo wrote:
Sorry, I just tend to hit reply to all because some lists seem to be set up
so that reply doesn't go to the list.
See if your mail client has a reply-to-list deature, mutt does
(shift+L).
I like the idea of enforced explicit
On Wednesday 11 December 2002 20.25, Sami P Perttu wrote:
[...]
That sounds a lot like a specialized event system, actually. You
have structured data - and that is essentially what events are
about.
Hmm, that's one way of looking at it. I had thought of the subblock
aspect as something
On Wednesday 11 December 2002 21.50, Steve Harris wrote:
On Wed, Dec 11, 2002 at 06:49:17 +, Nathaniel Virgo wrote:
Sorry, I just tend to hit reply to all because some lists seem
to be set up so that reply doesn't go to the list.
See if your mail client has a reply-to-list deature, mutt
David Olofson wrote:
so eventually, you'll need a different event system for
plugins that care about musical time.
No. You'll need a different event system for plugins that want to
look at future events.
which is an added level of complexity, barring a lot of ways
to head for plugins.
i'm
On Wednesday 11 December 2002 22.26, Tim Goetze wrote:
David Olofson wrote:
so eventually, you'll need a different event system for
plugins that care about musical time.
No. You'll need a different event system for plugins that want to
look at future events.
which is an added level of
On Sun, 2002-12-08 at 16:14, Kai Vehmanen wrote:
On Sun, 8 Dec 2002, Paul Davis wrote:
you also haven't addressed kernel scheduling issues; the context
switch doesn't happen till the kernel has decided what task is going
to run next. if it picks the wrong one, for whatever reason, then
i'm becoming tired of discussing this matter. fine by me if
you can live with a plugin system that goes only half the way
towards usable event handling.
I haven't been following this issue too closely, rather waiting for some
decision. I have been busy incorporating other ideas. What do
On Wednesday 11 December 2002 23.12, Tim Hockin wrote:
i'm becoming tired of discussing this matter. fine by me if
you can live with a plugin system that goes only half the way
towards usable event handling.
I haven't been following this issue too closely, rather waiting for
some
David Olofson wrote:
On Wednesday 11 December 2002 13.59, David Gerard Matthews wrote:
Steve Harris wrote:
On Wed, Dec 11, 2002 at 12:40:18 +, Nathaniel Virgo wrote:
I can't really say I can think of a better way though.
Personally I'd leave scales out of the API and let the host deal
I (still) don't think musical time belongs in timestamps of your
average event in XAP. Those events are meant to act as an alternative
to audio rate controls or blockless processing. The host gives you a
time frame to work with (expressed as a number of audio frames), and
that's the timeframe
On Wednesday 11 December 2002 23.56, David Gerard Matthews wrote:
[...]
The need for 1.0/note or similar arrise when you want to work with
something like 12t without deciding on the exact tuning, and also
when you want to write simple event processor plugins that think
it terms of notes
Tim Hockin wrote:
i'm becoming tired of discussing this matter. fine by me if
you can live with a plugin system that goes only half the way
towards usable event handling.
I haven't been following this issue too closely, rather waiting for some
decision. I have been busy incorporating
David Olofson wrote:
That's not rude - I don't think anyone is *totally* sure about this...
Though, you might want to note (pun not intended) that I'm really
talking about continous pitch - not note numbers, as in integer,
MIDI style. You could think of the relation as
linear_pitch =
On Thursday 12 December 2002 03.10, David Gerard Matthews wrote:
David Olofson wrote:
That's not rude - I don't think anyone is *totally* sure about
this...
Though, you might want to note (pun not intended) that I'm really
talking about continous pitch - not note numbers, as in
integer,
Well, this might be early, but I needed to do something slightly less
demanding for a while. So I hacked a small presentation:
http://olofson.net/xap/
Please, check facts and language (not my native tongue), and suggest
changes or additions.
(Oops! Clicked on dat doggy-like animal
What's going on with headers, docs, names and stuff?
I've ripped the event system and the FX API (the one with the state()
callback) from Audiality, and I'm shaping it up into my own XAP
proposal. There are headers for plugins and hosts, as well as the
beginnings of a host SDK lib. It's
59 matches
Mail list logo
