> 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 <[email protected]>: > 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 < > [email protected]> wrote: > >> 2016-11-01 8:42 GMT-02:00 Pierre Guillot <[email protected]>: >> >>> 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 >> >> ------------------------------ >> >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
