On Wed, 15 Dec 2010, brandon zeeb wrote:
do you, really ?
Why are people getting offended here?
Am I getting offended ? How would you know, anyway ?
I'm simply attempting to avoid information overload,
Having to reinvent all that's outside of pd-vanilla is a more severe information overload.
my background is primarily in software development, not DSP.
If your background is in software development, then you know that you should rely on libraries to get stuff done.
I use Pd to help learn these basics, and I will use pd-extended when I've mastered the basics.
But, as I said, many of what I consider to be basics are outside of pd-vanilla (while several things in pd-vanilla are rarely ever used by anyone).
With that in mind, what's the point in using a pre-baked filter if I haven't created my own
It's so that you don't have to create your own.
and don't yet fully understand the theory behind it?
Have you recreated Pd's message-system yet ? What's the theory behind it ?
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.
That doesn't fit any definition of delegation that I can find. What makes you say that ?
1st definition : a kind of inheritance used in some OOP programming languages
2nd definition : a kind of forwarding of a message to another object. the message is normally sent as-is to the other object.
If I have a [metro], the outgoing message is not coming from anywhere at all. The only way it can be considered delegation is if the outlet is considered as an intermediate object. Conceptually, if you want to add this layer and really talk about delegation, it still doesn't prove that it's not lying inside of a bigger IoC pattern.
Using IoC / Strategy, you create your abstraction and pass a symbol referencing the metronome you want to use.
But you can also create the [metro] outside of the object, provided that you have an inlet in the abstraction that accepts the bangs, and zero, one or two outlets for connecting back to [metro] depending on needs. Isn't that IoC ?
In Java / Spring IoC psuedocode:
No idea what Spring is... and it doesn't seem to be used in your pseudocode, does it ?
Within Pd we can't achieve pure IoC since we can't construct abstractions by themselves and pass them into other abstractions.
Why can't we ?
Why don't you want to use outlet/inlet combinations for that purpose ?
Although, we can only pass along the name of the abstraction with it's creation arguments.
You can pass a patchcord to the object as a creation argument. That attribute is called an "outlet".
This rides a blurry line between Strategy and IoC patterns.
Design patterns have quite blurry lines themselves.
Is this making more sense?
It will need more discussion.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC