Re: [PD-dev] [once] default closed...
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > [once] controls flow. It should take a float argument like [spigot] > and [gate] so you can choose the default state. No argument implies > an argument of 0. Therefore it makes sense that [once] would be > default closed. But then it wouldn't be [once] anymore, as I already remarked. > If you want it to be default open, you can easily do > [once 1]. Changing the behaviour of [once] would force anyone who was using [once] to change their patches. I guess we all agree that adding an argument to [once] can be considered, however IOhannes and I both don't want this if it changes the default behaviour. As a compromise why not let [once] stay the way it is and as it's used, but instead introduce a new object with a new name. I thought a bit about this, and *if* we want an argument to [once], then this argument should be used for a little bit more than just selecting open or close. The most natural use for an argument I could come up with was to select, after how many incoming messages the object should close. Of course then the name [once] wouldn't be useful anymore as we would also have a reaction to messages coming in "more than once". So my idea for this object is like this: [the_object_previously_known_as_once] would close after 0 messages, that is, default is closed just like you wished. [the_object_previously_known_as_once 1] would be like the old [once] [the_object_previously_known_as_once 10] would close after 10 in-messages, that is after it has counted down like: 9, 8, 7, 6, 5, 4, 3, 2, 1, liftoff! That's also the name I finally chose for the new [the_object_previously_known_as_once]: [countdown] It's attached. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ #N canvas 0 0 450 300 10; #X obj 90 30 inlet; #X obj 90 112 spigot \$1; #X obj 90 134 t a b; #X obj 90 250 outlet; #X obj 197 82 t a a; #X obj 197 29 inlet; #X obj 178 252 outlet; #X obj 247 171 - 1; #X obj 227 143 - 1; #X obj 148 222 t a a; #X obj 211 191 max 0; #X obj 211 171 f; #X obj 197 57 f \$1; #X obj 242 30 loadbang; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 2 1 11 0; #X connect 4 0 1 1; #X connect 4 1 8 0; #X connect 5 0 12 0; #X connect 7 0 11 1; #X connect 8 0 11 1; #X connect 9 0 1 1; #X connect 9 1 6 0; #X connect 10 0 9 0; #X connect 11 0 7 0; #X connect 11 0 10 0; #X connect 12 0 4 0; #X connect 13 0 12 0; #N canvas 0 0 717 324 10; #X floatatom 306 194 5 0 0 1 countdown - -; #X obj 234 201 print; #X floatatom 306 141 5 0 0 0 - - -; #X obj 432 201 print; #X floatatom 490 139 5 0 0 0 - - -; #X floatatom 490 190 5 0 0 1 countdown - -; #X obj 234 169 countdown 3; #X text 38 53 Countdown lets anything pass a certain number of times until the countdown reaches zero.; #X msg 234 112 boom_after_3; #X msg 432 112 too_late; #X obj 48 197 print; #X floatatom 120 136 5 0 0 0 - - -; #X floatatom 120 190 5 0 0 1 countdown - -; #X msg 48 108 BOOM!; #X msg 320 166 bang; #X obj 432 169 countdown; #X obj 48 165 countdown 1; #X connect 2 0 6 1; #X connect 4 0 15 1; #X connect 6 0 1 0; #X connect 6 1 0 0; #X connect 8 0 6 0; #X connect 9 0 15 0; #X connect 11 0 16 1; #X connect 13 0 16 0; #X connect 14 0 6 1; #X connect 15 0 3 0; #X connect 15 1 5 0; #X connect 16 0 10 0; #X connect 16 1 12 0; ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [once] default closed...
There are many objects that control flow. [spigot], [gate], etc. They take float arguments. Float arguments are initialized to 0. 0 means closed in Pd. [once] controls flow. It should take a float argument like [spigot] and [gate] so you can choose the default state. No argument implies an argument of 0. Therefore it makes sense that [once] would be default closed. If you want it to be default open, you can easily do [once 1]. This has worked well for [spigot], I think this will work well for [once]. If you doubt that [once] and [spigot] are related, then open up the once.pd and check what is controlling the flow of data. Low and behold, its [spigot]. .hc On Sep 13, 2006, at 12:31 PM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: I actually think that default closed would be more consistent behavior, especially if [once] uses an argument. Changing [once] to i cannot follow you here: what makes [once] consistent if it was closed by default? while the object should be consistent to other objects (and i don't think it is inconsistent), it should be consistent to itself in the first place. (e.g.: making an empty object [Symbol] output 0 if you bang it (after instantiation without arguments), might be consistent to [f] and [t f], but somehow i have the feeling it should do symbols...;-)) default-closed would make it exactly like [spigot], except with the added feature of closing itself after receiving one piece of data. i follow frank here: if this object was "exactly like [spigot]" then you should use [spigot]. if there is a need for your suggested hybrid between [spigot] and [once], then this object should be, but with a different name. The more objects behave consistently with each other, the better Pd will be. but the more objects will behave as expected, the even better Pd will be. consistency is really a lot about "how do i expect an object to behave" imho, the biggest inconsistency for [once] is, that you can reset it at all. mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-extended auto-builds & Linux
I added it to the Makefile, a .pdsettings file should show up in the autobuild packages tomorrow. For future reference, feel free to work on this stuff yourself. The Makefile and .pdsetings files in question are in packages/linux_make. .hc On Sep 3, 2006, at 6:01 PM, B. Bogart wrote: Hey all, Is the pd-extended auto-build supposed to include a .pdsettings file for linux? I'm trying to get the pd-extended to work, but (of course) it loads nothing without the matching config file! Where do I get the config file for pd-extended test5? Thanks! .b. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1551815 ] align control checkboxes to left
Patches item #1551815, was opened at 2006-09-04 04:05 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1551815&group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Submitted By: oskude (oskude) Assigned to: Nobody/Anonymous (nobody) Summary: align control checkboxes to left Initial Comment: "-anchor w" in checkbutton doesnt have any effect. moved to pack, so they aligh to the left... -- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-09-13 15:25 Message: Logged In: YES user_id=27104 can you elaborate on what this patch does? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1551815&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1551825 ] autoscrollbars
Patches item #1551825, was opened at 2006-09-04 04:17 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1551825&group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: wishlist Status: Open Resolution: None Priority: 5 Submitted By: oskude (oskude) Assigned to: Nobody/Anonymous (nobody) Summary: autoscrollbars Initial Comment: autoscrollbars patch for pd cvs. dunno how good the code is, but it works :) -- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-09-13 15:26 Message: Logged In: YES user_id=27104 can you elaborate on what this patch does? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1551825&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data
What's the point of keeping this "running two instances" feature and make the check as default ?Why not take the opportunity to rework the scheduler (with threads) so we don't have to launch two instances ? Sorry if I'm missing smth ... and please explain :)++On 9/13/06, Mathieu Bouchard <[EMAIL PROTECTED] > wrote:On Wed, 13 Sep 2006, padawan12 wrote:> On Tue, 12 Sep 2006 22:39:16 -0400 (EDT) > Mathieu Bouchard <[EMAIL PROTECTED]> wrote:> Agreed, but actually it would be good to have the choice as a comandline> arg of the first one launched with a way to accept patches to open in > the same instance from, say a web browser. Like also when you are in a file> manager and browsing some .pd files you really want them to open in the same> running instance.oh ok, if it's an option... i put it in my TODO. _ _ __ ___ _ _ _ ...| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju| Freelance Digital Arts Engineer, Montréal QC Canada ___PD-dev mailing listPD-dev@iem.athttp://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [once] default closed...
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: > imho, the biggest inconsistency for [once] is, that you can reset it at all. Yes, let's rename [once] to [onceagain]! ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [once] default closed...
Hans-Christoph Steiner wrote: I actually think that default closed would be more consistent behavior, especially if [once] uses an argument. Changing [once] to i cannot follow you here: what makes [once] consistent if it was closed by default? while the object should be consistent to other objects (and i don't think it is inconsistent), it should be consistent to itself in the first place. (e.g.: making an empty object [Symbol] output 0 if you bang it (after instantiation without arguments), might be consistent to [f] and [t f], but somehow i have the feeling it should do symbols...;-)) default-closed would make it exactly like [spigot], except with the added feature of closing itself after receiving one piece of data. i follow frank here: if this object was "exactly like [spigot]" then you should use [spigot]. if there is a need for your suggested hybrid between [spigot] and [once], then this object should be, but with a different name. The more objects behave consistently with each other, the better Pd will be. but the more objects will behave as expected, the even better Pd will be. consistency is really a lot about "how do i expect an object to behave" imho, the biggest inconsistency for [once] is, that you can reset it at all. mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data
On Wed, 13 Sep 2006, padawan12 wrote: On Tue, 12 Sep 2006 22:39:16 -0400 (EDT) Mathieu Bouchard <[EMAIL PROTECTED]> wrote: Agreed, but actually it would be good to have the choice as a comandline arg of the first one launched with a way to accept patches to open in the same instance from, say a web browser. Like also when you are in a file manager and browsing some .pd files you really want them to open in the same running instance. oh ok, if it's an option... i put it in my TODO. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data (2 of 2)
On Wed, 13 Sep 2006, David Plans Casal wrote: On 13 Sep 2006, at 03:02, Mathieu Bouchard wrote: So for now, I guess we should simply be able to "open" pd's internal developments to see some kind of Darwinism Genetic evolution has more to do with monkeys on typewriters than about people wanting to make intelligent decisions. (Darwin knew this... even though typewriters didn't exist in his day) Hold on. This seems to make an argument *for* closed code, and for pumpkin holding, and therefore, in favour of Miller's control. Are you feeling ok, Matthieu? ;-) I'm opposing to the use of the word "Darwinism" in this context. I'm not making an argument in favour of a closed process, I'm making one against likening an open process to Darwinism, even "some kind of". What you say seems to imply you believe that only Miller is intelligent? ;-) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data
Yep... it's on my dolist :) M On Wed, Sep 13, 2006 at 05:39:02PM +0100, padawan12 wrote: > On Tue, 12 Sep 2006 22:39:16 -0400 (EDT) > Mathieu Bouchard <[EMAIL PROTECTED]> wrote: > > > > Pd shouldn't check for another pd running. It is extremely common to use > > two pd's at once. This is required due to conflicts between audio and > > video. This is even something that we teach to newbies in workshops, > > including how to circumvent OSX's "launch only once" feature. > > > > Agreed, but actually it would be good to have the choice as a comandline > arg of the first one launched with a way to accept patches to open in > the same instance from, say a web browser. Like also when you are in a file > manager and browsing some .pd files you really want them to open in the same > running instance. > > 2c > > a. > > ___ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [once] default closed...
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > I actually think that default closed would be more consistent > behavior, especially if [once] uses an argument. Changing [once] to > default-closed would make it exactly like [spigot], except with the > added feature of closing itself after receiving one piece of data. > > The more objects behave consistently with each other, the better Pd > will be. I still don't see the Why. [once] is used in a different context than [spigot] and to me, having [once] open as default is more natural for its use which is: let something pass *once* through the open path, then close the path until the object is reset to its initial state: open. Contrary to this [spigot] just like its counterpart in real life, a spigot for water, is normally closed and only opened on demand. (There was a time, when [spigot] didn't accept an argument, that was the time, when people invented [once]). As I don't use [once] I don't really care much about how [once] behaves, however changing the default is bound to create confusion, just like switching the inlets of atan2 did, and I can't really follow the motivation for this. Additionally the only use the [once] object has IMO is as a backwards compatibile shortcut for "[spigot 1]-[trigger a b]-[1]" from a time, when [spigot 1] wasn't invented yet. As a "default closed [once]" is so similar to [spigot], the need for having it as an abstraction at all is questionable. Regarding consistency: I hope you don't intend to switch the inlets of [timer] for the sake of consistency? ;-) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [once] default closed...
On Sep 11, 2006, at 7:47 PM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I was thinking that it would be nice to have [once] accept a single argument which would set the initial state of the object, just like [spigot]. But this means that it would have to be default closed like spigot, breaking backwards compatibility. Do you mind if I make this change in abstractions/purepd/once.pd and add a warning message on load? I've never used [once] but to me it seems that breaking compatibility just for something "that would be nice" may do more harm than good to people who have actually used [once] and who now would need to find and change the patches where they did. Additionally I would find it confusing to have a [once] which would actually be more like a [nonce] unless called with an argument. I actually think that default closed would be more consistent behavior, especially if [once] uses an argument. Changing [once] to default-closed would make it exactly like [spigot], except with the added feature of closing itself after receiving one piece of data. The more objects behave consistently with each other, the better Pd will be. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data (2 of 2)
On 13 Sep 2006, at 03:02, Mathieu Bouchard wrote: So for now, I guess we should simply be able to "open" pd's internal developments to see some kind of Darwinism Genetic evolution has more to do with monkeys on typewriters than about people wanting to make intelligent decisions. (Darwin knew this... even though typewriters didn't exist in his day) Hold on. This seems to make an argument *for* closed code, and for pumpkin holding, and therefore, in favour of Miller's control. Are you feeling ok, Matthieu? ;-) d -- David Plans Casal main at davidcasal dot com http://www.davidcasal.com ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data
Hi all, i didn't follow all of the discussion, so only minimal words from my side. I'm all for it as long as it happens in a separate cvs branch. It's already a lot of work to merge into devel_0_39 new changes by Miller (the 0.40 changes have still to be merged in) and this will explode once some refactoring has been done. all the best, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data (2 of 2)
On Wed, 13 Sep 2006, Chris McCormick wrote: but they have to understand that as the leader of the project it is completely Miller's right to reject patches that he doesn't want to see as part of his vision of Pd. As a human being, Miller has the right to reject patches. That doesn't mean that as a human being I have the duty to enjoy it. I genuinely believe that PureData is a fantastic piece of software in many ways (else I surely wouldn't have posted a thousand mails about PureData). I don't think that I would be complaining so much if there wasn't people insisting that I ought to submit my diffs to someone who doesn't want them. Hopefully I'll stop getting caught into that trap every damn time: it just makes me want to restate disagreements that I've already stated enough times and in a less angry way. I still have to learn about this. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
