Poor IOhannes, everyone thinks you're yelling at them :D
Pierre, nobody is mad at you. It's just a misunderstanding. Everyone is really impressed with your work and we've been thinking of ways to integrate it within a Pd distribution (vanilla, extended, etc). Part of doing that is to find and eliminate redundancy where it makes sense and the usage of the work "dupes" only refers to that. If anything, perhaps we can analyze the reasons why you needed to extend a few of the existing objects and see if we can't add the functionality to them ([canvas] etc).
Also, nobody has been sarcastic with using the term "fancy objects". At this point, we *all* want nicer objects and yours are pretty awesome. "fancy" only refers to a comparison with the iemguis which are admittedly utilitarian (but have their own charm).
On Jan 3, 2014, at 10:35 AM, pd-list-request@iem.at wrote:
From: Pierre Guillot guillotpierre6@gmail.com Subject: Re: [PD] [PD-announce] Chocolate et Coffee Date: January 3, 2014 at 8:26:17 AM EST To: IOhannes m zmölnig zmoelnig@iem.at Cc: PD List pd-list@iem.at
I offers a library for Pd and not only on Pd-extented. It would have been annoying to put the iem's prepend in the distribution (I don't think that Thomas Musil would have be happy) and it would have strange to ask the user to download one external here and another here. I've made c.prepend and c.loadmess because I wanted to offer something with clean and simple and note that canvasarg don't have the same behavior, canvasinfo isn't my pd-extented distribution, listpak doesn't work. I know that most of the users use these obects and I don't want to replace them that why I put ".c" before everything. So I can't figure out what is your problem, why do you say "fancy" objects, for the "dupes" ? If I said something wrong, I'm sorry. Let's try to be cool please.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan is right on the mark here - and keep in mind here that there are folks with a lot of strong opinions on things. that's how this forum goes. it's rarely any kind of flame war, but occasionally feathers can get ruffled, and feelings hurt.
personally i'm also very impressed. from the experience of an educator with a lot of familiarity in Max and a little in PD, i would totally welcome any number of your excellent GUI objects into Vanilla (my favorite as i want to work with libpd) or Extended. as for the various other libraries and externals you've made, i will leave that for the experts to handle the issues of duplication. (i also agree a prepend object in vanilla would be wonderful however). i'm not discounting the wonderful GPLd work, GUI based and otherwise, done by so many contributors in pd-extended but it presents issues to less code-savvy people wanting to make iOS apps in PD.
in short, i think more work for Vanilla than can be turned into iOS apps through libpd is extremely welcome. so thumbs up from me! keep doing what you're doing.
best to all, scott
On Thu, Jan 9, 2014 at 5:33 PM, Dan Wilcox danomatika@gmail.com wrote:
Poor IOhannes, everyone thinks you're yelling at them :D
Pierre, nobody is mad at you. It's just a misunderstanding. Everyone is really impressed with your work and we've been thinking of ways to integrate it within a Pd distribution (vanilla, extended, etc). Part of doing that is to find and eliminate redundancy where it makes sense and the usage of the work "dupes" only refers to that. If anything, perhaps we can analyze the reasons why you needed to extend a few of the existing objects and see if we can't add the functionality to them ([canvas] etc).
Also, nobody has been sarcastic with using the term "fancy objects". At this point, we *all* want nicer objects and yours are pretty awesome. "fancy" only refers to a comparison with the iemguis which are admittedly utilitarian (but have their own charm).
On Jan 3, 2014, at 10:35 AM, pd-list-request@iem.at wrote:
*From: *Pierre Guillot guillotpierre6@gmail.com *Subject: **Re: [PD] [PD-announce] Chocolate et Coffee* *Date: *January 3, 2014 at 8:26:17 AM EST *To: *IOhannes m zmölnig zmoelnig@iem.at *Cc: *PD List pd-list@iem.at
I offers a library for Pd and not only on Pd-extented. It would have been annoying to put the iem's prepend in the distribution (I don't think that Thomas Musil would have be happy) and it would have strange to ask the user to download one external here and another here. I've made c.prepend and c.loadmess because I wanted to offer something with clean and simple and note that canvasarg don't have the same behavior, canvasinfo isn't my pd-extented distribution, listpak doesn't work. I know that most of the users use these obects and I don't want to replace them that why I put ".c" before everything. So I can't figure out what is your problem, why do you say "fancy" objects, for the "dupes" ? If I said something wrong, I'm sorry. Let's try to be cool please.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
just tried this out, and it doesn't play nicely with pd-extended 0.42.5-rc3 on osx.
i get this error:
invalid command name "pdsend" invalid command name "pdsend" while executing "pdsend {#c.bang1902000 mouseenter}" (command bound to event)
so, looks like you need at least 0.43 to make it work
On Fri, Jan 10, 2014 at 11:15 AM, Scott R. Looney scottrlooney@gmail.comwrote:
Dan is right on the mark here - and keep in mind here that there are folks with a lot of strong opinions on things. that's how this forum goes. it's rarely any kind of flame war, but occasionally feathers can get ruffled, and feelings hurt.
personally i'm also very impressed. from the experience of an educator with a lot of familiarity in Max and a little in PD, i would totally welcome any number of your excellent GUI objects into Vanilla (my favorite as i want to work with libpd) or Extended. as for the various other libraries and externals you've made, i will leave that for the experts to handle the issues of duplication. (i also agree a prepend object in vanilla would be wonderful however). i'm not discounting the wonderful GPLd work, GUI based and otherwise, done by so many contributors in pd-extended but it presents issues to less code-savvy people wanting to make iOS apps in PD.
in short, i think more work for Vanilla than can be turned into iOS apps through libpd is extremely welcome. so thumbs up from me! keep doing what you're doing.
best to all, scott
On Thu, Jan 9, 2014 at 5:33 PM, Dan Wilcox danomatika@gmail.com wrote:
Poor IOhannes, everyone thinks you're yelling at them :D
Pierre, nobody is mad at you. It's just a misunderstanding. Everyone is really impressed with your work and we've been thinking of ways to integrate it within a Pd distribution (vanilla, extended, etc). Part of doing that is to find and eliminate redundancy where it makes sense and the usage of the work "dupes" only refers to that. If anything, perhaps we can analyze the reasons why you needed to extend a few of the existing objects and see if we can't add the functionality to them ([canvas] etc).
Also, nobody has been sarcastic with using the term "fancy objects". At this point, we *all* want nicer objects and yours are pretty awesome. "fancy" only refers to a comparison with the iemguis which are admittedly utilitarian (but have their own charm).
On Jan 3, 2014, at 10:35 AM, pd-list-request@iem.at wrote:
*From: *Pierre Guillot guillotpierre6@gmail.com *Subject: **Re: [PD] [PD-announce] Chocolate et Coffee* *Date: *January 3, 2014 at 8:26:17 AM EST *To: *IOhannes m zmölnig zmoelnig@iem.at *Cc: *PD List pd-list@iem.at
I offers a library for Pd and not only on Pd-extented. It would have been annoying to put the iem's prepend in the distribution (I don't think that Thomas Musil would have be happy) and it would have strange to ask the user to download one external here and another here. I've made c.prepend and c.loadmess because I wanted to offer something with clean and simple and note that canvasarg don't have the same behavior, canvasinfo isn't my pd-extented distribution, listpak doesn't work. I know that most of the users use these obects and I don't want to replace them that why I put ".c" before everything. So I can't figure out what is your problem, why do you say "fancy" objects, for the "dupes" ? If I said something wrong, I'm sorry. Let's try to be cool please.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Just as a general rule, when you see this:
invalid command name "pdsend"
it means you're trying to use an external (or a gui-plugin) that was designed for Pd >= 0.43 on a version of Pd < 0.43
And when you see this:
invalid command name "pd"
it means you're trying to use an external designed for Pd <= 0.42 on Pd > 0.42.
In most cases the external is probably trying to draw something graphically in a patch or on the screen.
On Friday, January 10, 2014 2:55 AM, i go bananas hard.off@gmail.com wrote:
just tried this out, and it doesn't play nicely with pd-extended 0.42.5-rc3 on osx.
i get this error:
invalid command name "pdsend" invalid command name "pdsend" while executing "pdsend {#c.bang1902000 mouseenter}" (command bound to event)
so, looks like you need at least 0.43 to make it work
On Fri, Jan 10, 2014 at 11:15 AM, Scott R. Looney scottrlooney@gmail.com wrote:
Dan is right on the mark here - and keep in mind here that there are folks with a lot of strong opinions on things. that's how this forum goes. it's rarely any kind of flame war, but occasionally feathers can get ruffled, and feelings hurt.
personally i'm also very impressed. from the experience of an educator with a lot of familiarity in Max and a little in PD, i would totally welcome any number of your excellent GUI objects into Vanilla (my favorite as i want to work with libpd) or Extended. as for the various other libraries and externals you've made, i will leave that for the experts to handle the issues of duplication. (i also agree a prepend object in vanilla would be wonderful however). i'm not discounting the wonderful GPLd work, GUI based and otherwise, done by so many contributors in pd-extended but it presents issues to less code-savvy people wanting to make iOS apps in PD.
in short, i think more work for Vanilla than can be turned into iOS apps through libpd is extremely welcome. so thumbs up from me! keep doing what you're doing.
best to all, scott
On Thu, Jan 9, 2014 at 5:33 PM, Dan Wilcox danomatika@gmail.com wrote:
Poor IOhannes, everyone thinks you're yelling at them :D
Pierre, nobody is mad at you. It's just a misunderstanding. Everyone is really impressed with your work and we've been thinking of ways to integrate it within a Pd distribution (vanilla, extended, etc). Part of doing that is to find and eliminate redundancy where it makes sense and the usage of the work "dupes" only refers to that. If anything, perhaps we can analyze the reasons why you needed to extend a few of the existing objects and see if we can't add the functionality to them ([canvas] etc).
Also, nobody has been sarcastic with using the term "fancy objects". At this point, we *all* want nicer objects and yours are pretty awesome. "fancy" only refers to a comparison with the iemguis which are admittedly utilitarian (but have their own charm).
On Jan 3, 2014, at 10:35 AM, pd-list-request@iem.at wrote:
From: Pierre Guillot guillotpierre6@gmail.com
Subject: Re: [PD] [PD-announce] Chocolate et Coffee
Date: January 3, 2014 at 8:26:17 AM EST
To: IOhannes m zmölnig zmoelnig@iem.at
Cc: PD List pd-list@iem.at
I offers a library for Pd and not only on Pd-extented. It would have been annoying to put the iem's prepend in the distribution (I don't think that Thomas Musil would have be happy) and it would have strange to ask the user to download one external here and another here. I've made c.prepend and c.loadmess because I wanted to offer something with clean and simple and note that canvasarg don't have the same behavior, canvasinfo isn't my pd-extented distribution, listpak doesn't work. I know that most of the users use these obects and I don't want to replace them that why I put ".c" before everything. So I can't figure out what is your problem, why do you say "fancy" objects, for the "dupes" ? If I said something wrong, I'm sorry. Let's try to be cool please.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Dan, Given that Pierre wants to target Pd Vanilla with his external library, "dupes" are inevitable. Some of these are features that have been requested for over a decade.
What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this?
-Jonathan
On Thursday, January 9, 2014 8:37 PM, Dan Wilcox danomatika@gmail.com wrote:
Poor IOhannes, everyone thinks you're yelling at them :D
Pierre, nobody is mad at you. It's just a misunderstanding. Everyone is really impressed with your work and we've been thinking of ways to integrate it within a Pd distribution (vanilla, extended, etc). Part of doing that is to find and eliminate redundancy where it makes sense and the usage of the work "dupes" only refers to that. If anything, perhaps we can analyze the reasons why you needed to extend a few of the existing objects and see if we can't add the functionality to them ([canvas] etc).
Also, nobody has been sarcastic with using the term "fancy objects". At this point, we *all* want nicer objects and yours are pretty awesome. "fancy" only refers to a comparison with the iemguis which are admittedly utilitarian (but have their own charm).
On Jan 3, 2014, at 10:35 AM, pd-list-request@iem.at wrote:
From: Pierre Guillot guillotpierre6@gmail.com
Subject: Re: [PD] [PD-announce] Chocolate et Coffee
Date: January 3, 2014 at 8:26:17 AM EST
To: IOhannes m zmölnig zmoelnig@iem.at
Cc: PD List pd-list@iem.at
I offers a library for Pd and not only on Pd-extented. It would have been annoying to put the iem's prepend in the distribution (I don't think that Thomas Musil would have be happy) and it would have strange to ask the user to download one external here and another here. I've made c.prepend and c.loadmess because I wanted to offer something with clean and simple and note that canvasarg don't have the same behavior, canvasinfo isn't my pd-extented distribution, listpak doesn't work. I know that most of the users use these obects and I don't want to replace them that why I put ".c" before everything. So I can't figure out what is your problem, why do you say "fancy" objects, for the "dupes" ? If I said something wrong, I'm sorry. Let's try to be cool please.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ...
On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this?
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 01/10/2014 12:50 PM, Dan Wilcox wrote:
I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ...
I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the "dupes" IOhannes cites already be included in Pd Vanilla after over a decade now?
Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about "dupes". Then you ship the library, and it "just works" without users having to find other libraries.
-Jonathan
On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this?
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Hi, I may have been sensitive, I needed 2 days break, sorry. If we focus on the important facts, I received really constructive feedbacks and I've been able to improve the library for the next release.
Joao suggestions :
- The properties window will have a fixed size.
- We can set (in the code) if we want a color picker, checkbox, menu or
textfield for each property.
- The id name becomes receive symbol and there's also an send symbol.
IOhannes suggestions :
- The c/tcl library is now named CicmWrapper (The repository name will
change with the next release)
- If it seems better to change the libray name, Chocolate can become
CicmGUI ?
About the right click during runmode, It's possible to change it but I don't really like it. Do you think that's really important ?
To include in Pd-ext, it's possible to only include Chocolate, I just have to replace all the c.prepend and c.loadmess with prepend and init. I received mails and some users like c.patcherargs and the double click of the coffee objects but they can download and add the library manually. To include in Vanilla, you're right, the best is to ask to Miller.
If we want to "replace" the vanilla GUIs, two suggestions for the moment :
- We keep the the vanilla GUIs and we just replace the shortcut, we won't
have any problem to load previous patchs and users will use the new GUI for their new patchs (Secure and easy to do, we can also have an option to replace or not the vanilla shortcuts).
- We overwrite the vanilla classes then every objects will replaced but the
users will lose the properties (size, font, color, etc...). Another idea is to add a menu option or to offer 2 libraries with one that overwrite classes.
Cheers
2014/1/10 Jonathan Wilkes jancsika@yahoo.com
On 01/10/2014 12:50 PM, Dan Wilcox wrote:
I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ...
I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the "dupes" IOhannes cites already be included in Pd Vanilla after over a decade now?
Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about "dupes". Then you ship the library, and it "just works" without users having to find other libraries.
-Jonathan
On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this?
Dan Wilcox @danomatika danomatika.com robotcowboy.com
i very much doubt miller will include stuff in vanilla that's not backwards compatible. seeing as how these objects don't even work with my (relatively) recent 0.42.5 version, i can't see how they'd pass.
On Mon, Jan 13, 2014 at 6:00 PM, Pierre Guillot guillotpierre6@gmail.comwrote:
Hi, I may have been sensitive, I needed 2 days break, sorry. If we focus on the important facts, I received really constructive feedbacks and I've been able to improve the library for the next release.
Joao suggestions :
- The properties window will have a fixed size.
- We can set (in the code) if we want a color picker, checkbox, menu or
textfield for each property.
- The id name becomes receive symbol and there's also an send symbol.
IOhannes suggestions :
- The c/tcl library is now named CicmWrapper (The repository name will
change with the next release)
- If it seems better to change the libray name, Chocolate can become
CicmGUI ?
About the right click during runmode, It's possible to change it but I don't really like it. Do you think that's really important ?
To include in Pd-ext, it's possible to only include Chocolate, I just have to replace all the c.prepend and c.loadmess with prepend and init. I received mails and some users like c.patcherargs and the double click of the coffee objects but they can download and add the library manually. To include in Vanilla, you're right, the best is to ask to Miller.
If we want to "replace" the vanilla GUIs, two suggestions for the moment :
- We keep the the vanilla GUIs and we just replace the shortcut, we won't
have any problem to load previous patchs and users will use the new GUI for their new patchs (Secure and easy to do, we can also have an option to replace or not the vanilla shortcuts).
- We overwrite the vanilla classes then every objects will replaced but
the users will lose the properties (size, font, color, etc...). Another idea is to add a menu option or to offer 2 libraries with one that overwrite classes.
Cheers
2014/1/10 Jonathan Wilkes jancsika@yahoo.com
On 01/10/2014 12:50 PM, Dan Wilcox wrote:
I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ...
I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the "dupes" IOhannes cites already be included in Pd Vanilla after over a decade now?
Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about "dupes". Then you ship the library, and it "just works" without users having to find other libraries.
-Jonathan
On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this?
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well, backwards compatibility can have reasonable limitations and perhaps this is one.
On Jan 13, 2014, at 6:18 AM, i go bananas hard.off@gmail.com wrote:
i very much doubt miller will include stuff in vanilla that's not backwards compatible. seeing as how these objects don't even work with my (relatively) recent 0.42.5 version, i can't see how they'd pass.
On Mon, Jan 13, 2014 at 6:00 PM, Pierre Guillot guillotpierre6@gmail.com wrote: Hi, I may have been sensitive, I needed 2 days break, sorry. If we focus on the important facts, I received really constructive feedbacks and I've been able to improve the library for the next release.
Joao suggestions :
- The properties window will have a fixed size.
- We can set (in the code) if we want a color picker, checkbox, menu or textfield for each property.
- The id name becomes receive symbol and there's also an send symbol.
IOhannes suggestions :
- The c/tcl library is now named CicmWrapper (The repository name will change with the next release)
- If it seems better to change the libray name, Chocolate can become CicmGUI ?
About the right click during runmode, It's possible to change it but I don't really like it. Do you think that's really important ?
To include in Pd-ext, it's possible to only include Chocolate, I just have to replace all the c.prepend and c.loadmess with prepend and init. I received mails and some users like c.patcherargs and the double click of the coffee objects but they can download and add the library manually. To include in Vanilla, you're right, the best is to ask to Miller.
If we want to "replace" the vanilla GUIs, two suggestions for the moment :
- We keep the the vanilla GUIs and we just replace the shortcut, we won't have any problem to load previous patchs and users will use the new GUI for their new patchs (Secure and easy to do, we can also have an option to replace or not the vanilla shortcuts).
- We overwrite the vanilla classes then every objects will replaced but the users will lose the properties (size, font, color, etc...).
Another idea is to add a menu option or to offer 2 libraries with one that overwrite classes.
Cheers
2014/1/10 Jonathan Wilkes jancsika@yahoo.com On 01/10/2014 12:50 PM, Dan Wilcox wrote:
I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ...
I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the "dupes" IOhannes cites already be included in Pd Vanilla after over a decade now?
Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about "dupes". Then you ship the library, and it "just works" without users having to find other libraries.
-Jonathan
On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this?
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
is it possible/feasible to add a switch so that "old" objects don't get
replaced by the new ones? e.g. by analysing the parameters of the creation
objects? if so, and someone delivers the code for this (I don't know how
to do it myself), there might be a better chance of these objects making
it into vanilla. (or not?)
Well, backwards compatibility can have reasonable limitations and
perhaps this is one.On Jan 13, 2014, at 6:18 AM, i go bananas hard.off@gmail.com wrote:
i very much doubt miller will include stuff in vanilla that's not
backwards compatible. seeing as how these objects don't even work withmy (relatively) recent 0.42.5 version, i can't see how they'd pass.
On Mon, Jan 13, 2014 at 6:00 PM, Pierre Guillot
guillotpierre6@gmail.com wrote:Hi, I may have been sensitive, I needed 2 days break, sorry. If we focus
on the important facts, I received really constructive feedbacksand I've been able to improve the library for the next release.
Joao suggestions :- The properties window will have a fixed size.
- We can set (in the code) if we want a color picker, checkbox, menu
or textfield for each property.
- The id name becomes receive symbol and there's also an send symbol.
IOhannes suggestions :
- The c/tcl library is now named CicmWrapper (The repository name will
change with the next release)
- If it seems better to change the libray name, Chocolate can become
CicmGUI ?
About the right click during runmode, It's possible to change it but I
don't really like it. Do you think that's really important ?To include in Pd-ext, it's possible to only include Chocolate, I just
have to replace all the c.prepend and c.loadmess with prepend andinit. I received mails and some users like c.patcherargs and the
double click of the coffee objects but they can download and add the
library manually.To include in Vanilla, you're right, the best is
to ask to Miller.
If we want to "replace" the vanilla GUIs, two suggestions for the
moment :- We keep the the vanilla GUIs and we just replace the
shortcut, we won't have any problem to load previous patchs and users
will >>>use the new GUI for their new patchs (Secure and easy to do,
we can also have an option to replace or not the vanilla shortcuts).
- We overwrite the vanilla classes then every objects will replaced
but the users will lose the properties (size, font, color, etc...). Another idea is to add a menu option or to offer 2 libraries with one
that overwrite classes.Cheers
2014/1/10 Jonathan Wilkes jancsika@yahoo.com
On 01/10/2014 12:50 PM, Dan Wilcox wrote:
I don't have any plans, I was only responding in a hypothetical
manner. I'm busy on a show right now and can't do >>>>>pd dev. A
better person to ask is Miller ...I must have misunderstood-- the way you wrote that made it sound like
there is a process by which the community gets things >>>>included
into Pd Vanilla. If such a process existed wouldn't one of the
"dupes" IOhannes cites already be included in Pd Vanilla >>>>after
over a decade now?Instead, I think Pierre has taken the only sensible approach to
making a library that works with both Pd-Vanilla and Pd-extended.>>You simply code up the stuff that's been missing forever-- some
of it probably in less time than it takes to respond to questions
>>about "dupes". Then you ship the library, and it "just works"
without users having to find other libraries.
-Jonathan
On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancsika@yahoo.com
wrote:What is your plan for getting the necessary features into Vanilla
so that such dupes are no longer >>>>>>necessary to include in a
library like this?>>>>>>>>> --------
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika danomatika.com robotcowboy.com
-
Dan Wilcox -
i go bananas -
Jonathan Wilkes -
João Pais -
Pierre Guillot -
Scott R. Looney