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 incorporat
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
> 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 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 ad
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.
On Wednesday 11 December 2002 21.00, Tim Hockin wrote:
> > > 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.
> >
> >
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
> > 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-bl
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
>
> 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 mus
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 even
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 ev
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 descr
On Wednesday 11 December 2002 02.43, Paul Davis wrote:
> >> you are discussing an API that is intended to support
> >> *instruments*.
> >
> >And very few instruments understand musical time, and practically
> >none *should* think in terms of notes.
>
> i didn't say anything about notes (which is wh
On Wednesday 11 December 2002 02.06, Tim Goetze wrote:
> David Olofson wrote:
> >And normal plugins don't generate and "output" audio or control
> > data an arbitrary number of buffers ahead. Why should they do
> > that with events?
>
> you may have an algorithm written in a scripting (non-rt
> cap
>> you are discussing an API that is intended to support
>> *instruments*.
>
>And very few instruments understand musical time, and practically
>none *should* think in terms of notes.
i didn't say anything about notes (which is why i deliberately used a
non-MIDI number to stand for a pitch code o
David Olofson wrote:
>And normal plugins don't generate and "output" audio or control data
>an arbitrary number of buffers ahead. Why should they do that with
>events?
you may have an algorithm written in a scripting (non-rt
capable) language to generate events for example. or you
don't wan't t
On Wednesday 11 December 2002 01.44, Paul Davis wrote:
> >See how I handle this in Audiality. Originally, I thought it would
> > be a nice idea to be able to queue events ahead of the current
> > buffer, but it turned out to be a very bad idea for various
> > reasons.
> >
> >And normal plugins don'
>See how I handle this in Audiality. Originally, I thought it would be
>a nice idea to be able to queue events ahead of the current buffer,
>but it turned out to be a very bad idea for various reasons.
>
>And normal plugins don't generate and "output" audio or control data
>an arbitrary number o
On Wednesday 11 December 2002 00.08, Tim Goetze wrote:
> David Olofson wrote:
> >> thats a mistake, i think. there are some definite benefits to
> >> being able to define events' time in musical time as well.
> >
> >Like what? Since we're talking about sample accurate timing, isn't
> >asking the ho
David Olofson wrote:
>> thats a mistake, i think. there are some definite benefits to being
>> able to define events' time in musical time as well.
>
>Like what? Since we're talking about sample accurate timing, isn't
>asking the host about the musical time for an event timestamp
>sufficient for
On Tuesday 10 December 2002 23.02, Paul Davis wrote:
> >Yes. Event/audio time is one thing, and musical time is something
> >completely different, although related.
>
> you've just defined "event time" to be the same as "audio time".
> thats a mistake, i think. there are some definite benefits to b
>Yes. Event/audio time is one thing, and musical time is something
>completely different, although related.
you've just defined "event time" to be the same as "audio time". thats
a mistake, i think. there are some definite benefits to being able to
define events' time in musical time as well.
>M
On Tuesday 10 December 2002 20.31, Paul Davis wrote:
> >> I assume that if the host loops, or the user jumps back in
> >> song-position, time does not jump with it, it just keeps on
> >> ticking?
> >
> >Yes. You can't rewind *time*, can you? ;-)
> >
> >Seriously though, the reason to do it this way
On Tuesday 10 December 2002 15.54, Steve Harris wrote:
> On Tue, Dec 10, 2002 at 09:14:36 -0500, Paul Davis wrote:
> > >So time starts at some point decided by the host. Does the host
> > > pass the current timestamp to process(), so plugins know what
> > > time it is? I assume that if the host l
> i will be talking more about this issue at the LAD meeting in
> karlsruhe (plug, plug :)
which is impossible for Californians to attend on a budget :(
>> I assume that if the host loops, or the user jumps back in
>> song-position, time does not jump with it, it just keeps on
>> ticking?
>
>Yes. You can't rewind *time*, can you? ;-)
>
>Seriously though, the reason to do it this way is that timestamp time
>is directly related to "audio time" (ie s
On Tuesday 10 December 2002 08.56, Tim Hockin wrote:
[...timestamps...]
> > Wrapping is not a problem, so why avoid it? :-)
>
> So time starts at some point decided by the host. Does the host
> pass the current timestamp to process(), so plugins know what time
> it is?
In Audiality, there is a ho
On Tue, Dec 10, 2002 at 09:14:36 -0500, Paul Davis wrote:
> >So time starts at some point decided by the host. Does the host pass the
> >current timestamp to process(), so plugins know what time it is? I assume
> >that if the host loops, or the user jumps back in song-position, time does
> >not j
>So time starts at some point decided by the host. Does the host pass the
>current timestamp to process(), so plugins know what time it is? I assume
>that if the host loops, or the user jumps back in song-position, time does
>not jump with it, it just keeps on ticking?
>
>I guess my only question
> > > The way VST does it however, that wouldn't be needed, since
> > > timestamps are related to buffers. 0 == start of this buffer.
> > > Might look nice to plugins, but I forsee minor nightmares in
> > > multithreaded hosts, hosts that want to split buffers, hosts that
> > > support different bu
On Monday 09 December 2002 23.32, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 10:09:18 +0100, David Olofson wrote:
> > That explicit delay element I'm talking about would probably be
> > an internal host object that's aware of the buffer size in the
> > loop it sits in, and subtracts the correspo
On Mon, Dec 09, 2002 at 10:09:18 +0100, David Olofson wrote:
> That explicit delay element I'm talking about would probably be an
> internal host object that's aware of the buffer size in the loop it
> sits in, and subtracts the corresponding latency from the delay
> parameter, so you get *exact
On Monday 09 December 2002 18.59, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 05:47:47PM +0100, David Olofson wrote:
> > * Hosts may chose whatever buffer size they want.
> >
> > * You may be running off-line, in which case you
> > could potentially run with "huge" buffers.
> >
> >
On Mon, Dec 09, 2002 at 05:47:47PM +0100, David Olofson wrote:
> * Hosts may chose whatever buffer size they want.
>
> * You may be running off-line, in which case you
> could potentially run with "huge" buffers.
>
> It still doesn't matter? I do believe concistency matters in
On Monday 09 December 2002 17.30, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 04:52:48PM +0100, David Olofson wrote:
> > > > That's the feedback loop problem. As long as the host runs
> > > > plugins in the correct order, you'll never see this unless
> > > > you *actually* have loops in your netw
On Mon, Dec 09, 2002 at 04:52:48PM +0100, David Olofson wrote:
> > > That's the feedback loop problem. As long as the host runs
> > > plugins in the correct order, you'll never see this unless you
> > > *actually* have loops in your network.
> >
> > Like in your example ;)
>
> Hmm... Which one? (W
On Monday 09 December 2002 16.06, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 03:00:50PM +0100, David Olofson wrote:
> > That's the feedback loop problem. As long as the host runs
> > plugins in the correct order, you'll never see this unless you
> > *actually* have loops in your network.
>
> Lik
On Mon, Dec 09, 2002 at 03:00:50PM +0100, David Olofson wrote:
> That's the feedback loop problem. As long as the host runs plugins in
> the correct order, you'll never see this unless you *actually* have
> loops in your network.
Like in your example ;)
> The way VST does it however, that would
On Monday 09 December 2002 14.49, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 11:39:38AM +0100, David Olofson wrote:
> > In theory, the problem is very easy to solve: Have the host throw
> > in "shadow event ports", and then have it sort/merge the queues
> > from those into a single, ordered queu
On Mon, Dec 09, 2002 at 11:39:38AM +0100, David Olofson wrote:
> In theory, the problem is very easy to solve: Have the host throw in
> "shadow event ports", and then have it sort/merge the queues from
> those into a single, ordered queue that is passed to the actual
> target port.
I dont think
On Monday 09 December 2002 11.39, David Olofson wrote:
[...]
> struct XAP_cnx_descriptor
> {
> XAP_plugin *plugin;
> int bay;
> int channel;
> int output;
> };
Doh! s/output/slot/ or index or something, since this can describes
inpu
I did some thinking last night, and I have an interesting problem, as
well as a nice solution - or so I think. Please tell me what you
think.
Consider the following situation:
* You have a plugin "A", which has 1:4:7 (Bay:Channel:Control)
(which is an Event Output) connected
43 matches
Mail list logo
