would be nice an embedded text editor for pd patches. yes, I mean an editor to see/edit the patch source file directly, and that is visually linked in both directions [source/gui], so selecting and object would locate its code in the editor, and editing the code would react the changes to the object itself.
this is more handy for some tasks, e.g. I want to re-create dynamically an object with pd-win-messages.... or insert new objects interactively by typing the code... :) (maybe I have some programs that can generate sequential garbage of text more quickly than CTRL+C,CTRL+V,edit... hehe)
more nice would be some way to access portion of memory by other programs, in order to let external C programs modify a patch in puredata.... but I think this is still "sci-fi"
all the best
We really don't want to get into maintaining a text editor in Pd when
there are so many good ones maintained by other people. But yes, a
way to work with the text files would be handy. Even better would be
to make Pd better so that you don't have to edit the text files
directly.
.hc
On May 5, 2006, at 11:17 PM, Federico wrote:
would be nice an embedded text editor for pd patches. yes, I mean an editor to see/edit the patch source file directly,
and that is visually linked in both directions [source/gui], so
selecting and object would locate its code in the editor, and
editing the code would react the changes to the object itself.this is more handy for some tasks, e.g. I want to re-create
dynamically an object with pd-win-messages.... or insert new
objects interactively by typing the code... :) (maybe I have some
programs that can generate sequential garbage of text more quickly
than CTRL+C,CTRL+V,edit... hehe)more nice would be some way to access portion of memory by other
programs, in order to let external C programs modify a patch in
puredata.... but I think this is still "sci-fi"all the best
-- Federico
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
On Sun, 7 May 2006, Hans-Christoph Steiner wrote:
We really don't want to get into maintaining a text editor in Pd when there are so many good ones maintained by other people. But yes, a way to work with the text files would be handy. Even better would be to make Pd better so that you don't have to edit the text files directly.
Getting a text editor in Pd means writing it ourselves instead of using one that already exists. It's also not relevant that there exist so many good editors if they aren't integrated with pd because as long as they aren't integrated with pd they're not an alternative to writing our own pd-specific text editor.
Then the question is whether it's easier to embed pd inside an existing text editor or to embed an existing text editor inside pd. Well, another question is whether someone really wants to tackle the challenge...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
sorry for the delay, I've been very busy
Mathieu Bouchard wrote:
On Sun, 7 May 2006, Hans-Christoph Steiner wrote:
We really don't want to get into maintaining a text editor in Pd when there are so many good ones maintained by other people. But yes, a way to work with the text files would be handy. Even better would be to make Pd better so that you don't have to edit the text files directly.
Getting a text editor in Pd means writing it ourselves instead of using one that already exists. It's also not relevant that there exist so many good editors if they aren't integrated with pd because as long as they aren't integrated with pd they're not an alternative to writing our own pd-specific text editor.
Then the question is whether it's easier to embed pd inside an existing text editor or to embed an existing text editor inside pd. Well, another question is whether someone really wants to tackle the challenge...
maybe i drove the question too far.
having a text editor in pd maybe is too much. a simpler thing would be the ability to copy the object code to clipboard. this is just an idea that comes to me, thinking that there are several lacks for what concerns "dynamic patching". just to enumerate some:
- a pd-object that gives the actual number of objects in the current
patch (if one needs to do dynamic patching inside an abstraction which already has several object, he has to count objects, and hardcode that number in a float... and on every modification should update this count.... booring!)
- ability to resize the GOP patch from inside itself (via messages)
- ability to change a property for a group of (homogeneous) selected
objects (i.e. change the width of 100 sliders)
- ability to distribute horizontally or vertically a group of selected
objects
maybe there are things more important than others... here you can see various problems and their solution. choosing the right way for solving those problem is crucial
bye
>
On Wed, May 17, 2006 at 07:14:52PM +0200, Federico wrote:
- a pd-object that gives the actual number of objects in the current
patch (if one needs to do dynamic patching inside an abstraction which already has several object, he has to count objects, and hardcode that number in a float... and on every modification should update this count.... booring!)
- ability to resize the GOP patch from inside itself (via messages)
- ability to change a property for a group of (homogeneous) selected
objects (i.e. change the width of 100 sliders)
- ability to distribute horizontally or vertically a group of selected
objects
How about adding these to the feature tracker on sourceforge after checking whether or not they are already in the TODO file?
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
-
Chris McCormick -
Federico -
Hans-Christoph Steiner -
Mathieu Bouchard