[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