On Friday 13 December 2002 03.07, Tim Hockin wrote:
[...]
> > How about a mixer with variable insert count? There are several
> > ways to implement that, but I can't think of one that doesn't
> > require either that dreaded "link" feature, or an extra level of
> > "grouping"...
>
> I prefer not to
> > newchannel_idx = plug->new_channel(channel_descriptor_idx); The
> But the host is allowed to assume that it is in fact an *index*; not
> just a cookie?
I guess no, it doesn't matter - it's a cookie.
> I see. (No problem as long as there is no assumption that anything is
> both an input an
On Thursday 12 December 2002 22.26, Tim Hockin wrote:
[...]
> > > So why do we need Bays and Foos again, and not just
> > > ChannelDescriptors? Simpler is better ...
> >
> > Well, the problem with addressing Channels 1D is that Channels
> > move around if you change the number of Channels of a cert
> What is a stereo I/O? How is it described, and how do you index them
> when making connections?
its a thing with 2 mono Audio Ports.
> > So why do we need Bays and Foos again, and not just
> > ChannelDescriptors? Simpler is better ...
>
> Well, the problem with addressing Channels 1D is that
On Thursday 12 December 2002 09.28, Tim Hockin wrote:
> > > So _every_ audio 'Channel' has one i/o port? Assuming I buy
> > > this whole model, it seems like multiple I/O (of one flavor - I
> > > or O) is right.
> >
> > You could say the Channel *is* the port (either I or O) for
> > audio, whereas
> > So _every_ audio 'Channel' has one i/o port? Assuming I buy this
> > whole model, it seems like multiple I/O (of one flavor - I or O) is
> > right.
>
> You could say the Channel *is* the port (either I or O) for audio,
> whereas for Controls, it's more like MIDI and CCs; one Channel has an
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 l
> > 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.
See
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 o
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
On Wednesday 11 December 2002 01.42, Tim Hockin wrote:
> > > I'm not conviced Bay has the correct connotation...
> >
> > Well, the intention is that it should be thought of something
> > like a physical "panel" or area on a real device, where you have
> > a number of jacks, all of the same kind.
>
John Lazzaro wrote:
>Basically, many Logic users would like to use SAOL as a scripting
>language for their own plugins ... thus, AudioUnits support.
make that 'Logic and Linux users' please.
>This could actually be a catalyst for SAOL becoming more popular
>generally, if it works out ...
i'm c
> > I'm not conviced Bay has the correct connotation...
>
> Well, the intention is that it should be thought of something like a
> physical "panel" or area on a real device, where you have a number of
> jacks, all of the same kind.
> Maybe there's a better word for it.
There has to be - see be
> Steve Harris <[EMAIL PROTECTED]> writes:
>
> Yeah, please do that would be damn useful. For rapid prototyping if
> nothing else
FYI, making sfront produce code suitable for .so's is at the
top of the list of things to do these days, because AudioUnits
support awaits it. But, that's the "sfront
On Wed, Dec 11, 2002 at 12:53:44AM +0100, David Olofson wrote:
> > The solution in SyncModular is much simpler, theres a big "Compile"
> > button and when you press it the sound goes away for a second or so
> > :)
>
> Well, yeah - but I was under the impression that the idea was to
> *avoid* that
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 submit to John L. to
> distribute with sfront... really, I will...
On Wednesday 11 December 2002 00.01, Steve Harris wrote:
> On Tue, Dec 10, 2002 at 07:51:58 +0100, David Olofson wrote:
> > Hmm... IIRC, someone initially misunderstood my design and
> > thought the VVIDs were a common resource maintaned by the host.
>
> That was me I think. Which is why I though i
On Wednesday 11 December 2002 00.05, Steve Harris wrote:
> On Tue, Dec 10, 2002 at 10:28:29 +0100, David Olofson wrote:
> > > it'd still be interesting to know how the sync problems this
> > > method poses are solved: you cannot rely on executable code
> > > modifications to be atomic. an indirect
On Tue, Dec 10, 2002 at 10:56:41PM +, Steve Harris wrote:
> Yeah, saol .so's would rock. Some problem with global varaibles IIRC, I
> think there might be an ELF hack to get round it but I never looked into
> it too closely.
This came up a long time ago when I looked into making
LADSPA a t
On Tue, Dec 10, 2002 at 10:28:29 +0100, David Olofson wrote:
> > it'd still be interesting to know how the sync problems this
> > method poses are solved: you cannot rely on executable code
> > modifications to be atomic. an indirect jump instruction is
> > not guaranteed to work ok: a pointer on x
On Tue, Dec 10, 2002 at 08:53:02 +0100, David Olofson wrote:
> > You could have an interpreted mode, where it tries to evaluate it
> > noramlly, but that /will/ be slow.
>
> Or an intermediate mode, where the GUI generates unoptimized machine
> code more or less directly, by pasting "micro plugin
On Tue, Dec 10, 2002 at 07:51:58 +0100, David Olofson wrote:
> Hmm... IIRC, someone initially misunderstood my design and thought
> the VVIDs were a common resource maintaned by the host.
That was me I think. Which is why I though it was a good idea :)
> This is optional for plugins, of course.
On Tue, Dec 10, 2002 at 07:16:52 +0100, Tim Goetze wrote:
> >Argh! I was thinking of dumping the code and rebuilding (hopefully keeping
> >the state). Doing it that way would be interesting, but much harder. Youd
> >have to either use a lot of function calls or do some hard code relocation
> >stuff
On Tuesday 10 December 2002 15.08, Tim Goetze wrote:
> Steve Harris wrote:
> >On Tue, Dec 10, 2002 at 02:03:42 +0100, Tim Goetze wrote:
> >> >Not if it generates machine code. That way, it could
> >> > (theoretically)
> >>
> >> in realtime? we'll need everybodies' spare cpu cycles!
> >
> >No, it re
Tim Goetze wrote:
Steve Harris wrote:
On Tue, Dec 10, 2002 at 03:08:01 +0100, Tim Goetze wrote:
it'd still be interesting to know how the sync problems this
method poses are solved: you cannot rely on executable code
By sync problemt do you mean loop latency? There not solved exac
On Tuesday 10 December 2002 12.32, Steve Harris wrote:
> On Tue, Dec 10, 2002 at 01:07:48 +0100, Tim Goetze wrote:
> > Steve Harris wrote:
> > >Linuxsampler is using a similar approach, but its not blockless
> > > (and it wouldn't be noticably better if it was).
> > >
> > >Still if anyone ever want
On Tuesday 10 December 2002 12.36, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 10:56:42 -0800, Tim Hockin wrote:
> > * Must get enough so that if something else asks you can dole
> > some out
>
> I'm not sure why this is neccesary. Can someone explain. The others
> seem reasonable (its not like y
On Tuesday 10 December 2002 08.00, Tim Hockin wrote:
> > It doesn't have to, unless it actually cares. If you save a
> > preset with a "bad" value in some field, the plugin will just fix
> > it when you load the preset.
> >
> > There's just one problem: In what order do you write the controls
> > b
On Tuesday 10 December 2002 07.56, Tim Hockin wrote:
> > > the RT engine - *unless* you decide on a number of VVIDs to
> > > allocate for each Channel of every plugin, right when they're
> > > instantiated.
> >
> > That sound most sensible. The instrument has to allocate voice
> > table space, so t
Steve Harris wrote:
>> nope, i meant dynamic updates on a realtime (lock-free)
>> code path; it's an interesting problem with, afaict, no
>> obviously elegant solutions.
>
>Argh! I was thinking of dumping the code and rebuilding (hopefully keeping
>the state). Doing it that way would be interestin
On Tuesday 10 December 2002 07.17, Tim Hockin wrote:
> > > a Channel has p Controls and q Ports
> >
> > Well, a Channel can have p Controls OR p Audio Ports. I would say
> > that a Channel can vave p *Slots* - where a slot can be one of:
> > Audio Input Slot
> > Audio Output Slot
> > Co
On Tue, Dec 10, 2002 at 05:06:29 +0100, Tim Goetze wrote:
> Steve Harris wrote:
>
> >On Tue, Dec 10, 2002 at 03:08:01 +0100, Tim Goetze wrote:
> >> it'd still be interesting to know how the sync problems this
> >> method poses are solved: you cannot rely on executable code
>
> >By sync problemt
> On Mon, Dec 09, 2002 at 10:56:42 -0800, Tim Hockin wrote:
> > * Must get enough so that if something else asks you can dole some out
>
> I'm not sure why this is neccesary. Can someone explain. The others seem
> reasonable (its not like youre going to run out of ints).
There was talk of plugins
Steve Harris wrote:
>On Tue, Dec 10, 2002 at 03:08:01 +0100, Tim Goetze wrote:
>> it'd still be interesting to know how the sync problems this
>> method poses are solved: you cannot rely on executable code
>By sync problemt do you mean loop latency? There not solved exactly its
nope, i meant dy
Paul Davis wrote:
>no, atomic is 32 bits on x86. its only 24 bits on sparc, where
>the need to provide a spinlock to cover cache write-back effects
>forces it to 24 bits. you can do atomic exchange and compare-and-swap
>on pointers for x86.
thanks for the correction. sacrificing portability, this
On Tue, Dec 10, 2002 at 03:08:01 +0100, Tim Goetze wrote:
> it'd still be interesting to know how the sync problems this
> method poses are solved: you cannot rely on executable code
> modifications to be atomic. an indirect jump instruction is
> not guaranteed to work ok: a pointer on x86 is 32 b
>Steve Harris wrote:
>
>>On Tue, Dec 10, 2002 at 02:03:42 +0100, Tim Goetze wrote:
>>> >Not if it generates machine code. That way, it could (theoretically)
>>>
>>> in realtime? we'll need everybodies' spare cpu cycles!
>>
>>No, it really isn't that slow.
>>
>>SyncModular does a similar trick.
>
Steve Harris wrote:
>On Tue, Dec 10, 2002 at 02:03:42 +0100, Tim Goetze wrote:
>> >Not if it generates machine code. That way, it could (theoretically)
>>
>> in realtime? we'll need everybodies' spare cpu cycles!
>
>No, it really isn't that slow.
>
>SyncModular does a similar trick.
it'd still
On Mon, Dec 09, 2002 at 10:56:42 -0800, Tim Hockin wrote:
> * Must get enough so that if something else asks you can dole some out
I'm not sure why this is neccesary. Can someone explain. The others seem
reasonable (its not like youre going to run out of ints).
- Steve
On Tue, Dec 10, 2002 at 02:03:42 +0100, Tim Goetze wrote:
> >Not if it generates machine code. That way, it could (theoretically)
>
> in realtime? we'll need everybodies' spare cpu cycles!
No, it really isn't that slow.
SyncModular does a similar trick.
- Steve
On Tue, Dec 10, 2002 at 01:07:48 +0100, Tim Goetze wrote:
> Steve Harris wrote:
>
> >Linuxsampler is using a similar approach, but its not blockless (and
> >it wouldn't be noticably better if it was).
> >
> >Still if anyone ever wants to tackle this they can have a fair chunk of my
> >spare brain
> It doesn't have to, unless it actually cares. If you save a preset
> with a "bad" value in some field, the plugin will just fix it when
> you load the preset.
>
> There's just one problem: In what order do you write the controls
> back to ensure you end up with the exact same result?
The ord
> > the RT engine - *unless* you decide on a number of VVIDs to allocate
> > for each Channel of every plugin, right when they're instantiated.
>
> That sound most sensible. The instrument has to allocate voice table
> space, so there is likly to be an internal (soft) limit anyway.
so this is th
> > a Channel has p Controls and q Ports
>
> Well, a Channel can have p Controls OR p Audio Ports. I would say
> that a Channel can vave p *Slots* - where a slot can be one of:
> Audio Input Slot
> Audio Output Slot
> Control Input
> Control Output
Ok - I see how you've s
On Tuesday 10 December 2002 02.15, Tim Hockin wrote:
> > struct XAP_bay_descriptor
> > {
> > const char *name;
> > XAP_channel_typechannel_type;
> > int min_channels;
> > int max_cha
On Tuesday 10 December 2002 01.18, Tim Hockin wrote:
> Long context, sorry
>
> > > Do let me see if I get this right:
> > >
> > > Host allocates the VVID pool (perhaps a bitmask or some other
> > > way of indicating usage)
> > > Host wants to send a VOICE_ON:
> > > allocates an unused VVID
> > >
> struct XAP_bay_descriptor
> {
> const char *name;
> XAP_channel_typechannel_type;
> int min_channels;
> int max_channels;
> /*
>* Maybe so
David Olofson wrote:
>On Tuesday 10 December 2002 01.07, Tim Goetze wrote:
>> Steve Harris wrote:
>> >Linuxsampler is using a similar approach, but its not blockless
>> > (and it wouldn't be noticably better if it was).
>> >
>> >Still if anyone ever wants to tackle this they can have a fair
>> > c
On Tuesday 10 December 2002 01.07, Tim Goetze wrote:
> Steve Harris wrote:
> >Linuxsampler is using a similar approach, but its not blockless
> > (and it wouldn't be noticably better if it was).
> >
> >Still if anyone ever wants to tackle this they can have a fair
> > chunk of my spare brain cycles
On Monday 09 December 2002 23.41, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 10:01:15 +0100, David Olofson wrote:
> > Well, those kind of belong together - at least if you're working
> > on the level where feedback loops are used frequently. I think an
> > "ordinary" plugin API can do some of th
Long context, sorry
> > Do let me see if I get this right:
> >
> > Host allocates the VVID pool (perhaps a bitmask or some other way
> > of indicating usage)
> > Host wants to send a VOICE_ON:
> > allocates an unused VVID
> > sends VOICE_ON with that VVID
> > when it sends a VOICE_OFF
Steve Harris wrote:
>Linuxsampler is using a similar approach, but its not blockless (and
>it wouldn't be noticably better if it was).
>
>Still if anyone ever wants to tackle this they can have a fair chunk of my
>spare brain cycles.
if it's going to run blockless, we'll need all your spare
cpu c
On Mon, Dec 09, 2002 at 10:01:15 +0100, David Olofson wrote:
> Well, those kind of belong together - at least if you're working on
> the level where feedback loops are used frequently. I think an
> "ordinary" plugin API can do some of this, but only for sane feedback
> delays, unless you can acc
On Monday 09 December 2002 22.39, Sebastien Metrot wrote:
> Do I really look *that* clueless? ;-D
Yes! ;-D
No, of course not. (Although I don't actually know what you look
like. :-) I was just trying to formulate the first sentence in a
somewhat amusing way, but lost the point...
> > On Monda
Do I really look *that* clueless? ;-D
Sebastien
- Original Message -
From: "David Olofson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, 09 December, 2002 22:11
Subject: Re: [linux-audio-dev] Plugin APIs (again)
> On Monday 09 December 2002 19.3
On Monday 09 December 2002 19.45, Sebastien Metrot wrote:
> And so is JACK if i'm not mistaken ;-).
Yes, but it's just a word; not a TLA for a specific type of
connector. :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --
On Monday 09 December 2002 19.32, Sebastien Metrot wrote:
> XLR = Xtended Linux Rack (everybody knows its freind Jack ;-)
...and XLR is a type of connector frequently used in studios and PA.
Is that intentional? :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of
On Monday 09 December 2002 18.56, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 05:31:41PM +0100, David Olofson wrote:
> > So, what do you do if you don't *have* the source signal you want
> > in audio format? Hack the plugin? (Yeah, ordinary users will love
> > that...)
>
> Well ordinary users don
Good lord you guys were busy while I was asleep. I'm going to spend all day
just digesting the 70+ emails I have to read, and forget about replying to
them all.
How does this sound, since I seem to be the scribe: I'm just going to shut
up for a while and sort all the emails into questions, reaso
> And so is JACK if i'm not mistaken ;-).
Not as an acronym, or at least, not one I am aware of. Besides 'jack' is a
generic concept. It's something you plug in to. XLR does not have the
benefit of having a vague meaning :)
Besides It doesn't speak well. "Ziller". XAP (in US anyway) would b
And so is JACK if i'm not mistaken ;-).
Sebastien
- Original Message -
From: "Tim Hockin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, 09 December, 2002 19:39
Subject: Re: [linux-audio-dev] Plugin APIs (again)
> > XLR = Xtended Linux Rack
> XLR = Xtended Linux Rack (everybody knows its freind Jack ;-)
>
> Just my 0.02 cents of euros :)
XLR already has a well-established meaning in the audio world. Best not to
overload it :)
XLR = Xtended Linux Rack (everybody knows its freind Jack ;-)
Just my 0.02 cents of euros :)
Sebastien
- Original Message -
From: "Kjetil S. Matheussen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, 09 December, 2002 19:24
Subject: Re: [linux-audio-d
On Mon, 9 Dec 2002, Kjetil S. Matheussen wrote:
>
>
> On Sun, 8 Dec 2002, Joern Nettingsmeier wrote:
>
> > Tim Hockin wrote:
> > >
> > > > > Why? What is it that LADSPA does that would be so complicated that an
> > > > > instrument API must not support it?
> > > >
> > > > Nothing, OAPI or whatev
On Sun, 8 Dec 2002, Joern Nettingsmeier wrote:
> Tim Hockin wrote:
> >
> > > > Why? What is it that LADSPA does that would be so complicated that an
> > > > instrument API must not support it?
> > >
> > > Nothing, OAPI or whatever will be a superset I imagine, but that implies
> > > that LADSPA
On Mon, Dec 09, 2002 at 05:31:41PM +0100, David Olofson wrote:
> So, what do you do if you don't *have* the source signal you want in
> audio format? Hack the plugin? (Yeah, ordinary users will love
> that...)
Well ordinary users dont want audio rate controle either... until sfotware
companies t
On Mon, Dec 09, 2002 at 05:00:43PM +0100, David Olofson wrote:
> > Doesnt it make more sense to require imstruments to handle all
> > values in the range that they declare as valid? Thats not hard.
>
> Hmm... Well, yes, but how do you handle these enum controls with
> "random" modes that can be d
On Monday 09 December 2002 16.57, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 03:49:55PM +0100, David Olofson wrote:
> > > Converting between continuous control and event control is not
> > > reliable, and kinda removes the point of cont. control.
> >
> > Yes, but without converters, you can't do
On Monday 09 December 2002 16.09, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 03:33:47PM +0100, David Olofson wrote:
> > Well, let's put it as simple as this:
> >
> > If your plugin has controls that may refuse certain values
> > within the valid range, they *must* tell the host when this
On Mon, Dec 09, 2002 at 03:49:55PM +0100, David Olofson wrote:
> > Converting between continuous control and event control is not
> > reliable, and kinda removes the point of cont. control.
>
> Yes, but without converters, you can't do things like applying audio
> effects on controls...
Right, s
On Mon, Dec 09, 2002 at 03:53:30PM +0100, David Olofson wrote:
> Why filtering? The sequencer will just send events where they're
> meant to go, which means that each output may be connected to a
> different port, or all to the same port, or whatever.
OK, I was confused. Yes, this sounds fine.
On Mon, Dec 09, 2002 at 03:33:47PM +0100, David Olofson wrote:
> Well, let's put it as simple as this:
>
> If your plugin has controls that may refuse certain values
> within the valid range, they *must* tell the host when this
> happens. Otherwise, automation and preset save/res
On Monday 09 December 2002 15.35, Steve Harris wrote:
[...]
> > > > the RT engine - *unless* you decide on a number of VVIDs to
> > > > allocate for each Channel of every plugin, right when they're
> > > > instantiated.
> > >
> > > That sound most sensible. The instrument has to allocate voice
> >
On Monday 09 December 2002 15.31, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 02:17:06PM +0100, David Olofson wrote:
> > (*) One example would be if all your channels are driven by the
> > same sequencer, which has only one internal loop for event
> > output. Then event ordering is guaranteed, no
On Monday 09 December 2002 15.29, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 02:31:24PM +0100, David Olofson wrote:
> [audio rate controls]
>
> > Well, ok. You can have those *too*. (I'm Santa! :-)
>
> Well, you can obviously "have" them, but I dont think you want to
> have sophisticated support
On Mon, Dec 09, 2002 at 02:10:09PM +0100, David Olofson wrote:
> > Actually it quickly became obvious that for a host to construct a
> > useful GUI the plugin has to at least hint at some ranges.
>
> Yes, *hint*.
Yes, I agree with you entirly on this point.
> > > the RT engine - *unless* you de
On Monday 09 December 2002 15.16, Steve Harris wrote:
> On Mon, Dec 09, 2002 at 01:49:38PM +0100, David Olofson wrote:
> > > This sounds pretty complex. I'm not sure the hosts will be able
> > > to reliably implement this correctly.
> >
> > It doesn't have to, unless it actually cares. If you save
On Mon, Dec 09, 2002 at 02:17:06PM +0100, David Olofson wrote:
> (*) One example would be if all your channels are driven by the same
> sequencer, which has only one internal loop for event output. Then
> event ordering is guaranteed, no matter how many input ports the
> synth has, or h
On Mon, Dec 09, 2002 at 02:31:24PM +0100, David Olofson wrote:
[audio rate controls]
> Well, ok. You can have those *too*. (I'm Santa! :-)
Well, you can obviously "have" them, but I dont think you want to have
sophisticated support for both. That would make the API bloaty, and only
nuts like me ac
On Mon, Dec 09, 2002 at 01:49:38PM +0100, David Olofson wrote:
> > This sounds pretty complex. I'm not sure the hosts will be able to
> > reliably implement this correctly.
>
> It doesn't have to, unless it actually cares. If you save a preset
> with a "bad" value in some field, the plugin will j
On Monday 09 December 2002 13.37, Steve Harris wrote:
[...]
> > > If the host is marshaling the events then it should know what
> > > the last controller value it sent to the instrument was.
> >
> > It could also figure out what the interpolated value should be at
> > any time - whatever use that w
(Either I forgot to comment on this yesterday, or I missed some
stuff...)
On Sunday 08 December 2002 06.52, Tim Hockin wrote:
> > > controls, two filter controls etc and making them slightly
> > > different and behave differently in each plug. Are we better to
> > > define the behavior, or at lea
On Monday 09 December 2002 13.34, Steve Harris wrote:
[...]
> > That, and/or there should be ramp events. Those can be a bit
> > hairy to deal with at times, but please, do suggest an
> > alternative if there is one that is simpler and still sufficient
> > for sample accurate control... (No, no aud
On Monday 09 December 2002 13.29, Steve Harris wrote:
> On Sun, Dec 08, 2002 at 11:43:07PM +0100, David Olofson wrote:
> > Well, if you actually want to implement multicannel synths, all
> > you get with a single event queue is:
> >
> > * bigger events (more fields in the struct), and
> > *
On Monday 09 December 2002 13.27, Steve Harris wrote:
> On Sun, Dec 08, 2002 at 11:06:36PM +0100, David Olofson wrote:
> > Just like with LADSPA, the plugin will have to tell the host
> > whether or not it has absolute upper and/or lower limits. In VST,
> > the range is [0,1], period, but I think t
On Monday 09 December 2002 13.14, Steve Harris wrote:
> On Sun, Dec 08, 2002 at 02:20:11PM -0800, Tim Hockin wrote:
> > I was more thinking that some controls would disable certain
> > functions, or limit other controls. Assuming that there is no
> > get() method for a control, and the host knows
On Mon, Dec 09, 2002 at 12:27:58AM +0100, David Olofson wrote:
> On Sunday 08 December 2002 12.48, Steve Harris wrote:
> [...getting control values...]
> > The problem is that the dsp code doesn't always know the real value
> > of a controller: if its expensive to calcuate the coefficients you
> >
On Mon, Dec 09, 2002 at 01:25:24AM +0100, David Olofson wrote:
> On Sunday 08 December 2002 22.59, Steve Harris wrote:
> > On Sun, Dec 08, 2002 at 12:19:06PM -0800, Tim Hockin wrote:
> > > I'll buy that. Once the host reads the initial values, it should
> > > refrain from bothering the plugin.
> >
On Sun, Dec 08, 2002 at 11:43:07PM +0100, David Olofson wrote:
> Well, if you actually want to implement multicannel synths, all you
> get with a single event queue is:
>
> * bigger events (more fields in the struct), and
> * lots of queue splitting/filtering overhead.
> * You a
On Sun, Dec 08, 2002 at 11:06:36PM +0100, David Olofson wrote:
> Just like with LADSPA, the plugin will have to tell the host whether
> or not it has absolute upper and/or lower limits. In VST, the range
> is [0,1], period, but I think that's too restrictive. Scaling that
> range to whatever you
On Sun, Dec 08, 2002 at 11:11:18PM +0100, David Olofson wrote:
> On Sunday 08 December 2002 11.45, Steve Harris wrote:
> [...]
> > Your more immediate problem is making it easy for a LADSPA host to
> > host [insert name here] plugins. There are a lot of LADSPA hosts,
> > and zero [...] hosts.
>
>
On Sun, Dec 08, 2002 at 02:20:11PM -0800, Tim Hockin wrote:
> I was more thinking that some controls would disable certain functions, or
> limit other controls. Assuming that there is no get() method for a control,
> and the host knows the value by remembering, then the plugin does need to
> alert
Me, not long ago...:
> [...XAP...]
>
> Oh, I forgot to say what I was *actually* thinking:
Well, that's not the only thing I forgot. Just realized I never
*sent* the mail I referred to in the first place! (Need more
caffeine... :-)
Anyway, here it is:
On Monday 09 December 2002 09.45, Tim Ho
On Monday 09 December 2002 09.45, Tim Hockin wrote:
[...XAP...]
Oh, I forgot to say what I was *actually* thinking:
eXtensible might actually be true, if we allow a bit of "you may see
things you can't know about here - try to load a support/interface
plugin for it!" (Such as the multiple datat
On Monday 09 December 2002 08.54, Tim Hockin wrote:
> > > Interface. or 'PAPI Audio Plugin Interface'?
> >
> > In parts of the UK "pappy" is equivalent to shite, ie. redolent
> > of excrement ;)
>
> ok, then nix that. How about YAPI. Yet Another Plugin Interface?
Doesn't strike me as "Wow! *Thi
On Monday 09 December 2002 03.14, Paul Winkler wrote:
> On Mon, Dec 09, 2002 at 01:44:03AM +0100, David Olofson wrote:
> > (Quite easy to spell too, for those who refuse to say "ksapp" or
> > whatever. ;-)
>
> Well, taking a cue from xylophones and Xerox,
> I would pronounce it ZAP! ... with the
> Woops, dgm= tool. The X isn't the problem, as my earlier message would
> imply.
> What about XAP = eXtended Audio Plugins?
> -dgm
hmm, I like the XAP acronym, and it speaks well. I dunno about eXtended,
though. The X could be amorphous. X stands for eXtended, eXtreme,
eXtensible, eXcellent
> > Interface. or 'PAPI Audio Plugin Interface'?
>
> In parts of the UK "pappy" is equivalent to shite, ie. redolent of
> excrement ;)
ok, then nix that. How about YAPI. Yet Another Plugin Interface?
>> personally, i think ardour is an excellent proof-by-implementation
>> that yes, busses are really just a special class of strip,
>
>Well, no. Busses are not strips. Busses are not signal paths. Busses
>are unity gain summing nodes that facilitate many-to-one connections.
>Ardour depends on
> personally, i think ardour is an excellent proof-by-implementation
> that yes, busses are really just a special class of strip,
Well, no. Busses are not strips. Busses are not signal paths. Busses
are unity gain summing nodes that facilitate many-to-one connections.
Ardour depends on jack
1 - 100 of 213 matches
Mail list logo
