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

Andy Farnell padawan12 at obiwannabe.co.uk
Tue Nov 1 17:41:30 CET 2016


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: Digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161101/4f41b445/attachment.sig>


More information about the Pd-list mailing list