[PD] [datastruct] calculations inside drawing instructions
fbar at footils.org
Sat Apr 9 14:25:39 CEST 2005
federico hat gesagt: // federico wrote:
> i looked at that patch, but it is not so good... really it allows you to
> set more parameters than needed.
Yes, it's not really meant as a useable adsr-abstraction, it's just
a little example to explain arrays.
> here i notice the absence of separation between model's data and view's
> data (did you ever hear about MVC concept?).
> practically: the view part (V) shows some values, but the model part (M)
> keep other values. in addiction: the V part translate user input (on
> itself) into values suitable for data, and viceversa, when model's data
> changes, the view updates itself.
> if [drawpolygon] (and other drawing instructions) could (should!) do
> calculations inside them, this part would be done automagically.
> just for a structure like this, it is a pain in the ass maintain M and V
> in sync. (i can't still make a full working example). imagine yourself
> what could happen with a more complex structure.
> in addition, having model separate from view, allows you to have many
> views that belongs to one data-structure, and this is good.
Comments like these are very important. Before I published my data
structures tutorial, practically no one was using data structures,
judging by the DS-related traffic on this list, although this feature
is present in Pd for a very long time. This led to a chicken-egg
problem: without user feedback, DS continued to feel a little awkward;
and because DS feel this way, people didn't use them.
As useful as computations would be in your use case and in many other
possible cases, one problem is still unsolved: How should the
computations be represented in Pd's language?
Probably they cannot (?) be in the data structure [struct] itself, so
they might go into the drawing instructions. Now how could a [drawX]
look like? A very simple application would be drawing the negative
value of a struct:
[struct s float n]
This looks natural and could be very useful. But if you take this
further, [drawnumber] would in the end become something like [expr]:
How should we deal with whitespace?
[drawnumber exp(2, n)]
And what should happen if the structure was defined like this:
[struct s float n float exp]
IMO because of these problems [drawX] may be not such a good place for
My (still very fuzzy) ideas to solve the problem would be to add some
kind of "update trigger" or "callback" to the data structure system.
That would actually follow the MVC pattern a bit, where you also have
to send some kind of messages between the participants to notify them
of changes and actions than happened.
Basically you and I already did something like that using the Mouse
watching objects from cyclone to intercept changes done with the mouse
using [mousefilter] etc., do some computations (for which Pd already
has sufficiently enough objects), and then update and [set] the data
structures accordingly. Polling is another possibility.
But it would be nicer if the DS had some kind of [supermousefilter]
built in, which not only filters mouse-ups but could intercept, check
and change all messages to data structures. Which is something like
the Controller. ;)
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
More information about the Pd-list