Hey,
Now that I am immersing myself in the various versions of *poly, I am thinking the time is ripe for creating a nice, clean library of various poly objects.
- polypoly, works with [poly] - instances, for managing addressable instances - voices, for managing voice instances, basically nqpoly4
The key idea is that they all have a common interface and structure so if you know how to use one, you can use another. The first question I have is related to polypoly. I haven't really used it, so I am wondering how useful it is to be able to set the patch and the number of instances via the inlets.
.hc
------------------------------------------------------------------------ ----
kill your television
Ok, so I am replying to myself... :)
I just created two sketched that don't need the 'wrap' object, but still use the route like polypoly does. I am not sure which is better, or whether both are useful.
- [rawpoly] allows for dynamic addition while each existing instance will keep it's state. It also creates objects in the subpatch with proper $0 and $1.
- [instances] uses one [route] for all instances
.hc
On Nov 15, 2008, at 4:38 PM, Hans-Christoph Steiner wrote:
Hey,
Now that I am immersing myself in the various versions of *poly, I am thinking the time is ripe for creating a nice, clean library of various poly objects.
- polypoly, works with [poly]
- instances, for managing addressable instances
- voices, for managing voice instances, basically nqpoly4
The key idea is that they all have a common interface and structure so if you know how to use one, you can use another. The first question I have is related to polypoly. I haven't really used it, so I am wondering how useful it is to be able to set the patch and the number of instances via the inlets.
.hc
kill your television
------------------------------------------------------------------------ ----
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
- [rawpoly] allows for dynamic addition while each existing instance
will keep it's state. It also creates objects in the subpatch with proper $0 and $1.
- [instances] uses one [route] for all instances
I think, the proper $1 can be pretty useful, especially when combined with IOhannes' trick to detect empty creation arguments. The real $0 doesn't have a real advantage inside *poly, but it allows copy-and-paste of the whole subpatch into a static patch, that isn't generated dynamically anymore, which can be useful as a patching utility.
The other changes are more cosmetic, I think, and here it's probably a matter of taste if an additional wrapper or the added dynamic patching is easier to handle.
I'm a bit undecided in this regard, but the wrapper has as an advantage, that just by creating different wrappers one could induce different types of *poly-behaviour.
I'm not a big fan of huge [route]s, though. ;)
Ciao
On Nov 15, 2008, at 9:46 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
- [rawpoly] allows for dynamic addition while each existing instance
will keep it's state. It also creates objects in the subpatch with proper $0 and $1.
- [instances] uses one [route] for all instances
I think, the proper $1 can be pretty useful, especially when combined with IOhannes' trick to detect empty creation arguments. The real $0 doesn't have a real advantage inside *poly, but it allows copy-and-paste of the whole subpatch into a static patch, that isn't generated dynamically anymore, which can be useful as a patching utility.
The other changes are more cosmetic, I think, and here it's probably a matter of taste if an additional wrapper or the added dynamic patching is easier to handle.
I'm a bit undecided in this regard, but the wrapper has as an advantage, that just by creating different wrappers one could induce different types of *poly-behaviour.
I'm not a big fan of huge [route]s, though. ;)
I didn't think of changing the behavior by using different wrappers, that makes sense. I guess with nqpoly4 vs polypoly the main difference in the wrapper. I think there are a couple advantages to not using a wrapper:
- makes it easier and more transparent to find instances when debugging, [$1 $2 $3 $4 $5 $6 $7 $8 $9] is a strange construct to see
- it should make it much easier to make the *poly objectclass behave like a normal objectclass, with one file being in extra, but usable anywhere. This would require [ggee/getdir], but it should be pretty straightforward from there.
I am not a fan of huge routes, unless they are being dynamically generated. It makes some really nice line drawings when you have 30 or more instances :) Is there any real difference in efficiency between one big route and many small ones?
.hc
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I didn't think of changing the behavior by using different wrappers, that makes sense. I guess with nqpoly4 vs polypoly the main difference in the wrapper. I think there are a couple advantages to not using a wrapper:
- makes it easier and more transparent to find instances when
debugging, [$1 $2 $3 $4 $5 $6 $7 $8 $9] is a strange construct to see
Yep, that's true, but OTOH a wrapper is just a Pd patch, which is much easier to change than a dynamic patching construct. That has to be taken into account when it comes to longer-term maintainability. Generally less dynamic patching is better.
- it should make it much easier to make the *poly objectclass behave
like a normal objectclass, with one file being in extra, but usable anywhere. This would require [ggee/getdir], but it should be pretty straightforward from there.
You mean getdir for finding the objects to instantiate? Maybe you can elaborate this a bit... The big problem of all *polys so far is that it's hard for them to finde the objects to instantiate. At first I had hoped that your solution of omitting the wrapper would be an easy fix, but in my tests it showed the same issue.
I am not a fan of huge routes, unless they are being dynamically generated. It makes some really nice line drawings when you have 30 or more instances :)
Yep, it looks really cool. ;)
Is there any real difference in efficiency between one big route and many small ones?
I don't think so. I'd guess that small ones are a tiny bit less efficient because of the additional inlets, but I wouldn't care about this.
Ciao
On Nov 16, 2008, at 4:17 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I didn't think of changing the behavior by using different wrappers, that makes sense. I guess with nqpoly4 vs polypoly the main difference in the wrapper. I think there are a couple advantages to not using a wrapper:
- makes it easier and more transparent to find instances when
debugging, [$1 $2 $3 $4 $5 $6 $7 $8 $9] is a strange construct to see
Yep, that's true, but OTOH a wrapper is just a Pd patch, which is much easier to change than a dynamic patching construct. That has to be taken into account when it comes to longer-term maintainability. Generally less dynamic patching is better.
I used to think that, but some recent improvements have made dynamic patching much easier. First, your idea of using a subpatch and send/ receives is super helpful. Also, the settable send makes things much easier to follow. Building on your work, I think I've managed to get these polys to be pretty simple and straightforward. They could even fit all on one patch without subpatches.
- it should make it much easier to make the *poly objectclass behave
like a normal objectclass, with one file being in extra, but usable anywhere. This would require [ggee/getdir], but it should be pretty straightforward from there.
You mean getdir for finding the objects to instantiate? Maybe you can elaborate this a bit... The big problem of all *polys so far is that it's hard for them to finde the objects to instantiate. At first I had hoped that your solution of omitting the wrapper would be an easy fix, but in my tests it showed the same issue.
Yes, I am thinking of using [getdir] to get the path of the parent patch, then adding that path to the *poly's subpatch using [declare].
.hc
I am not a fan of huge routes, unless they are being dynamically generated. It makes some really nice line drawings when you have 30 or more instances :)
Yep, it looks really cool. ;)
Is there any real difference in efficiency between one big route and many small ones?
I don't think so. I'd guess that small ones are a tiny bit less efficient because of the additional inlets, but I wouldn't care about this.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
So I want to start working on a library of different poly, I welcome anyone who wants to join in the project. I have a number of sketches, then there is nqpoly~, nqpoly4, and polypoly already there. What needs to happen next is to name it...
any ideas?
fabrik poly massproduction instantiation
.hc
On Nov 16, 2008, at 4:17 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I didn't think of changing the behavior by using different wrappers, that makes sense. I guess with nqpoly4 vs polypoly the main difference in the wrapper. I think there are a couple advantages to not using a wrapper:
- makes it easier and more transparent to find instances when
debugging, [$1 $2 $3 $4 $5 $6 $7 $8 $9] is a strange construct to see
Yep, that's true, but OTOH a wrapper is just a Pd patch, which is much easier to change than a dynamic patching construct. That has to be taken into account when it comes to longer-term maintainability. Generally less dynamic patching is better.
- it should make it much easier to make the *poly objectclass behave
like a normal objectclass, with one file being in extra, but usable anywhere. This would require [ggee/getdir], but it should be pretty straightforward from there.
You mean getdir for finding the objects to instantiate? Maybe you can elaborate this a bit... The big problem of all *polys so far is that it's hard for them to finde the objects to instantiate. At first I had hoped that your solution of omitting the wrapper would be an easy fix, but in my tests it showed the same issue.
I am not a fan of huge routes, unless they are being dynamically generated. It makes some really nice line drawings when you have 30 or more instances :)
Yep, it looks really cool. ;)
Is there any real difference in efficiency between one big route and many small ones?
I don't think so. I'd guess that small ones are a tiny bit less efficient because of the additional inlets, but I wouldn't care about this.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
kill your television
Yep, that's true, but OTOH a wrapper is just a Pd
patch, which is
much easier to change than a dynamic patching construct. That has
to be taken into
account when it comes to longer-term maintainability.
Generally
less dynamic patching is better.
Well...if objects to be used within a dynamic patching system conform to some kind of standard, then dynamic patching is a good thing. I'm using it a bit in the forthcoming release of metastudio.
It's really time-consuming and cumbersome to create large polyphonic structures in PD. So I'm making a client in which my machines can be dynamically created as patches. Can anyone explain to me why the dynamic patching aspect of PD is not documented? Some have suggested that it "might change" at some point in the future. I can't see how basic [obj $1 $2 myvoice $3 $4...$n-1( syntax could change without a radical change to the structure of PD. Can anyone enlighten me?
Happy Xmas, ED
Lone Shark: Synchromatic: Out December 1st 2008 http://www.pyramidtransmissions.com/store Also available through the iTunes store
On Dec 21, 2008, at 5:28 PM, Ed Kelly wrote:
Yep, that's true, but OTOH a wrapper is just a Pd
patch, which is
much easier to change than a dynamic patching construct. That has
to be taken into
account when it comes to longer-term maintainability.
Generally
less dynamic patching is better.
Well...if objects to be used within a dynamic patching system conform to some kind of standard, then dynamic patching is a good thing. I'm using it a bit in the forthcoming release of metastudio.
It's really time-consuming and cumbersome to create large polyphonic structures in PD. So I'm making a client in which my machines can be dynamically created as patches. Can anyone explain to me why the dynamic patching aspect of PD is not documented? Some have suggested that it "might change" at some point in the future. I can't see how basic [obj $1 $2 myvoice $3 $4...$n-1( syntax could change without a radical change to the structure of PD. Can anyone enlighten me?
Basically, just open up a .pd file in a text editor, and those are the messages that are used in dynamic patching. You can also use mouse movement messages, but those are really kludgey to use. Check out IOhannes' iemguts lib, it is a really great thing for this stuff.
.hc
Happy Xmas, ED
Lone Shark: Synchromatic: Out December 1st 2008 http://www.pyramidtransmissions.com/store Also available through the iTunes store
------------------------------------------------------------------------ ----
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-
Ed Kelly -
Frank Barknecht -
Hans-Christoph Steiner