> > Yeah, but is it really that useful? Ok, VST seems to survive with the > > same restriction, but I'm not sure if it actually solves more > > problems than it creates. > > Agreed, in practice you can connect things together if you allow arbitrary > ranges.
Well, at some point we talked about hardlimited ranges. If we have a control that has hardlimited ranges, and you connect joe random to it, it can go out-of-bounds and blow up. Either all controls check their own bounds, or we have to provide scalar plugins to convert control streams, or we normalize controls. We have a few classes of numerical value controls: unbounded (one or both bounds are infinite) bounded (both bounds are well-defined) enum (a special class of bounded) positive only negative and positive (zero-centered, hopefully) It's hard to normalize for all these. 0-1.0 can make sense for bounded, but is useless for unbounded. hrrmm.. > > Yeah, that would be reasonable, I think. In the few cases where > > plugins can't be in-place safe (or the author is too lazy), we even > > have a nice, cache friendly solution: The audio buffer pool. (A LIFO > > stack of preallocated buffers. Optimized hosts will probably use one > > anyway, instead of fixed buffers all over the net.) > > Hmmmm.... not convinced. If a plugin can flag itself as in-place-safe, is that good enough? We then push that into the host, which is OK, I guess. > > > Well, there also needs to be a way for a plugin to wrap other > > > formats, and change all it's metadata. I imagined that a plugin > > > couls tell the host that it needs to be re-examined - > > > XAP_EV_GESTALT - or something. > > > > Yeah. > > Ugh! Better ideas welcome... We need to change the meta-data as a function of some control. Perhaps wrappers need special attention? Add a flag that says they are a wrapper, and a flag on the control that changes the universe? What if it is multiple controls? > > Yeah. run_adding() is indeed nothing but a performance hack. Question > > is if we really need it these days. I'm not saying that we'll ever > > have enough cycles to just waste them, but focus is shifting > > continously. Things are getting higher level. > > I disagree. Its really quite expensive. So we standardiz: if your plugin provides MIX_WET and MIX_DRY controls, the host can use those and you assume run_adding() behavior. If you do not provide those, you are replacing. If you want to supprt run_adding() behavior, you need to specify those two controls (or is one percentage control enough ?) The host still only calls run(), but if you provide those, it can use you without a send-return loop. Is that good enough? This is what hints are there for, after all. Tim
