On Thu, 6 Feb 2003, David Olofson wrote:
> Would be interesting to know which ASCII values are valid inside
> multibyte charatcers, BTW. Is there a risk you'll see false slashes,
> colons and things like that in paths, if you don't parse the UTF-8
> properly? (There isn't IIRC, but I'll have to re
On Wed, 5 Feb 2003, David Olofson wrote:
> Anyway, the reason for not using Hz or similar in the API is that such
> units are harder to deal with, pretty much no matter what you want to
> do. The only exception is when you actually want to have some
> periodic action driven by it, ie sound. Thus,
On Wed, 5 Feb 2003, Steve Harris wrote:
> On Wed, Feb 05, 2003 at 10:31:06 +0200, Sami P Perttu wrote:
> > The more I'm thinking about this the more biased I am toward just one
> > process() that replaces values. And an in-place-is-okay hint. No gains or
> > DRY and
On Wed, 5 Feb 2003, David Olofson wrote:
> Q: Where do multiple versions of process() make sense?
> A: In small plugins that are likely to be used in many instances.
>
> Q: When do you desperatly want to avoid any added complexity?
> A: When implementing large "monolith" type plugins, that general
On Mon, 3 Feb 2003, David Olofson wrote:
> > As a plugin author, having to implement
> > both is a pain. I use code generation to make both functions.
>
> You don't necessarily *have* to implement both. Even the primitive FX
> plugin API of Audiality have these variants:
>
> void (*process)(
On Wed, 18 Dec 2002, Tim Hockin wrote:
> do we really need spline? How many plugins are going to implement that?
Splines would give us 6 dB/octave less discontinuity artifacts than
linear interpolation, or something like that. I don't know if we really
need them. The plugin interface can be made
On Tue, 17 Dec 2002, David Olofson wrote:
> > Thanks for the explanations... there is still one thing I don't
> > understand. Do you intend to have both frequency (Hz) and pitch
> > (logarithmic Hz) controls? It seems redundant.
>
> There will not be Hz at all, if I can help it; just linear PITCH,
On Tue, 17 Dec 2002, David Olofson wrote:
> This is not our first shot at an audio plugin API. We've all learned
> a lot since I came here with Audiality/RT-Linux, and IMHO, we should
> do our best to make XAP reflect our current knowledge and experience.
> I think we can do better than a slightly
On Mon, 16 Dec 2002, Tim Goetze wrote:
> >Summa theologica: dump musical time, note pitch, asynchronous I/O. Use Hz
> >for pitch.
>
> and never even think of using the system to actually
> produce music.
>
> tim
That's true, it would require something built on top of it to be musically
useful. I'
On Fri, 13 Dec 2002, David Olofson wrote:
> [...valid points...]
>
> > > How? It's not the host that sends these events in general; it's
> > > other plugins. The host never touches the events in the normal
> > > case.
> >
> > Okay. I'm lost here because I don't know what a XAP app would look
> > l
On Fri, 13 Dec 2002, David Olofson wrote:
> 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 h
On Fri, 13 Dec 2002, David Olofson wrote:
> > What is that? If a plugin got an audio port event it would just
> > update a pointer. Past samples should be kept in temporary
> > variables and future samples should not be looked at.
>
> Correct. But consider this example:
>
>
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 i
On Fri, 13 Dec 2002, Sami P Perttu wrote:
> It is tempting but I object to having high-level concepts such as musical
> time in XAP.
It is slightly stupid to reply to one's own post but I withdraw my
objection. I didn't really think it through.
--
Sami Perttu
On Thu, 12 Dec 2002, David Olofson wrote:
> Still, that does not prevent a gread deal of overlap, although XAP
> gets more and more expensive the more you "abuse" it - just like full
> audio rate or blockless systems tend to be less efficient when used
> more like "VSTi style" synths.
I thought X
On Fri, 13 Dec 2002, Tim Hockin wrote:
> * A tempo delay that starts a delayed sound just before the host loops the
> play back in (musical) time does not really want to know about absolute
> musical time, but DIFFERENCES in musical time. More precisely, it wants to
> be aware of the passing of t
On 12 Dec 2002, nick wrote:
> > > 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 co
On Wed, 11 Dec 2002, David Olofson wrote:
> An event system with "set" and "ramp" events can do the same thing -
> although it does get pretty inefficient when you want to transfer
> actuall audio rate data! ;-)
Yes. It seems that audio architecture design is dominated by the audio
versus control
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: co
> > 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
> > 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, a
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 in
22 matches
Mail list logo
