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

On Wed, Dec 15, 2010 at 11:52 AM, Mathieu Bouchard <matju@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