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

Ed Kelly morph_2016 at yahoo.co.uk
Thu Nov 10 19:57:24 CET 2016


I did something similar with wrap_overshoot~ which wraps signals only when a block boundary is reached...to be shown and released at pdcon16~Cheers,Ed
 Lone Shark releases: Light Vessel Automatic available now on 12" vinyl.Build Your Wings on the Way Down, the new digital album available @ http://scifirecords.co.uk/releases 
Earthlings compilation is out now @ http://www.pyramidtransmissions.com

Ninja Jamm - the revolutionary music remix app for iOS and Android: http://www.ninjajamm.com/

Gemnotes-0.2: Live music notation for Pure Data, and Metastudio 5 live composition and improvisation suite, available at http://sharktracks.co.uk/puredata 

    On Tuesday, 1 November 2016, 15:57, Alex Norman <x37v.alex at gmail.com> wrote:
 
 

 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 usean 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 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161110/8cb62916/attachment.html>


More information about the Pd-list mailing list