On Mon, 7 Jul 2008, Roman Haefeli wrote:
sorry, if i now seem to be nitpicking, but this is actually what i mean by 'core classes': the classes, that cover the initial focus of the library, in the case of gridflow the classes, that do deal with grids.
ok.
i don't think, that something hardcoded as [range 8 9 10] in [#camera]/[pd camera] justifies the use an extra external, if three [moses] objects cover exaxtly the same.
Look, [range] is in use in more abstractions than that, plus in more patches that you can see (unreleased stuff). [#camera] was just one example, and furthermore, [range] was just one example. There is also [route2], [listread], [listfind], and whatever else, that get used in abstractions, and that aren't as straightforward to replace by Miller's builtins.
i rather meant: is it really necessary to have the exact functionality of [range]? cannot the same be achieved by having some [moses]es here and there?
It's not the point.
different languages provide different ways to deal with issues.
And Pd doesn't provide enough when it comes to supporting abstractions in a way that makes them be able to use Pd in a way equivalent to how normal externals can use Pd, and at a price not significantly greater.
For example, [#in] and [#out] aren't in such great shape since they became abstractions, and they're significantly more complicated, because even the simplest dynamic patching is complicated.
At Pd Convention 2004, there was a nice moment during the papers sessions, where there was an apparent consensus that as many things as possible should be made as abstractions. I still think about that. I like the idea, and I've always liked the idea, and you can trace my appreciation of that idea back to the original design of GridFlow, but it's not always so feasible just by using Pd.
i might be wrong, but i haven't seen a case yet, where [range] would be the only option to solve a certain problem.
Originally [range] was only there so that when I convert jMax patches to Pd patches, I wouldn't have to do elaborate search-and-replaces. Although later on I could have decided to let it go and do things the Pd way, instead I came with the idea that [moses] was not enough and that if [sel] and [route] and such, take multiple number of arguments, [moses] should. In some patches I had to string 8 [moses] together.
Anyway, you seem to be on the defensive side... we don't absolutely need [range] so why bother? This is influenced by the fact that it is troublesome to make [range] in the first place, because at the same time it's not possible (or overly difficult) to make an abstraction out of it, and because it's troublesome to even carry portable C code around if it's not already in a very popular distro. If it were easy to make an abstraction, perhaps you wouldn't think like this. Or perhaps you would think like this about [range] anyway, but you wouldn't think like this about another example such as [route2].
but in this case i am more in favor of repeating [moses]es instead of introducing another class, that doesn't really cover new possibilities.
not much actually covers new possibilities. any abstraction could be just pasted in a patch so that you don't need the abstraction. It's all a matter of how much you're ok with doing that. It's more of a quantitative difference than qualitative.
in this particular case, i also prefer [moses], because it does not crash, while [range] crashes pd,
I don't have (nor remember) that bug.
I disavow any version of GridFlow prior to 0.9.2, and frankly, I also don't remember all of the bugs that might have been in 0.9.2 or 0.9.3. If you want to report bugs, do it relative to the last release, 0.9.4, or the SVN. (I uploaded it Friday, just didn't send an announcement yet).
from a developers perspective: why bother with making new code work, that introduces new problems and needs special attention, if pretty much the same could be achieved with a bit more effort in the user domain?
Exactly. So why bother improving Pd? It's hard, it introduces new problems, and needs special attention. If any possible improvement looks like it could be great, just break down this possible improvement into smaller, more incremental improvements, so that when you look at them individually, any of them looks like it's not worth doing. Looking at the big picture makes one worry, and we shouldn't worry, so let's not look at the big picture.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec