[PD] datastruct newbie mistake

[Mathieu Bouchard]

On Wed, 13 Sep 2006, Kyle Klipowicz wrote:

> Yes, this would be awesome!  I think it could be done, but it would be
> tricky to be as functional without the properties menu,

In DesireData you can do this to make sliders [hsl] and [vsl] be 
"normal objects" again instead of mapping to the Slider class:

   class_new MySlider {ObjectBox}
   classinfo hsl MySlider
   classinfo vsl MySlider

Similar things can be done to most other GUI classes. However there is 
currently no way to undefine [hsl] and [vsl] at runtime: you'd still have 
to remove S(g_slider) from desire_setup. From that point you can define 
your own [hsl] and [vsl] as abstractions, and because above I used 
MySlider instead of using ObjectBox directly, you can define a custom 
properties dialog like this:

   def MySlider popup_properties {} {
     set @blah [MySliderDialog new $self]
   }
   class_new MySliderDialog {PropertiesDialog}
   def MySliderDialog init {of} {
     super $of
     # here, add some widget creation inside of .$self
     # possibly using shortcut commands like:
     # $self add .$self {width integer}
   }
   def MySliderDialog apply {} {
     # here, pick up data and send it back to pd
   }

but then if you want to instead make it open a patch, I never tried, but 
it would be like:

   def MySlider popup_properties {} {
     pd pd open sliderprops.pd some/directory/there
   }

but there's currently no mechanism that can tell that newly open patch to 
bind to a particular slider. what I see is that the soon-to-come 
"announce-future-object" feature will be useful:

   def MySlider popup_properties {} {
     pd pd announce-future-object $self this_is_the_future
     pd pd open sliderprops.pd some/directory/there
   }
   def MySlider this_is_the_future {obj dollarzero} {
     pd $self here_it_is $dollarzero
   }

So the [hsl] or [vsl] abstraction instance will receive a here_it_is 
message in its leftmost [inlet] saying what's the $0, which you'd route 
using [route here_it_is]. Note that if the future-object is not a toplevel 
patch or abstraction-instance, the $0 wouldn't be passed. I just added 
that $0 idea to my former plan because the pointer ($obj above) can't 
really be handled by a patch.

Does that sound like a good idea?

Else, there could be a declarative class like [declare] or [block~] but 
which you would put in an abstraction instance to let it handle its own 
"Properties" menu entry.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada