On Nov 23, 2010, at 12:32 PM, Frank Barknecht wrote:
On Tue, Nov 23, 2010 at 11:57:26AM -0500, Hans-Christoph Steiner
wrote:On Nov 23, 2010, at 3:52 AM, Frank Barknecht wrote:
Is there a special reason tha I'm missing for voicepoly using
[initbang] instead of [loadbang]?It makes the coding much easier, IMHO. Also, it gives the
possibilities for dynamically creating inlets and outlets. But the objects don't currently do that, so I am open to someone converting them to use [loadbang]. They do require ggee/getdir tho, I think there is no replacement for that. I just got rid of a zexy requirement, so its currently [initbang] and [ggee/getdir] AFAIR.The problem with initbang is that currently it requires a patched
version of Pd so it's not as easy to install as an external. Unless you create
inlets or outlets dynamically, initbang IMO is superflous and patching with
loadbang is almost as easy: Just add one "loadbang" message box and trigger it
at the end.
It is true that [initbang] is not easy to use with Pd-vanilla. I think
its a good idea to use [loadbang] instead, as long as it provides the
same functionality. I'll try it.
Creating inlets/outlets dynamically can be useful, but actually it
would be most useful to get rid of the nasty wrapper abstractions, but for
that you'd ideally need a way to detect the number of inlets/outlets a
dynamically created object has. I think, iemguts has something for that. The rj polys
don't use wrappers, but they require your abstractions to be designed
specially, for instance midi-note pairs in and stereo outs. In practice this is
sufficient in many cases.
Check out bundle, instances, and instances~. They don't use the
wrapper abstraction. But they also don't do voice allocation
management. To do that without the wrapper abstraction would be the
real win. I guess that would be possible using your dynamic send
technique, perhaps keeping a list of busy instances. I guess you are
using [poly] to do the voice allocation, which doesn't work for more
generic things.
I didn't look in detail at how [getdir] is used, but for the rj poly
objects we just require that the things you want to create dynamically are in
your search path, just like for [polypoly]. I think, that's probably a reasonable assumption.
That's a dangerous assumption on anything but a small, tightly
controlled system. That takes us back to the bad old days when if you
used an external library, chances are your patch would not run on
anyone else's machine. A library should work regardless of the user's
path setup, etc. getdir is used to get the full path to the
abstraction that's given to the poly object, and then each instance is
created using the full path.
ggee uses the Tcl/Tk license, so I think you would be able to
distribute it via the Apple iTunes store (i.e. not GPL).
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White