Here is a second (and full?) version of the abstraction to make editing of
gui objects much easier and quicker (for those who work a lot with them).
Just put them in your externals folder.
As I said before, this example is for a canvas, but I'll take the model
and adapt it to all other GUI objects.
Please try it out, correct, criticise, etc. (even the english, if you
want). If it's fine I think I can start the adaptations to the other ones.
Some operations might be made not with the most fast sollutions, but I was
using only the standard objects of pd. It's not impossible, and it will
provide compatibility.
Greetings,
João Miguel Pais
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
Here is a second (and full?) version of the abstraction to make editing of
gui objects much easier and quicker (for those who work a lot with them).
Just put them in your externals folder.As I said before, this example is for a canvas, but I'll take the model
and adapt it to all other GUI objects.Please try it out, correct, criticise, etc. (even the english, if you
want). If it's fine I think I can start the adaptations to the other ones.Some operations might be made not with the most fast sollutions, but I was
using only the standard objects of pd. It's not impossible, and it will
provide compatibility.
Wow, that's a mighty cool and very useful patch!!
To do dynamic sends you don't need to use the editmode etc. messages, if you require pd >= 0.39 for your patch (which I think, everyone should use anyways, but I said so several times already.)
Attached is a little idiom on how to do renameable sends with pd-0.39.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Wow, that's a mighty cool and very useful patch!!
thanks. It just occured when I thought "it's really not handy to work with
guis here".
To do dynamic sends you don't need to use the editmode etc. messages, if you require pd >= 0.39 for your patch (which I think, everyone should use anyways, but I said so several times already.)
Attached is a little idiom on how to do renameable sends with pd-0.39.
thanks, already implemented it. now only leaves the question, is it
possible to do dynamic receives as well?
or wait, is there any message which makes the patch think that he's
"clean"? I think I read that somewhere (or was it another program?). that
would take away the only small detail that still remains, I think.
joao
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
thanks, already implemented it. now only leaves the question, is it
possible to do dynamic receives as well?
[r] in plain Pd doesn't allow this, all IEM-GUI objects however do.
As far as I see, you only need dynamic receives to get the position of the cnv. You can fake that by renaming the receivers of IEM number boxes [nbx]. However be careful: Once you renamed the receiver, the old value is gone, so you need to keep track of which receiver name is currently active.
(This seems to be one of the really rare cases where a dynamic receive is actually needed. Other than that, in 4-5 years of using Pd I never needed to rename a receiver. I think it's generally better to use a static or argument-generated receiver and then [route ...] incoming lists according to their first element. With [sroute.pd] from [list]-abs this even can be dynamic.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
thanks, already implemented it. now only leaves the question, is it
possible to do dynamic receives as well?[r] in plain Pd doesn't allow this, all IEM-GUI objects however do.
As far as I see, you only need dynamic receives to get the position of the cnv. You can fake that by renaming the receivers of IEM number boxes [nbx]. However be careful: Once you renamed the receiver, the old value is gone, so you need to keep track of which receiver name is currently active.
what i usually do in such cases is setting the receiver to whatever i need via the inlet; since the inlet stays, i don't have to track the name of the receiver and i can change it again to whatever i want.
(This seems to be one of the really rare cases where a dynamic receive is actually needed. Other than that, in 4-5 years of using Pd I never needed to rename a receiver. I think it's generally better to use a
i would totally agree (if i didn't use dynamic senders/receivers myself sometimes)
mfg.a.dsr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
(This seems to be one of the really rare cases where a dynamic receive is actually needed. Other than that, in 4-5 years of using Pd I never needed to rename a receiver. I think it's generally better to use a
i would totally agree (if i didn't use dynamic senders/receivers myself sometimes)
Note that I consider dynamic *senders* to be very useful, Sending to different targets is as natural as talking to different people.
I just don't like changing receivers. Renaming a receiver-name to me more feels like doing this kind of conversation:
- "Hi, I'm Frank, may I help you?"
- "Yes, could you explain Pd's data structures a bit, Frank?"
- "Sorry, who are you talking to? I'm Matju now. And data structures suck."
Ciao
Matju Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
i would totally agree (if i didn't use dynamic senders/receivers myself sometimes)
Note that I consider dynamic *senders* to be very useful, Sending to
i was really talking about dynamic *receivers* (it just happens that i use them almost exclusively in conjunction with dynamic senders)
different targets is as natural as talking to different people.
exactly. imagine sliders are taking part in a theater. one of them is dynamic and thus has to change its role every now and then (once it is frank, then it is matju), because the theatre is low on actors. the only important thing is that the director has a possibility to talk directly to the actors (and not to the roles they are playing). this is where the direct connection comes into the play (as opposed to send/receive).
i need these kind of tricks for a mixer where you can access a channel via the "channel section" and additionally there is a "focus section" for the "selected" channel. very simple if you can tell the gain-slider in the "focus section" to "just be" the gain-slider of channel X.
mfg.adsr IOhannes
[r] in plain Pd doesn't allow this, all IEM-GUI objects however do.
that's true. but I wanted to use only standard objects (maybe too
radical?).
As far as I see, you only need dynamic receives to get the position of the cnv. You can fake that by renaming the receivers of IEM number
true. in itself also not so necessary, but if the feature is there, why
not add it?
the cnv. You can fake that by renaming the receivers of IEM number boxes [nbx]. However be careful: Once you renamed the receiver, the old value is gone, so you need to keep track of which receiver name is currently active.
ok, good point. but it will save time if one gives the variable first,
which is the point of the patch. I mean, if no changes in code are
predicted, since it's working I guess it wouldn't bother so (well, apart
from "dirtying" the patch).
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
[r] in plain Pd doesn't allow this, all IEM-GUI objects however do.
that's true. but I wanted to use only standard objects (maybe too
radical?).
Oh, with "IEM-GUI" I meant the colored GUI objects, that are part of Pd, like [vsl] [hsl] [nbx] [cnv] ....
They were externals in the "iemgui" collection until Miller included them in Pd some years ago (0.36?).
the cnv. You can fake that by renaming the receivers of IEM number boxes [nbx]. However be careful: Once you renamed the receiver, the old value is gone, so you need to keep track of which receiver name is currently active.
ok, good point. but it will save time if one gives the variable first,
which is the point of the patch. I mean, if no changes in code are
predicted, since it's working I guess it wouldn't bother so (well, apart
from "dirtying" the patch).
It would also be nice to have inlets and outlets for your edit patches. Then you could also cross-connect the abstraction to a slider without any sends and receives involved at all.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
[r] in plain Pd doesn't allow this, all IEM-GUI objects however do.
that's true. but I wanted to use only standard objects (maybe too radical?).
Oh, with "IEM-GUI" I meant the colored GUI objects, that are part of Pd, like [vsl] [hsl] [nbx] [cnv] ....
I was talking about [r], not about the iem guis. they belong to pd
already, of course, without those can't I (and no one) work. I thought you
were speaking about some externals which have dynamic sends.
ok, good point. but it will save time if one gives the variable first, which is the point of the patch. I mean, if no changes in code are predicted, since it's working I guess it wouldn't bother so (well, apart from "dirtying" the patch).
It would also be nice to have inlets and outlets for your edit patches. Then you could also cross-connect the abstraction to a slider without any sends and receives involved at all.
good idea. with the canvas object that was no issue, of course. but one
can also connect this exit to whatever he wishes.
To do dynamic sends you don't need to use the editmode etc. messages, if you require pd >= 0.39 for your patch (which I think, everyone should use anyways, but I said so several times already.)
sorry, but I just found an inconvenient of your sollution:
many objects use send / receive symbols with variables, $0-aa, $1-ubb,
etc. It isn't possible to use those variables correctly because when
they're incorporated in messages they take another value - or at least I
couldn't do it (sometimes I still make confusions with the several classes
in pd/max).
anyway here's a patch, in case you find a sollution. the behaviour of the
cnv-edit patch is simulated (symbol for send and list with parameters).
joao
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
To do dynamic sends you don't need to use the editmode etc. messages, if you require pd >= 0.39 for your patch (which I think, everyone should use anyways, but I said so several times already.)
sorry, but I just found an inconvenient of your sollution:
many objects use send / receive symbols with variables, $0-aa, $1-ubb,
etc. It isn't possible to use those variables correctly because when
they're incorporated in messages they take another value - or at least I
couldn't do it (sometimes I still make confusions with the several classes
in pd/max).
You have this problem with the generated objects as well - as they, too, need to be built out of messages. That is, if you provide a symbol box to let users type in the name, they cannot type $0 or $1, instead they need to type in the values of $0 or $1.
Plus: There is no "$0" variable in messages! $0 is an object variable, so to get it into a message, the messages needs to use another $x, like $1, and replace that with the incoming value of [f $0] or [symbol $0-aa] or [f $0]-[makefilename pd-%d-patch].
Besides that, there are some new methods of messages in 0.39 like "adddollar 1" or "adddollsym 2-aa, which can be handy. See the help file for messages, subpatch "pd changing-messages" for details on this.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 28 Nov 2005, Frank Barknecht wrote:
You have this problem with the generated objects as well - as they, too, need to be built out of messages. That is, if you provide a symbol box to let users type in the name, they cannot type $0 or $1, instead they need to type in the values of $0 or $1.
Plus: There is no "$0" variable in messages! $0 is an object variable, so to get it into a message, the messages needs to use another $x, like $1, and replace that with the incoming value of [f $0] or [symbol $0-aa] or [f $0]-[makefilename pd-%d-patch].
BTW, if you consider:
an object construction as a message sent thru [s objectmaker]
abstraction instantiation as being the abstraction classname and arguments sent as a message to [s objectmaker] as if it were a messagebox banged and sending to object constructors as if they were messageboxes too
Then $ can be seen as consistent across objectboxes and messagebox. Let me give an easy example:
say you have foo.pd containing just [bar $2 $4] and then in another patch you create a [foo 2 3 5 7]. Then it's as if the [bar] object was created by banging this chain:
[foo 2 3 5 7( | [bar $2 $4( | [s objectmaker]
do I make sense here?
PS: However, my former proposal that $0 in messagebox could mean "get the selector of the incoming message" is not consistent with the above because it confuses the classname with the instance id.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
You have this problem with the generated objects as well - as they, too, need to be built out of messages. That is, if you provide a symbol box to let users type in the name, they cannot type $0 or $1, instead they need to type in the values of $0 or $1.
Actually it worked until now, when someone the receive or send of the
canvas changes it becomes what is typed (although the $ looks like $ in
the symbol atom).
Only with the label it doesn't work, was that what you meant? yeah, for
that I guess there's no solution.
Besides that, there are some new methods of messages in 0.39 like "adddollar 1" or "adddollsym 2-aa, which can be handy. See the help file for messages, subpatch "pd changing-messages" for details on this.
yes, I just saw it. But a good point would be to be able to edit patches
that could write the symbols "in the original form" in the guiobjs. the
best way would be to just type "$1-aa" in the receive name, and get it.
but it is already what's happening, at least with send and receive fields.
just saw the new message methods, but it's not easy (or not trivial) to
implement that in a typing context.
That's a great patch. My only critique is that I like thicker sliders
since they are easier targets.
It would be great to have this in CVS so that it automatically gets
included in the Pd-extended builds.
.hc
On Nov 26, 2005, at 12:06 PM, João Miguel Pais wrote:
Here is a second (and full?) version of the abstraction to make
editing of gui objects much easier and quicker (for those who work a
lot with them). Just put them in your externals folder.As I said before, this example is for a canvas, but I'll take the
model and adapt it to all other GUI objects.Please try it out, correct, criticise, etc. (even the english, if you
want). If it's fine I think I can start the adaptations to the other
ones.Some operations might be made not with the most fast sollutions, but I
was using only the standard objects of pd. It's not impossible, and it
will provide compatibility.Greetings,
João Miguel Pais
--
Lugostr. 14 79100 Freiburg i. Br. Deutschland +49 (0)761 7074997 jmmmp@arcor.de<cnv- edit.pd>_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"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
That's a great patch. My only critique is that I like thicker sliders
since they are easier targets.It would be great to have this in CVS so that it automatically gets
included in the Pd-extended builds.
my purpose wasn't to become famous or something, but if it must be is ok.
that to say that a patch for general use should follow general principles.
I find thinner sliders elegant, but that's not what's important here. can
you suggest a value?
frank gave a better suggestion for the dynamic send, if rhere are no other
issues (or anything I forgot), then I'll implement it and move on to the
other guis.
joao
.hc
On Nov 26, 2005, at 12:06 PM, João Miguel Pais wrote:
Here is a second (and full?) version of the abstraction to make editing
of gui objects much easier and quicker (for those who work a lot with
them). Just put them in your externals folder.As I said before, this example is for a canvas, but I'll take the model
and adapt it to all other GUI objects.Please try it out, correct, criticise, etc. (even the english, if you
want). If it's fine I think I can start the adaptations to the other
ones.Some operations might be made not with the most fast sollutions, but I
was using only the standard objects of pd. It's not impossible, and it
will provide compatibility.Greetings,
João Miguel Pais
-- Lugostr. 14 79100 Freiburg i. Br. Deutschland +49 (0)761 7074997 jmmmp@arcor.de<cnv- edit.pd>_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"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
Hi!
João Miguel Pais wrote:
Here is a second (and full?) version of the abstraction to make editing of gui objects much easier and quicker (for those who work a lot with them). Just put them in your externals folder.
The patch looks great - it's very clearly designed. I even like the thin sliders :-)
Can you shortly explain, how to connect the editor with a canvas? I didn't manage that trying to follow the help instructions:
"Connect this patch and your GUI object through typing the receive and send symbols of the object you want to edit."
Particularly, I don't know _what_ to type in the receive and send fields of my canvas...
Piotr
Can you shortly explain, how to connect the editor with a canvas? I
didn't manage that trying to follow the help instructions:"Connect this patch and your GUI object through typing the receive and
send symbols of the object you want to edit."
all editing of gui objects works only through send messages. You must give
your canvas(es) a receive [and send] symbol first (if you don't have them
already). Then you must type that receive symbol in the receive symbol
field in cnv-edit. That's the connection of the patches.
English is not my mutter language (more like cousin language), if you want
you can suggest a simple phrase to explain how to make the connection.
Hi!
I tried many things, but I still get no connection and an "error: unpack: type mismatch" changing any number/slider in cnv-edit.
João Miguel Pais wrote:
all editing of gui objects works only through send messages. You must give your canvas(es) a receive [and send] symbol first (if you don't have them already).
What I did:
- Open cnv-edit and a new empty patch.
- Put a canvas
- Edited the send-symbol field of the canvas to "test1"
- Edited the receive-symbol field of the canvas to "test2"
Is this what you mean by giving a receive/send symbol? You don't mean a pd "symbol" (ctrl-4), don't you?
Then you must type that receive symbol in the
receive symbol field in cnv-edit. That's the connection of the patches.
I changed the receive symbol _field_ in the symbol labeled "Receive" from "$0-receive-i" to "test1". Is this what you propose? It looks strange, I think I should change the send field, but anyhow, both changes don't work. I tried to change the Receive-symbol in the "Symbols.of.the.target.object" - no results as well...
English is not my mutter language (more like cousin language), if you want you can suggest a simple phrase to explain how to make the connection.
Don't worry - your English is fine. I think I'm doing something wrong here - it seems like I'm the only one with problems here. Which pd do you need for cnv-edit (maybe that's the point)?
br, Piotr
- Open cnv-edit and a new empty patch.
- Put a canvas
- Edited the send-symbol field of the canvas to "test1"
- Edited the receive-symbol field of the canvas to "test2"
Is this what you mean by giving a receive/send symbol? You don't mean a
pd "symbol" (ctrl-4), don't you?
that's exactly. it is actually a symbol, but I can't explain it that well
as the pd masters. that's also what is written in the canvas properties
window.
I changed the receive symbol _field_ in the symbol labeled "Receive"
from "$0-receive-i" to "test1". Is this what you propose? It looks
strange, I think I should change the send field, but anyhow, both
changes don't work.
no, it is much simpler than that. the patch is made so that no editing is
necessary. you type the name in the symbol field and press enter. that
would be
- click on the "Receive" field
- type test2 and press enter
- do the same for the send field, when necessary (with the other name)
if you changed the properties of the symbols you have to put them back in
order for the patch to work. as I said, it isn't necessary (and not
wished) to edit the patch to work with it.
Don't worry - your English is fine. I think I'm doing something wrong
here - it seems like I'm the only one with problems here. Which pd do
you need for cnv-edit (maybe that's the point)?
I work with 0.39, but that's not the point (it will be when I implement
Frank B's sollutions). actually this is fully compatible, no exts as well.
Hi!
João Miguel Pais wrote:
- click on the "Receive" field
- type test2 and press enter
Thanks - that helped. Now I know what is "type in a symbol" :-)
The editor works great.
Piotr
-
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
João Miguel Pais -
Mathieu Bouchard -
Piotr Majdak