> > 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?
On Sun, 8 Dec 2002, Paul Davis wrote:
> >> >I'm not talking about jack tasks, I'm talking about doing a simple
> >plug-in
> >> >task inside a standalone program, the way the vst server works.
> >>
> >> i don't understand how the vst server works. perhaps you can explain
> >> it.
> >
> >Its just
>> 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
Hi all,
I've been beavering away on a session/config managment system, and it's just
reached the point where projects can be properly saved and restored. It's
an implmentation of the api proposal, http://reduz.dyndns.org/api/ , that
originated from this discussion:
http://marc.theaimsgroup.com/?l
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 exclamation
point ;)
--PW
Or else you ca
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 exclamation
point ;)
--PW
--
Paul Winkler
http://www.slinkp
On Monday 09 December 2002 01.06, David Gerard Matthews wrote:
> David Olofson wrote:
> >On Sunday 08 December 2002 12.52, Steve Harris wrote:
> >[...API name...]
> >
> >>I jokingly suggested XLP in a previous thread on a similar
> >> subject. It could be... eXtended Linux Plugins?
> >>
> >>Maybe X
On Monday 09 December 2002 01.01, David Gerard Matthews wrote:
[...]
> Yeah, when I went to buy a SCSI Zip disk a few years ago when I was
> living in Austria, I was surprised
> to learn that they pronounce SCSI Es-Tseh-Es-I (in other words,
> exactly as the individual letters are pronounced
> in G
On Sunday 08 December 2002 23.54, Paul Davis wrote:
> >Well, I think means trouble for mixers, synths with sophisticated
> >"master sections" and that kind of stuff. You want to use the same
> >controls for busses as for strips?
>
> personally, i think ardour is an excellent proof-by-implementation
On Sunday 08 December 2002 23.10, Steve Harris wrote:
[...]
> > My personal preference is for something that doesn't have to be
> > spelled to be spoken. I know most people say VSTi as 'visty'.
>
> Agreed, our German brethren seem to want to spell out
> El-Ah-Dee-Es-Pee-Ah, which is pretty inconve
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.
>
> I think the host should be able to give the instrument its initial
> v
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
> you/we lose. right now, it picks the wrong one too o
On Sunday 08 December 2002 21.19, Tim Hockin wrote:
> > > Well, my first thought is that we don;t want to send a
> > > CTRL_CHANGE event to the host every time a control changes, Do
> > > we want the host to have to send CTRL_GET events and wait for
> > > CTRL_VALUE events, or can we say 'one tick
David Olofson wrote:
On Sunday 08 December 2002 12.52, Steve Harris wrote:
[...API name...]
I jokingly suggested XLP in a previous thread on a similar subject.
It could be... eXtended Linux Plugins?
Maybe XLI would be good here.
Not bad - although I think the "Linux" part is an issue. Do we
On Sunday 08 December 2002 19.12, Mark Knecht wrote:
> Frank,
>I agree with your comments. I'd also like to see the developers
> at least understand and consider these sorts of protocols also. In
> the end something good will come out of it.
>
>Actually, the use of MIDI velocity information
Steve Harris wrote:
Agreed, our German brethren seem to want to spell out
El-Ah-Dee-Es-Pee-Ah, which is pretty inconvenient.
OTOH I think Joern was amused when I insisted on pronouncing luss, as in
"can you just ls that directory".
- Steve
Yeah, when I went to buy a SCSI Zip disk a few years
On Sunday 08 December 2002 18.33, Frank van de Pol wrote:
[...bell example]
> Nice examlple. To me it clearly illustrates that velocity (ie.
> force of note on/off) is indeed a property of the note event.
To me, it's just another example of a special class of instruments.
> The
> handling of vel
On Sunday 08 December 2002 12.52, Steve Harris wrote:
[...API name...]
> I jokingly suggested XLP in a previous thread on a similar subject.
> It could be... eXtended Linux Plugins?
>
> Maybe XLI would be good here.
Not bad - although I think the "Linux" part is an issue. Do we want
this strictly
On Sunday 08 December 2002 12.49, Steve Harris wrote:
> On Sun, Dec 08, 2002 at 01:26:27 +0100, David Olofson wrote:
> > > > Ok. (But VSTis can be multichanne/multipart, AFAIK.)
> > >
> > > OK, but thier still instruments :)
> >
> > Yes - but there's only one instance for N channels. :-)
>
> Right,
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
> normally just calcuate them once for every N samples then
> interpolate t
On Sunday 08 December 2002 12.11, Tim Hockin wrote:
> > > Uggh, can we keep the get() of control values simpler than
> > > events? My previos proposal had a control->get() method and a
> > > ctrl->set() method. Obviously, the set() is superceded by
> > > events. Is the get, too?
> >
> > What is t
>Well, I think means trouble for mixers, synths with sophisticated
>"master sections" and that kind of stuff. You want to use the same
>controls for busses as for strips?
personally, i think ardour is an excellent proof-by-implementation
that yes, busses are really just a special class of strip,
On Sunday 08 December 2002 11.58, Steve Harris wrote:
> > I had been assuming a single event-queue per instance. Two
> > questions: why would a plugin (assuming not multi-timbral for
> > now) have more than one event-queue? Assuming we do support
> > multi-timbral synths, is there an advantage t
On Sunday 08 December 2002 11.42, Steve Harris wrote:
> On Sat, Dec 07, 2002 at 09:52:28 -0800, Tim Hockin wrote:
> > Do we really want to have different controls for different
> > channels? I can see how it might be neat, but since multiple
> > channels is convenient for hardware people, shouldn'
On Sunday 08 December 2002 06.00, Tim Hockin wrote:
[...]
> Aside: I propose the following for naming stuff:
>
> * Plugin: a chunk of code, loaded or not, that implements this API
> (a .so file or a running instance).
> * Instrument: an instance of a plugin that supports the instrument
> API bi
> I'm afraid I'm not familar with the AudioUnits API, but I dont/think/ this
> situation requires the instrument to inform the host, it should just be
> able to damp (slew rate limit) the control, shouldn't it? The result from
> playing back automation data will be the same, so no harm done.
Well,
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.
Easy enough to wrap the audio ports, but where would you get control
events
On Sun, Dec 08, 2002 at 12:25:16PM -0800, Tim Hockin wrote:
> I've converted it to PAPI for now, since it is easier to speak, and I
> 'speak' in my head as I write. {Portable, Public, Puerile} Audio Plugin
> Interface. or 'PAPI Audio Plugin Interface'?
In parts of the UK "pappy" is equivalent to
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.
I think the host should be able to give the instrument its initial values,
read for deafults, or a settings file etc.
> Aside: Do w
> > > Linux Audio Developers' More Sophisticated Plugin API (=LADMSPA) ? :-D
> >
> > umm, veto?
>
> I jokingly suggested XLP in a previous thread on a similar subject. It
> could be... eXtended Linux Plugins?
>
> Maybe XLI would be good here.
I once suggested OPI, but was stringly suggested to
> > Well, my first thought is that we don;t want to send a CTRL_CHANGE event to
> > the host every time a control changes, Do we want the host to have to send
> > CTRL_GET events and wait for CTRL_VALUE events, or can we say 'one tick
> > granularity is all the host can get' wrt CTRL_GET?
> If th
Serves me right I suppose...
have a nice day...
On Sun, 2002-12-08 at 11:28, Tim Hockin wrote:
> >I agree with your comments. I'd also like to see the developers at
> > least understand and consider these sorts of protocols also. In the end
> > something good will come out of it.
>
> We're n
>I agree with your comments. I'd also like to see the developers at
> least understand and consider these sorts of protocols also. In the end
> something good will come out of it.
We're not discussing discarding velocity. We're discussing whether it is a
property of the note on/off events, or
> does anyone here know if splitting code across different files, or for
> that matter, reordering the layout of one source file so that
> functions called together are now "far apart" can actually affect
> execution speed?
Not on x86, at least since we have a flat address space. I don't know abo
Paul Davis <[EMAIL PROTECTED]> wrote:
> i'll try the trick of a single to-be-used-by-the-compiler file that
> just includes all the others, and see if that helps things.
Please post your results if you find anything conclusive. I had never
considered the effects of how functions are distributed b
>Yupp, I see. I get a 7 percent penalty compaired to doing
>the same just in one process.
right. now try it with 8 different processes, all of them touching
enough (different) data to invalidate a random selection of about 80%
of the cache. or better yet, just take our word for it that the cost
of
On Sun, 8 Dec 2002, Paul Davis wrote:
> Kjetil and i have been boring the VST crew to death. so we took it
> here :)
>
> >> because when running a real-time low-latency audio system, the cost of
> >> context switches is comparatively large. if you've got 1500usecs to
> >> process a chunk of audi
Frank,
I agree with your comments. I'd also like to see the developers at
least understand and consider these sorts of protocols also. In the end
something good will come out of it.
Actually, the use of MIDI velocity information is a strong selling
point of GigaStudio. In GigaStudio you can
On Sun, Dec 08, 2002 at 10:35:39AM +, Steve Harris wrote:
> On Sun, Dec 08, 2002 at 12:26:32 +, Nathaniel Virgo wrote:
> > I think velocity is special because it is often needed by the synthesis
> > algorithm only at the beginning of the note. For instance, if you have a
> > physical mo
> From a 'C optimisation tutorial'
>
>http://www.abarnett.demon.co.uk/tutorial.html
>
># Compilers can often optimise a whole file - avoid splitting off
>closely related functions into separate files, the compiler will do
>better if can see both of them together (it might be able to inline the
From a 'C optimisation tutorial'
http://www.abarnett.demon.co.uk/tutorial.html
# Compilers can often optimise a whole file - avoid splitting off
closely related functions into separate files, the compiler will do
better if can see both of them together (it might be able to inline the
code, fo
does anyone here know if splitting code across different files, or for
that matter, reordering the layout of one source file so that
functions called together are now "far apart" can actually affect
execution speed?
--p
Kjetil and i have been boring the VST crew to death. so we took it
here :)
>> because when running a real-time low-latency audio system, the cost of
>> context switches is comparatively large. if you've got 1500usecs to
>> process a chunk of audio data, and you spend 150usecs of it doing
>> contex
Please follow-up this discussion to LAD.
On Sun, 8 Dec 2002, Paul Davis wrote:
> >> the situation, as i said before, is miserable. we just don't have a
> >> situation in linux where a single point of control can say "*this* is
> >> the GUI toolkit you will use". X is clearly the standard, but
On Sun, Dec 08, 2002 at 01:26:27 +0100, David Olofson wrote:
> > > Ok. (But VSTis can be multichanne/multipart, AFAIK.)
> >
> > OK, but thier still instruments :)
>
> Yes - but there's only one instance for N channels. :-)
Right, but isn't that what were planning?
- Steve
On Sun, Dec 08, 2002 at 03:11:16 -0800, Tim Hockin wrote:
> > > Uggh, can we keep the get() of control values simpler than events? My
> > > previos proposal had a control->get() method and a ctrl->set() method.
> > > Obviously, the set() is superceded by events. Is the get, too?
> >
> > What is
On Sat, Dec 07, 2002 at 09:52:28 -0800, Tim Hockin wrote:
> Do we really want to have different controls for different channels? I can
> see how it might be neat, but since multiple channels is convenient
> for hardware people, shouldn't we leave the controls the same, too? :)
Sounds sensible.
On Sat, Dec 07, 2002 at 04:02:07 -0800, 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 will still be simpler.
>
49 matches
Mail list logo
