[PD] [pdconv16_r] Expanding abstractions & Compiling Vanilla Patches As Objects (Gen~?)
Alexandre Torres Porres
porres at gmail.com
Tue Nov 1 17:12:08 CET 2016
> More generally, it would be great if abstractions could do
> anything a compiled object could do.
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...
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.
> 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~
>>> > 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
>> 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
>> > 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
>>> in my dummy library.
>> awesome, it's be great to have something like this in vanilla in order to
>> improve the design of abstractions ;)
>> 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...
More information about the Pd-list