[LV2] Powered By Ingen

Michael Fisher mfisher31 at gmail.com
Sun Jun 30 00:04:16 PDT 2013


On Sat, 2013-06-29 at 14:53 -0400, David Robillard wrote:
> On Wed, 2013-06-26 at 14:49 -0500, Michael Fisher wrote:
> > Hello all,
> > 
> > I was wondering what the intentions for using Ingen as a shared library
> > are.  Is this so I can manage an Ingen::World myself, create my own
> > clients, start the jack engine, etc, etc?  I noticed headers for the
> > server aren't installed.
> > 
> > I'm aiming at starting yet another audio/midi sequencer.  Some how some
> > way I want to power the engine primarily with LV2 technology and Ingen
> > graphs.  The idea behind graph usage is to layout processing logistics
> > in the sequencer and also be used as a standard "instrument" format.
> 
> The public library API is still in its infancy and is not currently used
> by anything other than Ingen itself.  It should be possible to do
> everything Ingen the program does, though some things are indeed private
> like server internals.
> 
> > Hypothetically a "Sequence" could be some kind of derived graph, which
> > manages some "Track" blocks (not sure how clip/regions of data would fit
> > in yet).  And through the nature of ingen graphs, sequences
> > theoretically can be nested inside of one another (kind of like what you
> > see in Adobe Premiere)
> 
> There is work that needs to be done here in terms of new plugins and
> support for them and so on, which is orthogonal to using Ingen as a
> library.  Essentially if you can't patch it in the GUI, you can't do it
> period.
> 
> Personally I would address being able to do what you want in the first
> place before trying to wrap a new custom app around it, which is a bunch
> of additional complexities and only useful in one use case as opposed to
> many.
> 
> > So obviously a full fledged midi sequencer + capture isn't really doable
> > with the stock ingen jack/server, but from what I've seen in the code
> > there's potential for just about anything audio-wise and could easily be
> > used as a starting point.
> 
> Moving around time might be tricky, but otherwise I'm not so sure.  By
> sending events around you can do pretty much anything.
> 
> > Dave, what do you think.  What would be a decent way to derive new
> > Internal blocks and graphs?  The only thing I can tell with current
> > materials, is just write my own engine or copy the stock engine and use
> > it as a starting point.  Or is this probably a bad idea?  It would be
> > nice to code things in a manner where I can offer patches to Ingen where
> > applicable.
> 
> The core of the Ingen Philosophy(TM) is that internals should not exist
> unless there is some good reason why they have to.  Everything should be
> done by plugins.
> 
> Internals are only for cases where the implementation needs to interact
> with the Ingen internals in a way that's not reasonable to add to the
> general LV2 API.
> 
> > I'm looking for ways to not re-invent the wheel and so far the LV2 model
> > makes the most sense to me, even at the application level.
> 
> In general, yes, this is very much what I've had in mind for the tool.
> Just as those in the Pd and Max worlds build very advanced environments
> in their tools, it should be possible to build anything you want in
> Ingen, including sequencers and other things with logic in them.  I'm
> all for work in this direction.

Thanks, that all brings things into light.

> 
> Personally I think the more interesting thing, and what needs doing
> first, is designing how to build such things in a graph, writing the
> necessary plugins, etc.  An app that uses Ingen as a library may be able
> to do fancy other things, but should not be necessary, and also strikes
> me as an overly ambitious project less likely to make tangible usable
> progress (this has happened before).

Now that I've have a better understanding, I agree though... writing the
necessary plugins and how those belong in a graph environment should be
first.  And would be useful elsewhere while doing so (potentially)

What would be a good generic way

What would you say for audio/event capture.  Should this also be done
with plugin(s)?  I suppose such a plugin would using Make Path.

> 
> Cheers,
> 
> -dr
> 






More information about the Devel mailing list