It's still a common vocabulary. You're not rewriting the abstractions (or renaming them) every time.
And in your case why not just have the several different patches all be in the same folder with the abstractions?
-Jonathan
On Tue, 15 Feb 2011, Jonathan Wilkes wrote:
It's still a common vocabulary. You're not rewriting the abstractions (or renaming them) every time.
How do the users know (and ensure) that they're really the same ?
Making copies like that, encourage per-project customisation of same-named things, doesn't it ?
And in your case why not just have the several different patches all be in the same folder with the abstractions?
In some sense, the examples/ folder of GridFlow can be thought as a big directory of projects sharing common abstractions and externals. So, in a sense, I'm doing that already.
To me, it's a form of packaging based on shared dependencies : things get distributed as a single package because they have a lot of dependencies with each other and/or in common (and there's not enough of a rationale to split the package). In GridFlow's case, it's also a form of packaging based on authorship : lots of things get put together because they share the same author (or by members of a same team, official or not).
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
--- On Tue, 2/15/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] noob question: trying to repurpose the G08.reverb.pd example To: "Jonathan Wilkes" jancsika@yahoo.com Cc: morgan@morganpackard.com, glitchpop@gmail.com, pd-list@iem.at Date: Tuesday, February 15, 2011, 9:15 PM On Tue, 15 Feb 2011, Jonathan Wilkes wrote:
It's still a common vocabulary. You're not rewriting
the abstractions (or renaming them) every time.
How do the users know (and ensure) that they're really the same ?
Well if the user is the person I send it to, the question makes no sense. They just run the patch and it works.
Making copies like that, encourage per-project customisation of same-named things, doesn't it ?
Not necessarily. You could have a core set of abstractions, and abstractions that you create specifically for a particular project.
And in your case why not just have the several
different patches all be in the same folder with the abstractions?
In some sense, the examples/ folder of GridFlow can be thought as a big directory of projects sharing common abstractions and externals. So, in a sense, I'm doing that already.
To me, it's a form of packaging based on shared dependencies : things get distributed as a single package because they have a lot of dependencies with each other and/or in common (and there's not enough of a rationale to split the package). In GridFlow's case, it's also a form of packaging based on authorship : lots of things get put together because they share the same author (or by members of a same team, official or not).
But GridFlow contains a lot more than abstractions. If it only contained abstractions, I'd just throw it in the patch's directory. It's the difference between someone using my patch with a few clicks, and emailing me back about why [blah] isn't creating, or why Pd says it can't connect to a nonexistent right inlet of [bloo]...
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Tue, 15 Feb 2011, Jonathan Wilkes wrote:
--- On Tue, 2/15/11, Mathieu Bouchard matju@artengine.ca wrote:
It's still a common vocabulary. You're not rewriting
the abstractions (or renaming them) every time. How do the users know (and ensure) that they're really the same ?
Well if the user is the person I send it to, the question makes no sense. They just run the patch and it works.
I mean the direct users of the abstractions. (call them developers if you like)
But GridFlow contains a lot more than abstractions. If it only contained abstractions, I'd just throw it in the patch's directory. It's the difference between someone using my patch with a few clicks, and emailing me back about why [blah] isn't creating, or why Pd says it can't connect to a nonexistent right inlet of [bloo]...
You can have all those problems with abstractions. This is because of two things : Pd looks for externals before it looks for abstractions ; and Pd doesn't look for an abstraction once a same-named external is loaded. Any name clash is possible (à priori).
So, if you have an abstraction called [oneshot], it will get overridden by any other [oneshot] that decides to register the name that is just "oneshot".
If you have a [pow~] abstraction, it could get overridden by another same-named class by just upgrading from one version of vanilla to another version of vanilla.
In both cases, this could mean attempt to connect to a nonexistent right inlet if you're lucky, otherwise, silently wrong behaviour that takes a long time to debug.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Jonathan Wilkes -
Mathieu Bouchard