[PD] PD OOP?

brandon zeeb zeeb.brandon at gmail.com
Wed Dec 15 19:59:14 CET 2010


Sorry, gmail is hacking up the comment log.  Comments are inline.

On Wed, Dec 15, 2010 at 11:52 AM, Mathieu Bouchard <matju at artengine.ca>wrote:

> On Wed, 15 Dec 2010, brandon zeeb wrote:
>
>  Say you compute a raised cosine window and store it in a table, this
>> table is used within one instance of a granular table reading voice
>> abstraction, 1-n of these abstractions are created at run time for
>> polyphony.  Now you have N instances of this table.  Some people cache mtof
>> in a table, and thus that was my original point.
>>
>
> Oh ok. I couldn't imagine that people would cache mtof in a table.
>
> You can send "reply-to $0-callback" to [s mtof] and see whether your [r
> $0-callback] gets a bang. If it does, it's because there's a [r mtof] that
> sees that and has a [t b s]=[s] to send you back a bang. This thing is in an
> instance of the mtof-cache abstraction somewhere. If you don't get the
> reply, then you dynamically open the mtof-cache as a toplevel patch (so that
> the cache doesn't disappear when you close the patch that created it) and
> you auto-hide it using "vis 0"-[s $0-canvas] [namecanvas $0-canvas].
> Does that sound good ?
>
>
That's not a bad idea!  Essentially attempting to delegate the creation of
the table.


>  In a given abstraction you do NOT have control of the order in which your
>> abstractions are created in memory.
>>
>
> Yes you do. It's the implicit object numbering. You can renumber an object
> by deleting and undeleting it. Any new object is created at the end of the
> order, such that when you save the patch, it will be reloadable in that
> order.
>
>
That said, it's considered bad practice to rely on this. People who need to
> rely on this may use dynamic patching instead.
>
>
Perhaps, but not if you're creating the objects by hand.  As you say, it is
a bad practice.


> I care more about Pd as a language and as a means to learn. For my
> purposes, using externals is pointless,
>
 I beg your pardon ???
>
> Pd with a lot of externals is a language too !
>
>
>  although I do appreciate all the hard work.
>>
>
> do you, really ?


Why are people getting offended here?  I'm simply attempting to avoid
information overload, my background is primarily in software development,
not DSP.  I use Pd to help learn these basics, and I will use pd-extended
when I've mastered the basics.  With that in mind, what's the point in using
a pre-baked filter if I haven't created my own and don't yet fully
understand the theory behind it?  This says more about me than it does you
:)

 Basically, an abstraction (or object) is given what it needs to function by
> a 3rd party.
>
 Ok, then connections are given to the abstractions in a kind of attribute
> that we call an "outlet" : wouldn't that be a form of IoC ?


Nope, that would be delegation.  A simple example would be this.  Assume you
have an abstraction which uses [metro] to synchronize a particular process.
Now, if you wanted to synchronize with mates on the net using [netro],* you
would have to create a second abstraction*!  Using IoC / Strategy, you
create your abstraction and pass a symbol referencing the metronome you want
to use.  In Java / Spring IoC psuedocode:

class DoFunThings {
   private ICounter counter;
   private ISomeFunThing funThing;

   public void setCounter(ICounter newCounter) {
*      counter = newCounter;*
   }

  public void setSomeFunThing(ISomeFunThing thing) {
      funThing = thing;
  }

  public void doIt(Intlet inlet1, Inlet inlet2) {
*     int val = counter.next();*
     funThing(val);
  }
}

/// now let's build it
ICounter netCounter = new NetCounter("127.0.0.1");
DoFunThings myAbstraction = new DoFunThings();
myAbstraction.setCounter(netCounter);

//... this is boring

myAbstraction.setCounter(new LocalMetronome(100));


Within Pd we can't achieve pure IoC since we can't construct abstractions by
themselves and pass them into other abstractions.  Although, we can only
pass along the name of the abstraction with it's creation arguments.  This
rides a blurry line between Strategy and IoC patterns.  Is this making more
sense?

Cheers,
-- 
Brandon Zeeb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/1846ef27/attachment.htm>


More information about the Pd-list mailing list