Re: [PD] [pdconv16_r] Expanding abstractions & Compiling Vanilla Patches As Objects (Gen~?)
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?
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.
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.
Cheers
2016-11-01 8:42 GMT-02:00 Pierre Guillot guillotpierre6@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
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@gmail.com wrote:
2016-11-01 8:42 GMT-02:00 Pierre Guillot guillotpierre6@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
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@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@gmail.com> wrote:
2016-11-01 8:42 GMT-02:00 Pierre Guillot guillotpierre6@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
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@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@gmail.com> wrote:
2016-11-01 8:42 GMT-02:00 Pierre Guillot guillotpierre6@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
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 padawan12@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.alex@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@gmail.com> wrote:
2016-11-01 8:42 GMT-02:00 Pierre Guillot guillotpierre6@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
@Alewandre Sorry, I just realize that I misunderstood the first mail. When you spoke about [inlet~], I thought about the inlets of the objects and not the inlets of the abstractions. My approach is for for externals so perhaps that should be another subject for the round table?
It seems that Enzien audio reinterprets the pd patches and doesn't use the pd code. If this framework acts like gen, it probably generates an pre-optimized C code from a patch (and then the compiler can compile and perform the optimizations). Perhaps I'm wrong but I think that there is a reason why Enzien audio doesn't use the pd code and why gen uses its own objects and not the native dsp objects: they had to rewrite all the code of the objects. I mean, if we want to convert a patch to a perform method (we simplify the approach by limiting the patch to the dsp objects only), the gen-like object have to know the textual form (or an equivalent) of the perform methods of all the objects. But for the moment, we can only retrieve the addresses of the perform methods and even if we implement a mechanism to retrieve these methods as text, we still have to rethink their syntaxes (because they are surely not usable and not optimized for the new context). Perhaps my explanations are not really clear and perhaps I should keep that for the irl discussion... I just think that such application amounts to recreate a brand new software. It would be great but it would require a lot of work. Considering the existing projects like libpd, FAUST or even Enzien audio, does the prize justify the cost? Sorry if it seems that I want to nip the project in the bud :)
2016-11-01 17:41 GMT+01:00 Andy Farnell padawan12@obiwannabe.co.uk:
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@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@gmail.com> wrote:
2016-11-01 8:42 GMT-02:00 Pierre Guillot guillotpierre6@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
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@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@gmail.com wrote: 2016-11-01 8:42 GMT-02:00 Pierre Guillot guillotpierre6@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@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
-
Alex Norman -
Alexandre Torres Porres -
Andy Farnell -
Ed Kelly -
Joe White -
Pierre Guillot