Hi again!
I'm working on a patch as interface for Pulsar Grain Synthesis based on a variation of nullpointer abstractions (good work Tom!):
I'm making some functions (constant, ramp up/down, triangle, sine, gaussian, etc) to store on tables for parameters control. I've made an abstraction to store an array with selected name which stored this functions [p-table1]. [p-tables] abstraction dynamically create six of this abstractions. But my problem is that: I have to send a bang to the [p-table1] abstraction after it have been created to change array name and canvas label. I send this bang by [send $1-bang] but it doesn't work. I'm begin to make my patches too much complicated and I can't find the problem.
Somebody know what's the problem?
Sorry...I forgot to attach patches!
Saludos!
2007/12/29, raul diaz raul.lete@gmail.com:
Hi again!
I'm working on a patch as interface for Pulsar Grain Synthesis based on a variation of nullpointer abstractions (good work Tom!):
- http://www.nullpointer.co.uk/-/pd.htm
- http://www.nullpointer.co.uk/-/files/pulse-grain-generator.zip
I'm making some functions (constant, ramp up/down, triangle, sine, gaussian, etc) to store on tables for parameters control. I've made an abstraction to store an array with selected name which stored this functions [p-table1]. [p-tables] abstraction dynamically create six of this abstractions. But my problem is that: I have to send a bang to the [p-table1] abstraction after it have been created to change array name and canvas label. I send this bang by [send $1-bang] but it doesn't work. I'm begin to make my patches too much complicated and I can't find the problem.
Somebody know what's the problem?
-- Raul Diaz Poblete
raul.lete@gmail.com Barcelona [Spain]
the problem is that all the tables begin with the same name (array1). thus the [; array1 rename $1 ( message you're sending will rename every table in all 6 abstractions.
change the original arraynames to $0-array, and then go:
[rename $1( | [s $0-array]
Hallo, raul diaz hat gesagt: // raul diaz wrote:
I'm working on a patch as interface for Pulsar Grain Synthesis based on a variation of nullpointer abstractions (good work Tom!):
- http://www.nullpointer.co.uk/-/pd.htm
- http://www.nullpointer.co.uk/-/files/pulse-grain-generator.zip
I'm making some functions (constant, ramp up/down, triangle, sine, gaussian, etc) to store on tables for parameters control. I've made an abstraction to store an array with selected name which stored this functions [p-table1]. [p-tables] abstraction dynamically create six of this abstractions.
Do you really need to do this dynamically? I don't see any compelling reason for dynamic patching here.
The [p-tables] abstraction will always be the same patch after it is loaded. Additionally if you really want to create two or more instances of [p-tables], like [p-tables 1] and [p-tables 2] your current approach may break anyway unless you use [namecanvas] and as soon as you introduce that, I would rather recommend to use a [pd $0-something] subpatch for dynamic patching, and with that, you could could then send a message "loadbang" to [s pd-$0-something] to initiate another loadbang for the newly created objects without getting into a loadbang-loop, as you would if you use [namcanvas] in your current patch.
So basically my recommendation would be to forgo dynamic patching in your case, it does more harm than good here.
(Here I also get lots of crashes when trying to open a created [p-tables] instances. Anyone else gets this?)
Frank Barknecht _ ______footils.org__
Hi hard-off, Frank, all!
Thanks for your comments. The main problem was that all arrays have the same name, and I know, dynamic patching is not necessary here, but I was playing nowadays with that, so I tried to implemented it in this way. I'm going to remade the abstraction in a simpler way.
Another question is: why can't I change canvas size dynamically?
Look at attached patch!
Saludos.
2007/12/30, Frank Barknecht fbar@footils.org:
Hallo, raul diaz hat gesagt: // raul diaz wrote:
I'm working on a patch as interface for Pulsar Grain Synthesis based on
a
variation of nullpointer abstractions (good work Tom!):
- http://www.nullpointer.co.uk/-/pd.htm
- http://www.nullpointer.co.uk/-/files/pulse-grain-generator.zip
I'm making some functions (constant, ramp up/down, triangle, sine,
gaussian,
etc) to store on tables for parameters control. I've made an abstraction to store an array with selected name which
stored
this functions [p-table1]. [p-tables] abstraction dynamically create six of this abstractions.
Do you really need to do this dynamically? I don't see any compelling reason for dynamic patching here.
The [p-tables] abstraction will always be the same patch after it is loaded. Additionally if you really want to create two or more instances of [p-tables], like [p-tables 1] and [p-tables 2] your current approach may break anyway unless you use [namecanvas] and as soon as you introduce that, I would rather recommend to use a [pd $0-something] subpatch for dynamic patching, and with that, you could could then send a message "loadbang" to [s pd-$0-something] to initiate another loadbang for the newly created objects without getting into a loadbang-loop, as you would if you use [namcanvas] in your current patch.
So basically my recommendation would be to forgo dynamic patching in your case, it does more harm than good here.
(Here I also get lots of crashes when trying to open a created [p-tables] instances. Anyone else gets this?)
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, raul diaz hat gesagt: // raul diaz wrote:
Thanks for your comments. The main problem was that all arrays have the same name, and I know, dynamic patching is not necessary here, but I was playing nowadays with that, so I tried to implemented it in this way. I'm going to remade the abstraction in a simpler way.
Another question is: why can't I change canvas size dynamically?
Look at attached patch!
You have a little error in your patch: You create the canvas with a sender symbol, and without a receiver symbol.
Frank Barknecht _ ______footils.org__
Ok! Sorry for the error
I have corrected it now, but why can't I change size or label of canvas?
Any explanation?
2007/12/30, Frank Barknecht fbar@footils.org:
Hallo, raul diaz hat gesagt: // raul diaz wrote:
Thanks for your comments. The main problem was that all arrays have the same name, and I know,
dynamic
patching is not necessary here, but I was playing nowadays with that, so
I
tried to implemented it in this way. I'm going to remade the abstraction
in
a simpler way.
Another question is: why can't I change canvas size dynamically?
Look at attached patch!
You have a little error in your patch: You create the canvas with a sender symbol, and without a receiver symbol.
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
...I forgot to attach the patch again!
My brain is on holidays! ;-)
2007/12/30, raul diaz raul.lete@gmail.com:
Ok! Sorry for the error
I have corrected it now, but why can't I change size or label of canvas?
Any explanation?
2007/12/30, Frank Barknecht < fbar@footils.org>:
Hallo, raul diaz hat gesagt: // raul diaz wrote:
Thanks for your comments. The main problem was that all arrays have the same name, and I know,
dynamic
patching is not necessary here, but I was playing nowadays with that,
so I
tried to implemented it in this way. I'm going to remade the
abstraction in
a simpler way.
Another question is: why can't I change canvas size dynamically?
Look at attached patch!
You have a little error in your patch: You create the canvas with a sender symbol, and without a receiver symbol.
Ciao
Frank Barknecht _ ______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Raul Diaz Poblete
raul.lete@gmail.com Barcelona [Spain]
2007/12/30, raul diaz raul.lete@gmail.com:
I have corrected it now, but why can't I change size or label of canvas?
Any explanation?
Hi Raul, The issue is that you are leaving off the rest of the parameters to the cnv object on creation. Apparently this results in a malformed cnv object that does not behave correctly. I have put it an update to the help-file to the tracker but it was never added to the repository... I'll do it myself when we switch to svn : ).
Attached is a working version Cheers Luke