[PD] [pdconv16_r] Expanding abstractions & Compiling Vanilla Patches As Objects (Gen~?)

[Joe White]

Hah, yeah that's a great idea, although you might not want to look at the C
source ;)

On 1 November 2016 at 16:41, Andy Farnell <padawan12 at obiwannabe.co.uk>
wrote:

> Its an idea I've long supported, for perhaps 10 years.
>
> But there are some subtle dangers to openness.
>
> Given the very small size of Pd patch code in relation
> to even the simplest compiled external we might agree a
> principle, a standard, an unwritten law if you like....
>
> that any pd abstraction converted by a [gen~] like mechanism
> into a compiled external, carries with it the dataflow source
> as a data chunk. That means the dataflow source is always distributed
> with it. Further the whole process is reversible with a
> "convert-external-to-abstraction" process.
>
> What we would have then is a kind of great "folding editor/compiler"
> for DSP development where two views of code are possible.
> This would be powerful in teaching C as well as data-flow with
> the same tool.
>
> Andy
>
> On Tue, Nov 01, 2016 at 02:12:08PM -0200, Alexandre Torres Porres wrote:
> > > More generally, it would be great if abstractions could do
> > > anything a compiled object could do.
> >
> > Exactly ;)
> >
> > And again, let me add, there are things like the heavy compiler,
> > https://enzienaudio.com where you can compile pd patches into optimized
> code
> >
> > how does that work? Wouldn't that be something like the "gen~" idea I
> > brought up? How hard would it be to have a compiler for a patch to be
> > turned into a coded object?
> >
> > if abstractions could do anything a compiled object could do including
> > being optimized and efficient, that would be amazing...
> >
> > cheers
> >
> > 2016-11-01 13:56 GMT-02:00 Alex Norman <x37v.alex at gmail.com>:
> >
> > > Miller did seem open to a control outlet on the inlet~ object. This was
> > > when we were discussing the clone object and how you have to pass
> messages
> > > to the first control inlet, if you have one, instead of just the first
> > > inlet always, to control the cloning operations. More generally, it
> would
> > > be great if abstractions could do anything a compiled object could do.
> > > Alex
> > >
> > > On November 1, 2016 8:47:11 AM PDT, Alexandre Torres Porres <
> > > porres at gmail.com> wrote:
> > >
> > >> 2016-11-01 8:42 GMT-02:00 Pierre Guillot <guillotpierre6 at gmail.com>:
> > >>
> > >>> Hi Alexandre,
> > >>>
> > >>> > I wonder if a thing like libpd could work as turning a vanilla
> patch
> > >>> into a
> > >>> > compiled object to be used inside pd... that'd be something like
> gen~
> > >>> in
> > >>> > max/msp.
> > >>>
> > >>> Can you be more specific ? For the moment, I think it would be
> > >>> equivalent to use an abstraction or the object [pd~] (libpd loads
> > >>> dynamically a patch so I guess that the execution of the patch
> cannot be
> > >>> optimized and except if the patch has been be somehow included
> inside the
> > >>> binary, you'll have to share the patch with the object). For me, the
> main
> > >>> advantage of gen~ is that it generates code that can be used inside
> an
> > >>> application but libpd already offers this feature. So what would be
> the
> > >>> advantage?
> > >>>
> > >>
> > >>
> > >> Well, I thought the code could be optimized somehow, which I believe
> is
> > >> something gen~ does, and that could be an advantage... but I really
> know
> > >> nothing and now it seems that is not possible.
> > >>
> > >>
> > >> > A - being able to retrieve control data from [inlet~]
> > >>>
> > >>> I did it in the Cicm Wrapper but it was pretty tricky. If you use the
> > >>> object [hoa.process~], you can send messages via a signal inlet for
> > >>> example. I'm not very proud of this because I had to hack a bit the
> inlet
> > >>> class. Now, I don't know if I must remove this feature or keep it...
> > >>> Perhaps somebody could tell/remind us if there is a reason why signal
> > >>> inlets can't receive messages.
> > >>>
> > >>
> > >> cool, there's also a [route~] object from zexy which could be
> embedded in
> > >> inlet~
> > >>
> > >>
> > >> > B - being able to know if a signal is connected to [inlet~]
> > >>>
> > >>> I also did it in the Cicm Wrapper, perhaps this feature could be
> > >>> included in the "m_pd.h" interface because for the moment you need to
> > >>> include "g_canvas.h" and "m_imp.h". Anyway, if you want a simple
> code that
> > >>> shows how to do it, I have an example
> > >>> <https://github.com/pierreguillot/pd-dummy/blob/
> master/src/connected_tilde.c>
> > >>> in my dummy library.
> > >>>
> > >>
> > >> awesome, it's be great to have something like this in vanilla in
> order to
> > >> improve the design of abstractions ;)
> > >>
> > >> cheers
> > >>
> > >> ------------------------------
> > >>
> > >> Pd-list at lists.iem.at mailing list
> > >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> > >>
> > >>
>
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161101/ed628842/attachment-0001.html>