I've thought a bit more about the subject. I find that a realisation of the idea on top of a custom gui object could have some rough edges:
(i) the code is not given at creation time, so if the number of inlets/outlets is to be inferred from it, pd objects should support adding/removing of inlets/outlets after object initialization. Is this possible?
(ii) maybe the object will show itself in outer abstractions when contained in inner abstractions with graph-in-parent activated. Is it possible to avoid this?
I ask the above to the pd savvy in order to determine if it's viable to go this way.
TIA
Cheers,
Carlos
On 6/30/07, Carlos Pita <carlosjosepita@gmail.com> wrote:
Hello all,
I think there are at least three ways to go with this:
1) reassemble the code from atoms.
2) provide a object with a gui specialized for code edition.
3) provide some symbol escaping syntax so that, for example, everything between << and >> will be taken as a single symbol by pd.
I think 2, although a bit laborious, fit best to the goal of code edition. We could treat code as a single string, instead of dealing with symbols, and we could even (this is wishful thinking) provide some syntax highlighting and formatting. I'm pretty new to pd but I guess I could take g_bang.c and friends as examples to start working with.
Cheers,
Carlos