hi miller, hi list !
using pd with the ("experimental") scalar object is painful, especially if you (like me) are trying to use it in abstractions that are used more than one time.
the problems are:
default. thus you cannot use "namecanvas my_template" within the sub, since the "set"(...) routines will fail. the "scalar"-object itself does *not* add the leading "pd-". so you have to create objects: "scalar pd-my_template float X" and "get my_template X" to address the same template. i do not think that this is consistent. it is not possible to use multiple namespaces within a subpatch (with "namecanvas"), which is ok, but does not help to work around the inconsistency.
"pd-my_template" will be created. however, this does not work with $args, so "pd $0_template" will create a namespace like "pd-$0_template" instead of (for instance) "pd-1001_template"
i considered these as bugs and tried to fix them:: so now the behaviour is as follows:
the other traversal objects 2) the $args are correctly expanded for the namespace of a subpatch
i fixed the help-files (5.reference/scalar.pd and 7.stuff/data-structures/8.panel.pd) accordingly.
the patch does not fix the instability of the traversal/scalar-objects !! (so it will keep crashing when used ;-)
since i am going to use this heavily now, i hope that i could make it into the next release (or something similar, that let's me use multiple abstractions with templates and drawings on the parent-patch)
mfg.csd.asdf IOhannes
the patch is attached and (or alternatively the source-code) can be found on ftp://iem.kug.ac.at/pd/misc/
mfg.cds.sdaf IOhannes
hi IOhannes, hi Miller, hi list,
apparently my fix from 29/26/01 (`deadly dangling scalars' post) has not yet been looked at (it prevents pd from crashing only, the complete solution should be more elaborate).
Krzysztof
IOhannes m zmoelnig wrote: ...
the patch does not fix the instability of the traversal/scalar-objects !! (so it will keep crashing when used ;-)
Krzysztof Czaja wrote:
hi IOhannes, hi Miller, hi list,
apparently my fix from 29/26/01 (`deadly dangling scalars' post) has not yet been looked at (it prevents pd from crashing only, the complete solution should be more elaborate).
Krzysztof
IOhannes m zmoelnig wrote: ...
the patch does not fix the instability of the traversal/scalar-objects !! (so it will keep crashing when used ;-)
ok, thanks i applied your bug-fix to my patch and it works fine: patch/sources can be found as before
mfg.cdas.asr IOhannes
Hi all,
I want to try to fix the underlying bug as part of a major overhaul of the "data" business. If I can get this cooking it might make a lot of issues moot, like the one mentioned here.
I'm hoping to replace the "scalar" feature with something much more powerful, essentially allowing abstractions to show part of themselves as a panel in the parent.
IOhannes's other question, how to use "namecanves" to generate templates that are private to an _instance_ of an abstraction, is something I've never considered. I eventually want to stop having templates go through the canvas's symbol binding (it's inefficient) and this will mean changing how "set", etc., look up templates. So I'm hoping to get rid of the whole "pd-" prefix problem that way...
cheers Miller
On Thu, Nov 15, 2001 at 09:16:53PM +0100, IOhannes m zmoelnig wrote:
Krzysztof Czaja wrote:
hi IOhannes, hi Miller, hi list,
apparently my fix from 29/26/01 (`deadly dangling scalars' post) has not yet been looked at (it prevents pd from crashing only, the complete solution should be more elaborate).
Krzysztof
IOhannes m zmoelnig wrote: ...
the patch does not fix the instability of the traversal/scalar-objects !! (so it will keep crashing when used ;-)
ok, thanks i applied your bug-fix to my patch and it works fine: patch/sources can be found as before
mfg.cdas.asr IOhannes
Dear Miller & list.
I'm hoping to replace the "scalar" feature with something much more powerful, essentially allowing abstractions to show part of themselves as a panel in the parent.
Here The First goals : Allow any user to create a "visual" or "user interface object" without writing any lines of c code. Just using the pd language.
For this a very simple line object that allow a patch to draw a line into their parent patch could be enougth.
=-=-=-= |line | =-=-=-=
The four intlet allow the patch to move the line. The four outlet give the position of where the user (in non-edit mode only) whant to place the line with the mouse.
Nothing conected to the inlets and outlets imply that the line can't be moved in the non-edit mode If you connect the Ys outlets to the Ys inlets, you'll have a line that can move only on the y axe. You can compute everything from this position too...
But the key point is here : The child patch has to be "inside" the line. I mean that if you select the line into the parent windows and duplicate it, all the code inside the patch who is behind the line has to be duplicate too...
of course we can imagine a rectangle object etc....
If somebody help, I can try to code this. Today I realy don't if it's easy or not.
bye,
Damien.