> > 2) Do we need a run_adding() form of run()?
>
> Yes - but we should only encourage it for small/fast plugins that are
...
> Is this really worth messing with? This is starting to sound like
> silence handling with plugin granularity...
...
> Well, there's another issue. For this to be tr
> > > > no, it restricts users in ways EXACTLY intended by the authors.
> > >
> > > Unless the author just intended to hint a useful range for a
> > > control that doesn't have obvious limits. There's no way to do
> > > that if ranges are hard.
> >
> > That _CAN_ be solved,
>
> How? All ideas are
On Saturday 08 February 2003 06.51, Tim Hockin wrote:
> > > Flip on the LEARN control, do your stuff. When you flip off
> > > the LEARN control a raw-data output is updated. We don't even
> > > need to use a hint for LEARN - it is totally plugin unique.
> >
> > Right. As long as there is suitable
On Saturday 08 February 2003 06.48, Tim Hockin wrote:
> > > > However, I don't like the idea of making all controls have
> > > > hard ranges. It restricts the users in ways not necessarily
> > > > intended by plugin authors, since there's no way to set
> > > > controls to values
> > >
> > > no, it
On Saturday 08 February 2003 06.21, Tim Hockin wrote:
> Items we haven't agreed to a solution on (or that I missed the
> solution for :)
>
> 1) Do plugins load the default value for all their controls or do
> we have to send an event for data they already know?
There is one rather strong motivatio
> > Flip on the LEARN control, do your stuff. When you flip off the
> > LEARN control a raw-data output is updated. We don't even need to
> > use a hint for LEARN - it is totally plugin unique.
>
> Right. As long as there is suitable control datatypes, no additional
> support is needed, really.
On Saturday 08 February 2003 06.19, Tim Hockin wrote:
> > > BUT (you knew that was coming): the wrapped plugin is kind of a
> > > parameter, more than a control. Changing the parameter can
> > > change the ENTIRE metadata of the plugin.
> > >
> > > Maybe we should formalize that?
> >
> > We could
> > > However, I don't like the idea of making all controls have hard
> > > ranges. It restricts the users in ways not necessarily intended
> > > by plugin authors, since there's no way to set controls to values
> >
> > no, it restricts users in ways EXACTLY intended by the authors.
>
> Unless th
On Saturday 08 February 2003 05.53, Tim Hockin wrote:
> [ arguing get/set_extra_state()...]
>
> > Oh wait, there's one more difference. If we just assume that this
> > is data that the plugin wants to store whenever you save a
> > project, we have major issue: A project will *change* in
> > non-obv
On Saturday 08 February 2003 05.38, Tim Hockin wrote:
> > > Functions are handy when the calling conventions
> > > of both parts are compatible. If the language you use
> > > doesn't support this convention natively, all functions
> > > have to be wrapped, which is a real pain.
> >
> > Really?
>
>
Items we haven't agreed to a solution on (or that I missed the solution for
:)
1) Do plugins load the default value for all their controls or do we have to
send an event for data they already know?
2) Do we need a run_adding() form of run()? If so what are the semanitcs
and how to specify the
> > BUT (you knew that was coming): the wrapped plugin is kind of a
> > parameter, more than a control. Changing the parameter can change
> > the ENTIRE metadata of the plugin.
> >
> > Maybe we should formalize that?
>
> We could hint the Control as "will cause metadata changes!", but who
> care
On Saturday 08 February 2003 05.13, Tim Hockin wrote:
> > > I'm questioning whether
> > > having a simpler query based system may be easier. I don't
> > > like the idea that you have to instantiate to query, though.
> >
> > Many plug-in standards require instanciation before fetching
> > propertie
[ arguing get/set_extra_state()...]
> Oh wait, there's one more difference. If we just assume that this is
> data that the plugin wants to store whenever you save a project, we
> have major issue: A project will *change* in non-obvious ways if you
> repeatedly play and save, without explicitly
> > Functions are handy when the calling conventions
> > of both parts are compatible. If the language you use
> > doesn't support this convention natively, all functions
> > have to be wrapped, which is a real pain.
>
> Really?
I don't think it is such a pain. I'd rather penalize the wrapping s
> > I'm questioning whether
> > having a simpler query based system may be easier. I don't like the idea
> > that you have to instantiate to query, though.
>
> Many plug-in standards require instanciation before fetching
> properties. PTAF must be able to make good wrappers for existing
> plug-in
> > Let's just say that all ranges are suggestions, and if it matters,
> > it is the plugin's problem. If we later find this to be a big
> > problem, we'll deal with it. Fair?
>
> Yeah. Works for LADSPA, so it can't be *that* bad.
Unless anyone objects with good arguments, I'm putting it in my
Should the sustain pedal work yet?
Nasca Paul wrote:
Hi.
I relased ZynAddSubFX 1.0.7 .
News:
- some settings (like samplerate) are set at runtime
(by comand line)
- added Distorsion effect
- added controllers, and NRPNs for changing all
effects parameters by midi
- bugs removed
On Saturday 08 February 2003 02.17, Tim Hockin wrote:
[...]
> Assuming we really want to allow soft-limits (which I just don't
> get), we can just say that if you want a hardlimit, constrain it
> internally.
Yeah.
As to soft limits, I think the main point is to relieve the plugin
author of the t
> > > something out... It just seems to me that plugins have a better
> > > idea how to clamp - and they can quite often use constant limits
> > > as well, I guess.
> >
> > I'm fine with this. If the plugin can constrian the inputs itseelf,
> > it seems reasonable not to have explict host support.
On Friday 07 February 2003 23.07, Steve Harris wrote:
[...]
> > You might ove the conditionals around a bit depending on which
> > case you want to be the fastest, but I don't think it gets much
> > more fun than that.
>
> The are branchless clamps, which save a few cycles.
Cool. Would your averag
On Fri, Feb 07, 2003 at 10:04:54 +0100, David Olofson wrote:
> Yeah, that's nasty as well - but not nearly as nasty as forcing
> *outputs* to clamp to the range of whatever inputs you connect them
> to.
Sure.
> > Maybe the host could signal that a control might go out of range
> > and the SDK
On Fri, Feb 07, 2003 at 09:38:46 +0100, David Olofson wrote:
> Yeah - but not as cheap as generating occasional spikes, a tone or
> maybe even white noise, to prevent the generation of denormals in the
> first place.
>
> Besides, if you *get* a denormal to kill, it has to come from
> somewhere.
On Friday 07 February 2003 21.14, Steve Harris wrote:
> On Fri, Feb 07, 2003 at 03:22:27 +0100, David Olofson wrote:
> > On Friday 07 February 2003 11.07, Steve Harris wrote:
> > > On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > > > > It sounds like the wrong thing, the general cas
On Friday 07 February 2003 21.02, Steve Harris wrote:
[...]
> > Well, casting to int avoids getting the denormal into the FPU.
> > This is probably the only safe way to deal with a denormal
> > without forcing the FPU to burn cycles evaluating it. I don't see
> > how this has anything to do with th
On Fri, Feb 07, 2003 at 03:22:27 +0100, David Olofson wrote:
> On Friday 07 February 2003 11.07, Steve Harris wrote:
> > On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > > > It sounds like the wrong thing, the general case is that the
> > > > host generates values its knows to be in
On Fri, Feb 07, 2003 at 02:16:08 +0100, David Olofson wrote:
> On Friday 07 February 2003 10.55, Steve Harris wrote:
> > On Thu, Feb 06, 2003 at 11:13:45 +0100, David Olofson wrote:
> > > On Thursday 06 February 2003 16.28, Steve Harris wrote:
> > > [...]
> > >
> > > > #define FLUSH_TO_ZERO(fv) (((
This synth gets better and better.
For those who haven't used it, it is amazingly deep in capabilities, and
really pretty free of major problems (in my experience) for such a new piece
of software.
You owe it to yourself to check it out.
> -Original Message-
> From: [EMAIL PROTECTED]
> [
On Friday 07 February 2003 11.07, Steve Harris wrote:
> On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > > It sounds like the wrong thing, the general case is that the
> > > host generates values its knows to be in range, then the plugin
> > > checks it again to check its in range..
On Friday 07 February 2003 10.55, Steve Harris wrote:
> On Thu, Feb 06, 2003 at 11:13:45 +0100, David Olofson wrote:
> > On Thursday 06 February 2003 16.28, Steve Harris wrote:
> > [...]
> >
> > > #define FLUSH_TO_ZERO(fv) (((*(unsigned
> > > int*)&(fv))&0x7f80)==0)?0.0f:(fv) I think it came fr
On Friday 07 February 2003 10.19, Tim Hockin wrote:
> > If we allow hard ranges (not really neccesary, as LADSPA shows)
> > then the host should enforce them.
>
> Remind me why we want soft ranges?
This is to avoid having later "extended" versions of plugins that just
let you use a wider range fo
On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > It sounds like the wrong thing, the general case is that the host
> > generates values its knows to be in range, then the plugin checks
> > it again to check its in range...
>
> Not the host; the *sender*. That is the sequencer (whic
On Fri, Feb 07, 2003 at 12:56:38 +0100, David Olofson wrote:
> I say we should make it as simple as strongly recommending that
> plugins with algorithms that tend to generate denormals easily,
> should deal with it in a suitable way. Sounds both better and easier
> to me.
Agreed, plugins that c
On Thu, Feb 06, 2003 at 11:13:45 +0100, David Olofson wrote:
> On Thursday 06 February 2003 16.28, Steve Harris wrote:
> [...]
> > #define FLUSH_TO_ZERO(fv) (((*(unsigned
> > int*)&(fv))&0x7f80)==0)?0.0f:(fv) I think it came from the
> > music-dsp list.
>
> There's a conditional in there, thou
On Thu, Feb 06, 2003 at 06:03:47 +0100, Dave Griffiths wrote:
> > It happens on all IEEE machines, though on some (eg. the PS2's vector
> > units) you can turn it off.
> >
> > If your machine is memory bound then you wont notice as much.
> >
> > > Cheers for the info guys, I haven't come across
> If we allow hard ranges (not really neccesary, as LADSPA shows) then the
> host should enforce them.
Remind me why we want soft ranges? I'm more of the mind that all ranges are
hard ranges, except for {pos/neg} infinity.
If a control is going to the effort of specifying a range, don't we want
36 matches
Mail list logo
