[PD] Google Summer of Code WIKI

David Powers cyborgk at gmail.com
Sun Mar 4 03:54:49 CET 2007


I think this idea is awesome too ... very useful for me personally,
and would be sure to bring more PD users.
~David

On 3/3/07, Luke Iannini (pd) <lukexipd at gmail.com> wrote:
> Yeah. Kyle pretty much summed it up there.  This is something I've
> wanted badly since I first saw Pd.  It took me months to get a stable,
> workable setup between Cubase and Pd, and even now, I could finally
> take up knitting with the time a Pluggo for Pd would save me.  Futzing
> with Jack and OS X IAC every time I want to make noise is a monstrous
> PITA.
>
> I've attempted building large sequencers to replace Cubase on multiple
> occasions, but it just doesn't make sense to duplicate that effort
> (and that's assuming Pd's data structures are ready for such a thing
> performance-wise, which they are not).
>
> So a huge vote for PluggoPd!
>
> The Naspro project that Tim mentioned was exactly what I thought of
> when I first saw this idea... I'm glad to see it is being developed;
> the myriad plugin formats are a tedious situation.
>
> Luke
>
> On 3/3/07, Kyle Klipowicz <kyleklip at gmail.com> wrote:
> > There already is a jack VST and Audio Unit for OSX, that's not the
> > issue. What I really want is to just be able to run one master app (my
> > DAW) and have everything else loaded from there, so that I don't have
> > to do the whole 30 mins of configuring and opening corresponding files
> > and settings, stored in directories across the computer thing.
> >
> > It's a pain to have to adjust and load setting after setting when it
> > could all be saved in a nice project file in a professional sequencer
> > app. For those of us who like what Pd has to offer as a bus insert or
> > midi filter or general audio swiss army knife, we don't want to deal
> > with multiples of files all over the place in different spots, we just
> > want to have a nice compact project space that contains everything in
> > an intuitive way, so we can just touch and go, and save everything so
> > that we can open the project back up again exactly how we left it, all
> > automation and everything stored in the project.
> >
> > Managing automation in Pd has not been a quick and dirty thing for me,
> > and I'd prefer to leave that task to software that I'm comfortable
> > with. But to have a custom synth or effect or midi chain filter or
> > integrated graphics show work seamlessly from my DAW once I load one
> > single project file is the holy grail to me.
> >
> > Having 5 programs open and trying to wrangle the routing between them
> > for a half hour to get a song playing is less than ideal. A Pluggo for
> > Pd would help minimize the time and frustration of this by compressing
> > it all into one file that references a bank of subordinate plugins.
> >
> > ~Kyle
> >
> > On 3/3/07, Jamie Bullock <jamie at postlude.co.uk> wrote:
> > > On Thu, 2007-03-01 at 21:20 +0100, Tim Blechmann wrote:
> > >
> > > >
> > > > i've been changing some emails with stefano d'angelo, who is starting to
> > > > write a plugin wrapper, which is supposed to work with different plugin
> > > > backends (vst, ladspa ...) ... a pluggo for pd could make use of this
> > > > project in order to support several platforms out of the box. i guess,
> > > > stefano doesn't have a working prototype, yet, but it's probably a good
> > > > idea to join the development resources in order do avoid duplicate work.
> > > > his project website is http://sourceforge.net/projects/naspro/
> > > >
> > > > in general, from my knowledge of the pd architecture, running pd in a
> > > > plugin environment would require some non-trival changes, it can't be
> > > > just implemented on top of the current implementation. which means, in
> > > > some way, this has to be incorporated into vanilla pd ...
> > > >
> > >
> > > Maybe this is a very naive solution, but couldn't we solve the problem
> > > of getting audio data from PD into non-jack apps (that support some kind
> > > of plugin), by writing a very simple (LADSPA, VST, AU etc.) plugin that
> > > acts as a jack client.
> > >
> > > e.g.:
> > >
> > > Audacity -> LADSPA jack client plugin -> jack -> PD -> jack -> LADSPA
> > > jack client plugin -> Audacity
> > >
> > > The simplest case would use one 'jack client plugin' instance for each
> > > audio channel to/from PD.
> > >
> > > I've been meaning to implement this for a while, and maybe there's a
> > > glaring flaw, but I can't see it right now..
> > >
> > > Jamie
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > PD-list at iem.at mailing list
> > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> > >
> >
> >
> > --
> >
> > http://theradioproject.com
> > http://perhapsidid.blogspot.com
> >
> > (((())))(()()((((((((()())))()(((((((())()()())())))
> > (())))))(()))))))))))))(((((((((((()()))))))))((())))
> > ))(((((((((((())))())))))))))))))))__________
> > _____())))))(((((((((((((()))))))))))_______
> > ((((((())))))))))))((((((((000)))oOOOOOO
> >
> > _______________________________________________
> > PD-list at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>




More information about the Pd-list mailing list