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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
