Re: [Om-synth] Re: midi control of effects

[Dave Robillard]

On Fri, 2006-06-16 at 14:51 -0700, Scott Davidson wrote:
> On Fri, 16 Jun 2006 17:37:06 -0400, "Dave Robillard"
> <address@hidden> said:
> > On Fri, 2006-06-16 at 14:03 -0700, Scott Davidson wrote:
> > > On Fri, 16 Jun 2006 22:39:17 +0200, "Lars Luthman"
> > > <address@hidden> said:
> > > > On Fri, 2006-06-16 at 12:55 -0600, Jake Michaelson wrote:
> > > > > Thanks for the quick response, Dave. I like your idea - I would  
> > > > > describe this new node as a toggle switch: on the left of the node  
> > > > > one audio in and one MIDI in, on the right side of the node two audio 
> > > > >  
> > > > > outs.  Only one audio out would be active at any given time, and if  
> > > > > the node receives the specified MIDI message, it toggles between the  
> > > > > outs.  To get my desired result I could use this "theoretical node"  
> > > > > as follows: one audio out could route directly into the master PCM  
> > > > > out (pass-through) and the other could route through an effects patch 
> > > > >  
> > > > > and finally end up at the same PCM master out.  Sending a MIDI  
> > > > > message would simply toggle these routes (effect applied/no effect  
> > > > > applied).
> > > > 
> > > > It sounds a bit too specific - I'd rather see a node with a single MIDI
> > > > input (and possibly a control input to select the program number) and a
> > > > single audio output, where the audio output signal is a gate that is
> > > > controlled by MIDI PCs. Then it could be used with a mixer plugin or
> > > > some signal logic to create the effect/bypass thing.
> > > > 
> > > > Not that I would be opposed to anyone writing a plugin like the one you
> > > > described, of course.
> > > > 
> > > >
> > > 
> > > I like the plugin/gate idea and I respect the fact that the Node is
> > > intended to be relatively naive. However, wouldn't the original plugin
> > > node you are trying to bypass still be eating up processor cycles? Seems
> > > like this could get expensive, depending on the plugin. I guess you
> > > could put the plugin in a patch and use the existing patch-bypass
> > > functionality in conjunction with the plugin/gate, but that might get
> > > cumbersome.
> > 
> > External plugin nodes have zero runtime overhead over internal ones, if
> > that's what you mean.
> > 
> > -DR-
> > 
> 
> I was just saying that the external plugin would still be chuging away,
> potentially doing some expensive processing/FFTs. In the case that we're
> not sending it any signal to process, it would be nice to
> disable/disconnect the external plugin, or whatever the semantics are
> for LADSPA/LV2. (Apologies for not being very familiar with the plugin
> API).

Oh, you mean just a gate plugin versus literally shutting off processing
of the patch.  Om used to 'optimize' the graph like this, running only
the plugins necessary, but I removed that because of stupid DSSI plugins
needing to drive their UIs.

I suppose I can add a 'patch activate' special Node with a control rate
gate input, whether or not to actually process the patch.  Then you
could control the actual running of a patch with normal signals etc.

Hmm.. that's a big more complicated.  Obvious issue #1 is if that node
is inside the patch it's controlling, then anything feeding it won't be
run if it's off, so the state will never change.

I'll let it percolate in the brain. :)  Anyone have any ideas of how to
present patch enabling in the graph?

This is simple and already there with OSC, for the record.  Maybe just a
MIDI->OSC bridge is the right answer to your problem..
 
-Dave