hehe, depends on what you put into it too. On a slower machine, it
might start to choke too. You could also try uping the number of
voices. I was getting 247 before I got stack overflows.

.hc

On Nov 22, 2010, at 2:41 PM, Pierre Massat wrote:

It was just too loud. Nevermind.

2010/11/22 Pierre Massat pimassat@gmail.com Hi,

Is the patch with 200 voices supposed to be very noisy? It sounds
very distorted, very crusty.

pierre

2010/11/22 Hans-Christoph Steiner hans@at.or.at

I was just working on a library of objects for creating and managing
many instances. In the process I created a couple examples to play
with:

• ticker.pd, a 100 voice clock ticker, make it tick very fast!

• run-200voicestest.pd, a 200 voice sample stretcher and panner

These are based on voicepoly/voicepolywrap, which aims to be an easy- to-use replacement for nqpoly4. You can drop voicepoly.pd and
voicepolywrap.pd into your path (http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files ) and then use it from anywhere without having to copy it into your
project.

http://at.or.at/hans/pd/play/200voices.zip

Hopefully you have as much as I did making it!

.hc

---

If you are not part of the solution, you are part of the problem.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

"Making boring techno music is really easy with modern tools, but with
live coding, boring techno is much harder." - Chris McCormick

Its really simple when you look at it, just checkout voicetest~.pd,
that's it, multiplied by 200.

.hc

On Nov 23, 2010, at 1:34 AM, Phil Stone wrote:

Really, really great, Hans! I'm having a lot of fun with this, and
look forward to digging into it to figure out how it works...

Phil

On 11/22/10 9:47 AM, Hans-Christoph Steiner wrote:

...

I was just working on a library of objects for creating and
managing many instances. In the process I created a couple
examples to play with:

• ticker.pd, a 100 voice clock ticker, make it tick very fast!

• run-200voicestest.pd, a 200 voice sample stretcher and panner

These are based on voicepoly/voicepolywrap, which aims to be an
easy-to-use replacement for nqpoly4. You can drop voicepoly.pd and
voicepolywrap.pd into your path (http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files ) and then use it from anywhere without having to copy it into
your project.

http://at.or.at/hans/pd/play/200voices.zip

Hopefully you have as much as I did making it!

.hc

---

If you are not part of the solution, you are part of the problem.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Access to computers should be unlimited and total. - the hacker ethic

On Nov 23, 2010, at 3:52 AM, Frank Barknecht wrote:

Hi,

On Mon, Nov 22, 2010 at 12:47:43PM -0500, Hans-Christoph Steiner
wrote:

...

These are based on voicepoly/voicepolywrap, which aims to be an easy-to-use replacement for nqpoly4.

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.

.hc

There is no way to peace, peace is the way. -A.J. Muste

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

On Nov 24, 2010, at 6:00 AM, Frank Barknecht wrote:

On Tue, Nov 23, 2010 at 01:23:44PM -0500, Hans-Christoph Steiner
wrote:

...

On Nov 23, 2010, at 12:32 PM, Frank Barknecht wrote:

...

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.

If you create a poly-thing.pd file with e.g. [bundle 5 thing] in it,
then the way you are currently using [getdir] it seems it will only find a
thing.pd to load if it is in the same directory as poly-thing.pd. Creating for
instance a [bundle 5 creb/blosc~] will not work, because creb/blosc~.pd_linux
probably is somewhere else.

Now inside rj, we can poly-ize any object that you could manually
create in your patch as a single separate object. This makes it very easy to
patch something monophonic first, then later make it polyphonic by just
changing your [s_rhodey] to [u_makepoly 8 1 s_rhodey]. This is *extremely* useful.

OTOH the only case, where objects cannot be created, is the case
that you solve with getdir: abstractions that are right next to the surrounding
patch (like poly-thing.pd and thing.pd from above) cannot be created immediatly
because Pd extends its search path to the current directory only for the
toplevel patches, not for abstractions used inside.

But to fix this is trivial and easy and portable: Just add [declare - path .] :)

Ah, I see, I totally didn't think of that use case. For me, this lib
has always been in the context of using my own patches, so I was
focused on solving the problems I've encountered there. It is also
totally useful to be able to use any object in these objects too.

I have two ideas on how to combine both approaches:

• test whether the file exists in the current project dir and use

getdir, otherwise use the normal path

• use getdir to add the project path to the poly object via [declare -

path $1]

Both are untested as of yet, but seem feasible.

.hc

If you are not part of the solution, you are part of the problem.