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 <padawa...@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.a...@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 < > > > por...@gmail.com> wrote: > > > > > >> 2016-11-01 8:42 GMT-02:00 Pierre Guillot <guillotpier...@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@lists.iem.at mailing list > > >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > > >> > > >> > > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list