So, I've been playing with scalars a bit and am still not quite sure I understand how to actually create a new object/instance on canvas window that can then use templates etc.
All tutorials already have those created and while I can change their properties, I cannot for the love of the world figure out how to create a new instance from scratch without copying and pasting existing one. Copy/paste obviously works but how to create first one from scratch? In other words, how does one create such an object in their own patch without having to resort to copying and pasting from tutorial patches? Or to put it more simply, what is the "create canvas object" method?
Thanks!
ico
Never mind. Figure it out...
that said, FWIW this part may need better coverage under the "scalar" help file which pops up when one selects help on it. The other confusing thing is when you pull up properties for a scalar object on the graph that the window that pops up is titled misleadingly "Atom".
Ico
for a very simple automatic scalar creation, look at my abs
jmmmp/pd-colors. I'm sure you'll understand it easily.
there are many things that should be improved on data-s, so that they're
really usable on more complex compositional contexts, and not only to draw
some fancy guis. but since this is a very obscure area of pd, don't know
if much energy will be put in there.
Never mind. Figure it out...
that said, FWIW this part may need better coverage under the "scalar" help file which pops up when one selects help on it. The other confusing thing is when you pull up properties for a scalar object on the graph that the window that pops up is titled misleadingly "Atom".
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
I sent Miller an idea the other day about making data structures more expressive. Basically allowing subpatches (including abstractions) to be defined as a field of a struct.
[struct ex1 float y float i glist foo pd-bar] <-- glist field "foo" using [pd bar] as a template
So let's say you make a ds array using [struct ex1] above as the template for the elements. Now when you [setsize] to 40, each element has an associated "foo" field which is actually a subpatch. To define a "subpatch template" for foo, you'd just put [pd bar] in the same subpatch as [struct ex1].
The real power of this would come by being able to access the other ds fields from within the "foo" subpatch. So maybe having some objects for getting a scalar's data from "within" the scalar:
[getmy y i] <-- used within the "foo" subpatch, this will output the values of the fields when banged.
[setmy y i] <-- same for setting. (Since we're already inside the scalar there's no need for sending pointers.)
[notify] <-- output "change", "select", etc. messages only when they refer to this scalar
Local variables! Deleting abstraction instances with [setsize]! The possibilities are endless!
I have no idea how to program any of this!
-Jonathan
--- On Tue, 5/11/10, João Pais jmmmpais@googlemail.com wrote:
From: João Pais jmmmpais@googlemail.com Subject: Re: [PD] understanding graphics objects on canvas To: pd-list@iem.at, "Ivica Ico Bukvic" ico@vt.edu Date: Tuesday, May 11, 2010, 1:29 AM
for a very simple automatic scalar creation, look at my abs jmmmp/pd-colors. I'm sure you'll understand it easily.
there are many things that should be improved on data-s, so that they're really usable on more complex compositional contexts, and not only to draw some fancy guis. but since this is a very obscure area of pd, don't know if much energy will be put in there.
Never mind. Figure it out...
that said, FWIW this part may need better coverage under the "scalar" help file which pops up when one selects help on it. The other confusing thing is when you pull up properties for a scalar object on the graph that the window that pops up is titled misleadingly "Atom".
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[struct ex1 float y float i glist foo pd-bar] <-- glist field "foo"
using [pd bar] as a template
I think this would be a good idea. specially if you can change the patch
name, and the structure "jumps" as well between subpatches.
two other things I just remember now:
- click/move/change reports for scalars are quite good, because it's very
easy to know which scalar is being edited/active. but they should also be
integrated in arrays.
- as great as the improvements might be, the work will be only partial if
the gui doesn't get improved. since data structures depend 100%
graphically on tcl/tk graphics, they're very slow to work with, if you're
doing something complex. in order for data structures to be more widely
used on realtime patching/editing, the tcl/tk graphical code should be
more efficient.
- give a nameable string to each data-s, which keeps during sessions. this
way is easier to get a determinate data-s in the middle of a big window.
for now it's necessary to go through all the scalars in the window, and
match any inner parameters (an index, a symbol, etc.)
Data structures can be a very powerful mean to graphically
display/interact with the patch (to perform, display, compose, ...). But
without some improvements they'll still be a hidden part of pd. And afaik,
this is the only major feature that separates pd from max - but maybe I'm
wrong?
-
Ivica Ico Bukvic -
Jonathan Wilkes -
João Pais