On Thu, Apr 24, 2008 at 7:27 PM, Luigi Rensinghoff < luigi.rensinghoff@freenet.de> wrote:
do you know how the numbers change if you cut everything from patch and paste it back in ?? my impression is that it does not start from zero ?? What if you copy it to a new patch ? then it should start from zero.....
Well, if you are making these patches PROGRAMMATICALLY, then you can't cut and paste, as there is no way to do that in programming.
You might want to open up some abstractions in a text editor, you can see the code that PD uses to create these objects directly. It is very enlightening.
Well sure i could keep track of that....but what if i would like to modify an existing patch....
Can't do it programmatically. You can only add objects to an existing patch, and if it is something that already has existing objects, there is no way to know how many objects are already in a patch. mike
On Apr 24, 2008, at 10:49 PM, Mike McGonagle wrote:
On Thu, Apr 24, 2008 at 7:27 PM, Luigi Rensinghoff
luigi.rensinghoff@freenet.de wrote:do you know how the numbers change if you cut everything from patch
and paste it back in ?? my impression is that it does not start
from zero ?? What if you copy it to a new patch ? then it should
start from zero.....Well, if you are making these patches PROGRAMMATICALLY, then you
can't cut and paste, as there is no way to do that in programming.You might want to open up some abstractions in a text editor, you
can see the code that PD uses to create these objects directly. It
is very enlightening.
cut and paste is possible too. Check out pd-msg for the details.
Basically, you need to programmatically draw a box around the around
the area to select the objects, then send the cut and paste messages.
Well sure i could keep track of that....but what if i would like to
modify an existing patch....Can't do it programmatically. You can only add objects to an
existing patch, and if it is something that already has existing
objects, there is no way to know how many objects are already in a
patch. mike
It would be non-trivial but possible. You could count the lines in
the .pd file with "#X obj" in them, that would give you the total
number of objects. I guess you'd have to count symbolatoms and
floatatoms too.
.hc
-- Peace may sound simple—one beautiful word— but it requires
everything we have, every quality, every strength, every dream,
every high ideal. —Yehudi Menuhin (1916–1999), musician _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hans-Christoph Steiner wrote:
Well, if you are making these patches PROGRAMMATICALLY, then you can't cut and paste, as there is no way to do that in programming.
You might want to open up some abstractions in a text editor, you can see the code that PD uses to create these objects directly. It is very enlightening.
cut and paste is possible too. Check out pd-msg for the details. Basically, you need to programmatically draw a box around the around the area to select the objects, then send the cut and paste messages.
I would not recommend this, it is buggy, slow, and a resource for errors. if you really want to dynamically create and delete objects the best method is the dyn~ external http://grrrr.org/ext marius.
On Fri, Apr 25, 2008 at 9:25 AM, Hans-Christoph Steiner hans@eds.org wrote:
On Apr 24, 2008, at 10:49 PM, Mike McGonagle wrote:
On Thu, Apr 24, 2008 at 7:27 PM, Luigi Rensinghoff < luigi.rensinghoff@freenet.de> wrote:
do you know how the numbers change if you cut everything from patch and paste it back in ?? my impression is that it does not start from zero ?? What if you copy it to a new patch ? then it should start from zero.....
Well, if you are making these patches PROGRAMMATICALLY, then you can't cut and paste, as there is no way to do that in programming.
You might want to open up some abstractions in a text editor, you can see the code that PD uses to create these objects directly. It is very enlightening.
cut and paste is possible too. Check out pd-msg for the details. Basically, you need to programmatically draw a box around the around the area to select the objects, then send the cut and paste messages.
And yes, while this is possible, it just seems very "difficult" at best, to be able to create a patch and lay it out in such a way that you can make those sorts of selections. LOTS of planning would need to go into such a thing.
Well sure i could keep track of that....but what if i would like to modify
an existing patch....
Can't do it programmatically. You can only add objects to an existing patch, and if it is something that already has existing objects, there is no way to know how many objects are already in a patch. mike
It would be non-trivial but possible. You could count the lines in the .pd file with "#X obj" in them, that would give you the total number of objects. I guess you'd have to count symbolatoms and floatatoms too.
You could probably do this by loading the patch into a [textfile] object, if you need to do this programmatically.
Mike
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
And yes, while this is possible, it just seems very "difficult" at best, to be able to create a patch and lay it out in such a way that you can make those sorts of selections. LOTS of planning would need to go into such a thing.
What I generally do *if* I'm doing dynamic patching is write as much as possible into an abstraction and just create copies of that. nqpoly4~ may help with automating that.
A very useful trick for these abstractions is to avoid doing connections at all and just pass $0 as an argument. Then inside the abstraction, use [r $1-inlet] receivers where $1 is the $0 of the parent as passed as argument instead of inlets, and [s $1-outlet] instead of outlets. Outside of the patch use [s $0-inlet] to write to the fake inlet, and [r $0-outlet] to read from the fake sender outlet. Do the same for signals with r~/s~ and throw~/catch~ pairs. Most dynamic connections can be avoided by this approach.
If you need to pass data from one dynamically created abstraction to another, use a similar approach with numbered arguments. Again this can be seen in action in the redesign of nqpoly4~.pd that I once did and that's in svn/pd-extended as well, or in polypoly.pd.
Ciao
Frank Barknecht
On Fri, 2008-04-25 at 20:09 +0200, Frank Barknecht wrote:
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
And yes, while this is possible, it just seems very "difficult" at best, to be able to create a patch and lay it out in such a way that you can make those sorts of selections. LOTS of planning would need to go into such a thing.
What I generally do *if* I'm doing dynamic patching is write as much as possible into an abstraction and just create copies of that. nqpoly4~ may help with automating that.
A very useful trick for these abstractions is to avoid doing connections at all and just pass $0 as an argument. Then inside the abstraction, use [r $1-inlet] receivers where $1 is the $0 of the parent as passed as argument instead of inlets, and [s $1-outlet] instead of outlets. Outside of the patch use [s $0-inlet] to write to the fake inlet, and [r $0-outlet] to read from the fake sender outlet. Do the same for signals with r~/s~ and throw~/catch~ pairs. Most dynamic connections can be avoided by this approach.
If you need to pass data from one dynamically created abstraction to another, use a similar approach with numbered arguments. Again this can be seen in action in the redesign of nqpoly4~.pd that I once did and that's in svn/pd-extended as well, or in polypoly.pd.
this is basically the approach, that probably all dynamic patches from netpd are based on. no connections are created or deleted dynamically (it's just too cumbersome and relies on undocumented features). parts that need to be deleted separately go into their own subpatch, so that they can be deleted simply by sending 'clear' to the appropriate subpatch.
however, there _are_ issues, that cannot solved that way. whenever signals are involved with dynamically created abstractions, it's likely to get one-block-delays due to the creation order of the [throw~]s/[catch~]es and [send~]s/[receive~]s. don't know how to deal with that yet.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Just curious, but has anyone tried to test the performance differences between sending messages as compared to actually connecting things up with wires?
I am curious weather or not one of my patches would work with messages, as I want to instantiate close to 200 oscillators, with each taking about 7 or 8 parameters per grain.
Mike
On 4/25/08, Roman Haefeli reduzierer@yahoo.de wrote:
On Fri, 2008-04-25 at 20:09 +0200, Frank Barknecht wrote:
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
And yes, while this is possible, it just seems very "difficult" at best, to be able to create a patch and lay it out in such a way that you can make those sorts of selections. LOTS of planning would need to go into such a thing.
What I generally do *if* I'm doing dynamic patching is write as much as possible into an abstraction and just create copies of that. nqpoly4~ may help with automating that.
A very useful trick for these abstractions is to avoid doing connections at all and just pass $0 as an argument. Then inside the abstraction, use [r $1-inlet] receivers where $1 is the $0 of the parent as passed as argument instead of inlets, and [s $1-outlet] instead of outlets. Outside of the patch use [s $0-inlet] to write to the fake inlet, and [r $0-outlet] to read from the fake sender outlet. Do the same for signals with r~/s~ and throw~/catch~ pairs. Most dynamic connections can be avoided by this approach.
If you need to pass data from one dynamically created abstraction to another, use a similar approach with numbered arguments. Again this can be seen in action in the redesign of nqpoly4~.pd that I once did and that's in svn/pd-extended as well, or in polypoly.pd.
this is basically the approach, that probably all dynamic patches from netpd are based on. no connections are created or deleted dynamically (it's just too cumbersome and relies on undocumented features). parts that need to be deleted separately go into their own subpatch, so that they can be deleted simply by sending 'clear' to the appropriate subpatch.
however, there _are_ issues, that cannot solved that way. whenever signals are involved with dynamically created abstractions, it's likely to get one-block-delays due to the creation order of the [throw~]s/[catch~]es and [send~]s/[receive~]s. don't know how to deal with that yet.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well...
not yet...but if you post the patch, or the part with th 200 or more
wires...
i would test the difference.
I am surprised where this discussion is going...many useful tips so far.
I personally dont like that $0 $1 confusion somehow, but thats just
because i dont remeber what i did when i open
the patch many months later or so..
Wires are somehow more "haptic" and its a part of pd that i like,
sort of the typical pd-character, but
as in the 24 24 matrix thing - when you have to do more than 100
connections in one patch, then its kind of silly, this weaving
so dynamic object creation or just "automated" connecting seems to be
a good way..
To come to a little bit more practical example..
I am facing the problem - again with the mapping library - and this
is, where it does not work with abstractions - i would like to have one
abstraction with a mapping object inside, but not always the same...
i post the example, later - where i am now experimenting with this
message-thing
basically its like that..
lets say you have an abstraction:
transfer.pd
inside of that there is the core-math object like
exponential_curve or exponential_sigmoid
so it would be cool to just send the argument "expoential_curve" to
the abstraction so this object is created..
well...not very clear i guess..
but i will post it later ......................
What about the
route audio~ float - object ....
did nobody ever have the same problem ??
good night luigi
Am 26.04.2008 um 00:06 schrieb Mike McGonagle:
Just curious, but has anyone tried to test the performance differences between sending messages as compared to actually connecting things up with wires?
I am curious weather or not one of my patches would work with messages, as I want to instantiate close to 200 oscillators, with each taking about 7 or 8 parameters per grain.
Mike
On 4/25/08, Roman Haefeli reduzierer@yahoo.de wrote:
On Fri, 2008-04-25 at 20:09 +0200, Frank Barknecht wrote:
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
And yes, while this is possible, it just seems very "difficult"
at best, to be able to create a patch and lay it out in such a way that you
can make those sorts of selections. LOTS of planning would need to go
into such a thing.What I generally do *if* I'm doing dynamic patching is write as
much as possible into an abstraction and just create copies of that.
nqpoly4~ may help with automating that.A very useful trick for these abstractions is to avoid doing
connections at all and just pass $0 as an argument. Then inside the
abstraction, use [r $1-inlet] receivers where $1 is the $0 of the parent as passed as argument instead of inlets, and [s $1-outlet] instead of outlets.
Outside of the patch use [s $0-inlet] to write to the fake inlet, and [r $0- outlet] to read from the fake sender outlet. Do the same for signals with
r~/s~ and throw~/catch~ pairs. Most dynamic connections can be avoided
by this approach.If you need to pass data from one dynamically created abstraction to another, use a similar approach with numbered arguments. Again
this can be seen in action in the redesign of nqpoly4~.pd that I once did and that's in svn/pd-extended as well, or in polypoly.pd.this is basically the approach, that probably all dynamic patches
from netpd are based on. no connections are created or deleted
dynamically (it's just too cumbersome and relies on undocumented features). parts that need to be deleted separately go into their own
subpatch, so that they can be deleted simply by sending 'clear' to the
appropriate subpatch.however, there _are_ issues, that cannot solved that way. whenever signals are involved with dynamically created abstractions, it's
likely to get one-block-delays due to the creation order of the [throw~]s/[catch~]es and [send~]s/[receive~]s. don't know how to
deal with that yet.roman
Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
---------------------------------------<
Luigi Rensinghoff luigi.rensinghoff@freenet.de skype:gigischinke ichat:gigicarlo
On 4/25/08, Luigi Rensinghoff luigi.rensinghoff@freenet.de wrote:
Well...
not yet...but if you post the patch, or the part with th 200 or more wires...
Well, it is still something in "development". I would need to rework it to use [nqpoly4], as that would be my alternative to doing it programmatically.
I personally dont like that $0 $1 confusion somehow, but thats just because i dont remeber what i did when i open the patch many months later or so..
Well, actually, you don't need to worry about the $0 & $1, as those are handled by [nqpoly4]. All you need do is instatiate an [nqpoly4] with your object, and the number of instances (and a few more things...) and that Abstraction handles everything else.
You should check out the patch, it is very instructional.
Wires are somehow more "haptic" and its a part of pd that i like, sort of the typical pd-character, but as in the 24 24 matrix thing - when you have to do more than 100 connections in one patch, then its kind of silly, this weaving so dynamic object creation or just "automated" connecting seems to be a good way..
at the same time, the first time you patch up 100 objects into a patch, you get some sort of sense of accomplishment... but not so much on the 2nd or 3rd... That is when things like [nqpoly4] are REAL NICE.
To come to a little bit more practical example..
I am facing the problem - again with the mapping library - and this is, where it does not work with abstractions - i would like to have one abstraction with a mapping object inside, but not always the same...
Well, one of the things that you could find in [nqpoly4] is how to do this. I attached a VERY SIMPLISTIC example of what I think you are looking for...
thepatch.pd is the main patch to open. Inside that, it creates another abstraction (which is where you might "wrap" the mapping stuff) called 'testing'. The arguments to that are the name of the "mapping" abstraction you want to use. You would also need to include any parameters to that particular mapping object you want to use.
i post the example, later - where i am now experimenting with this message-thing
basically its like that..
lets say you have an abstraction:
transfer.pd
inside of that there is the core-math object like
exponential_curve or exponential_sigmoid
so it would be cool to just send the argument "expoential_curve" to the abstraction so this object is created..
well...not very clear i guess..
but i will post it later
Well, if you are looking to change the subpatch on the fly with a message, I don't think that is possible. You could possibly expand on [nqpoly4] and when you send it this message, it would destroy everything that was previously created, and then recreate the new subpatch you are looking for. But I wouldn't count on any "realtime" performance, depending on how many objects you are creating.
Again, my example is VERY SIMPLISTIC, and doesn't do anything other than show how to create a sub-patch within another patch.
Mike
......................
What about the
route audio~ float - object ....
did nobody ever have the same problem ??
good night luigi
Am 26.04.2008 um 00:06 schrieb Mike McGonagle:
Just curious, but has anyone tried to test the performance differences between sending messages as compared to actually connecting things up with wires?
I am curious weather or not one of my patches would work with messages, as I want to instantiate close to 200 oscillators, with each taking about 7 or 8 parameters per grain.
Mike
On 4/25/08, Roman Haefeli reduzierer@yahoo.de wrote: On Fri, 2008-04-25 at 20:09 +0200, Frank Barknecht wrote: Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
And yes, while this is possible, it just seems very "difficult" at best, to be able to create a patch and lay it out in such a way that you can make those sorts of selections. LOTS of planning would need to go into such a thing.
What I generally do *if* I'm doing dynamic patching is write as much as possible into an abstraction and just create copies of that. nqpoly4~ may help with automating that.
A very useful trick for these abstractions is to avoid doing connections at all and just pass $0 as an argument. Then inside the abstraction, use [r $1-inlet] receivers where $1 is the $0 of the parent as passed as argument instead of inlets, and [s $1-outlet] instead of outlets. Outside of the patch use [s $0-inlet] to write to the fake inlet, and [r $0-outlet] to read from the fake sender outlet. Do the same for signals with r~/s~ and throw~/catch~ pairs. Most dynamic connections can be avoided by this approach.
If you need to pass data from one dynamically created abstraction to another, use a similar approach with numbered arguments. Again this can be seen in action in the redesign of nqpoly4~.pd that I once did and that's in svn/pd-extended as well, or in polypoly.pd.
this is basically the approach, that probably all dynamic patches from netpd are based on. no connections are created or deleted dynamically (it's just too cumbersome and relies on undocumented features). parts that need to be deleted separately go into their own subpatch, so that they can be deleted simply by sending 'clear' to the appropriate subpatch.
however, there _are_ issues, that cannot solved that way. whenever signals are involved with dynamically created abstractions, it's likely to get one-block-delays due to the creation order of the [throw~]s/[catch~]es and [send~]s/[receive~]s. don't know how to deal with that yet.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
---------------------------------------<
Luigi Rensinghoff luigi.rensinghoff@freenet.de skype:gigischinke ichat:gigicarlo
Hallo, Luigi Rensinghoff hat gesagt: // Luigi Rensinghoff wrote:
lets say you have an abstraction:
transfer.pd
inside of that there is the core-math object like
exponential_curve or exponential_sigmoid
so it would be cool to just send the argument "expoential_curve" to
the abstraction so this object is created..
You can pass object names as arguments as well! So in transfer.pd just use [$1], connect it, and call transfer.pd as [transfer exponential_curve] or [transfer exponential_sigmoid] depending on which mapping you want to use.
See attachement for a silly example.
Ciao
Frank Barknecht _ ______footils.org__
On Apr 25, 2008, at 12:09 PM, Mike McGonagle wrote:
On Fri, Apr 25, 2008 at 9:25 AM, Hans-Christoph Steiner
hans@eds.org wrote:On Apr 24, 2008, at 10:49 PM, Mike McGonagle wrote:
On Thu, Apr 24, 2008 at 7:27 PM, Luigi Rensinghoff
luigi.rensinghoff@freenet.de wrote:do you know how the numbers change if you cut everything from
patch and paste it back in ?? my impression is that it does not
start from zero ?? What if you copy it to a new patch ? then it
should start from zero.....Well, if you are making these patches PROGRAMMATICALLY, then you
can't cut and paste, as there is no way to do that in programming.You might want to open up some abstractions in a text editor, you
can see the code that PD uses to create these objects directly. It
is very enlightening.cut and paste is possible too. Check out pd-msg for the details.
Basically, you need to programmatically draw a box around the
around the area to select the objects, then send the cut and paste
messages.And yes, while this is possible, it just seems very "difficult" at
best, to be able to create a patch and lay it out in such a way
that you can make those sorts of selections. LOTS of planning would
need to go into such a thing.Well sure i could keep track of that....but what if i would like
to modify an existing patch....Can't do it programmatically. You can only add objects to an
existing patch, and if it is something that already has existing
objects, there is no way to know how many objects are already in a
patch. mikeIt would be non-trivial but possible. You could count the lines in
the .pd file with "#X obj" in them, that would give you the total
number of objects. I guess you'd have to count symbolatoms and
floatatoms too.You could probably do this by loading the patch into a [textfile]
object, if you need to do this programmatically.
Yup, for an example, check out this one in Pd-extended 0.39.3:
Help->Browser->manuals->0.Intro->46.pure_data_files.pd (I just
released this is broken in 0.40...)
.hc
Mike
-- Peace may sound simple—one beautiful word— but it requires
everything we have, every quality, every strength, every dream,
every high ideal. —Yehudi Menuhin (1916–1999), musician
"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
-
Frank Barknecht -
Hans-Christoph Steiner -
Luigi Rensinghoff -
marius schebella -
Mike McGonagle -
Roman Haefeli