Re: [PD] fundamental hot/cold midi question
Yves Degoyon skrev: ola, anyway, there's not only programming in life, hopefully, a programmer is someone who has the illusion of making the machine behave as a human brain one day, all he is achieving for now is to make the human brains behave like machines. this to tell programmers not to feel so superior.. i program but that's not the only thing i do. sevy __ Whatncannthenprogrammerntrancendntoon? Howncannthenprogrammerndecentn?n pulsed ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
ola, anyway, there's not only programming in life, hopefully, a programmer is someone who has the illusion of making the machine behave as a human brain one day, all he is achieving for now is to make the human brains behave like machines. this to tell programmers not to feel so superior.. i program but that's not the only thing i do. sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Fri, 28 Sep 2007, Atte André Jensen wrote: Mathieu Bouchard wrote: The problem that I have found with Sorry about the misunderstanding. I guess there were some history preceding this. Hey. If I write that kind of thing to you in private it most likely means that I don't want it posted on pd-list. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
hey mathieu and yves, both of you do some extraordinary work and I would not like to miss either one of you, so please stop huting each other. talk about your differences only after you figured out what you have in common. marius. Mathieu Bouchard wrote: On Thu, 27 Sep 2007, Hans-Christoph Steiner wrote: How about you two settle this in a different forum? Let's not scare the newbies! :D I know beforehand that nothing will ever get settled, so I will just refrain from replying anything to Degoyon in the future. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada ___ 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
Re: [PD] fundamental hot/cold midi question
Mathieu Bouchard wrote: On Fri, 28 Sep 2007, Atte André Jensen wrote: Mathieu Bouchard wrote: The problem that I have found with Sorry about the misunderstanding. I guess there were some history preceding this. Hey. If I write that kind of thing to you in private it most likely means that I don't want it posted on pd-list. don't worry, this MB ( i don't call him Bouchard, as i find this attitude offensive ) has an e-mail communication problem and thinks he can post his brilliant advices all the time to any list, all MB's lists, de facto. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Cana da ___ 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
Re: [PD] fundamental hot/cold midi question
Warrior Bob wrote: All kidding aside, it's good to see the list so active. I joined up last night figuring I'd hear lots of pd discussion I could learn from and I haven't been disappointed. It's an interesting system and I'd love to be able to do more with it. Just gotta hit the manuals. Manual in progress. More work to come Oct-Dec: http://en.flossmanuals.net/PureData best, d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 113: Make a blank valuable by putting it in an exquisite frame ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
ola, and thinks he can post his brilliant advices all the time to any list, all MB's lists, de facto. in fact, i'd better have said _pedantic_ remarks.. and i checked out desire data again, cos i hadn't follow too closely, just to check if i was not telling crap ( far from me the _desire_ to use it ! ), then i had 3 errors and 1 crash, just loading the 'Test Audio and Midi' patch.. hum, some better write more code and less papers or mails. sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
ola again, i'm the night night nightly nightmare This goes against FSF/GNU's FSD, rule Freedom Zero freedom zero rule ??? hahaha, can't say better of laws made by a bunch of hippies voting for democrats or conservative, just thinking what's funny here is the similarity between the GPL ( hippie style ) and the liberal laissez faire model, the two models is a i don't want to know solution... me, i want to know, and always call a f* a f*... ( and to TB who asked me to be polite, fuck your political correctness, when you were one of the firsts to shit on pd, and what's that new pd-like you're developping again ? karma desire super-high ? ) you have to know people died in Gaza these days for the well-programmed guiding systems, so when i see where it's going, there's no way i'll remove : NOT FOR MILITARY OR REPRESSIVE USE !!! and consider it illegal or not, you're a detail in history... sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
oh and sorry another remark, when i read stupid things here like 'girls don't dive into pd', i really think we're in level 0 of intelligence : a/ i don't think this encourages any further dialog, all these cheap 'cliches' ( or your reality ? ) b/ could you tell me who released transcribe~ lately for pd, was it a man ? c/ if i was complaining on that focus put on gender these days, it's only because i don't want to separate/discriminate people on this, and being different should be a wealth ya basta, sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
:ola, b/ could you tell me who released transcribe~ lately for pd, was it a man ? here, i didn't want to make a reference to some girls who contributed to pd too, and who are too close to me, they know who they are. i feel with all this shit on gender, we will get to : 'girls are not genetically prepared to programming' or all ugly american 'scientific' magazine shit. anyway, there's not only programming in life, hopefully, so don't judge someone badly if he doesn't know ( someone here is a boy or a girl ) sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
in fact, MB, i'm gonna tell you one more thing : you shouldn't be speaking on pd list at all, as you're _not_ contributing to pd, you're doing desire data... so, get back on your list and be the brilliant mind there, with all your fan club, and speaking of your life, of how you code ( standing up ) and of your cat, all things we don't give a fuck about here... me, i only see your racist and sexist shit.. ciao, sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Hallo, Stephen Sinclair hat gesagt: // Stephen Sinclair wrote: Since [t] is the official work-around for this issue it's certainly no show-stopper, but I think it would be nice, imho, if there were a cleaner way of representing this. I think, I finally agree with you here, except one thing: Using [trigger] is not a work-around and shouldn't be called that. [t] is the construct Pd offers to order instructions - just as much as [f] is the construct Pd offers to store numbers and not just a work-around to the problem, that numbers can change. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
marius schebella wrote: Derek Holzer wrote: It can get especially confusing when sends and receives get involved. the pd solution is not much better, you most of the times can not tell which receive will get a message first. marius. the pd solution is _much_ better: you use [trigger] or you produce a buggy patch. it does not aim to solve the problem implicitely. true it doesn't solve the problem either. fmadr.a IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
IOhannes m zmoelnig wrote: the pd solution is _much_ better: you use [trigger] or you produce a buggy patch. it does not aim to solve the problem implicitely. true it doesn't solve the problem either. please ignore this. i have misunderstood the problem. fmgads.r IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Thu, 2007-09-27 at 03:10 +0200, tim wrote: If you need to have a specific execution order, then you should use a [trigger]. It makes it explicit, which is a good thing. Hello, What makes this a bit tedious is that, if you insert a new argument inside [t b b b] to get [t f b b b], the connections already in place don't move one place to the right, so you have to manually remove and redraw all of them. Does anyone know if a feature request has ever been submitted for that? If not, I will gladly submit one. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Jamie Bullock wrote: Does anyone know if a feature request has ever been submitted for that? If not, I will gladly submit one. yes it has, and i have given an explanation (though no excuse) why this is not trivial to solve (or rather not at all, the way objects are currently created) it should be in the mailinglist archives somewhere fmasdr. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Thu, 27 Sep 2007, IOhannes m zmoelnig wrote: Jamie Bullock wrote: Does anyone know if a feature request has ever been submitted for that? If not, I will gladly submit one. yes it has, and i have given an explanation (though no excuse) why this is not trivial to solve (or rather not at all, the way objects are currently created) pffft, it's the same trick as what currently allows [pd] to not be recreated when its arguments change... there *is* a precedent. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: On Thu, 27 Sep 2007, IOhannes m zmoelnig wrote: Jamie Bullock wrote: Does anyone know if a feature request has ever been submitted for that? If not, I will gladly submit one. yes it has, and i have given an explanation (though no excuse) why this is not trivial to solve (or rather not at all, the way objects are currently created) pffft, it's the same trick as what currently allows [pd] to not be recreated when its arguments change... there *is* a precedent. Hm, but generally the outlet count doesn't change when a subcanvas is renamed. Do you think, the trick can be made to work for that as well? (Note: I don't know how nothing about how the trick works.) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Mathieu Bouchard wrote: On Thu, 27 Sep 2007, Yves Degoyon wrote: in my paper a type theory for the documentation of PureData this is very useless to quote oneself, gosh all this blah blah just to say everyone should use triggers, i speak of this in day 1 of a workshop. yves sévy encore... rien à faire... rien à cirer... except the fact that this is rude, but there were rudest things from you like accusing me of not doing free software, i wouldn't really give a shit if you were not bloating our e-mail box with 8 or 9 messages about triggers, self referencing and saying absolutely _nothing_, if not blurring everything. yeh ciao, sevy _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Cana da ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Thu, 27 Sep 2007, Yves Degoyon wrote: but there were rudest things from you like accusing me of not doing free software, http://lists.puredata.info/pipermail/pd-dev/2005-12/005585.html http://lists.puredata.info/pipermail/pd-dev/2005-12/005587.html You have to be a bully to accuse me of defending myself against you, and pretend not to remember that you attacked first. And then, yes, the Degoyon license is legally shady, there is no doubt about that. I'm not inventing this, http://lists.puredata.info/pipermail/pd-dev/2005-12/005596.html http://lists.puredata.info/pipermail/pd-dev/2005-12/005600.html But somehow you would ever admit a mistake like that, ever, and instead you just blame the whole pd community??? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Thu, 27 Sep 2007, Frank Barknecht wrote: Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: pffft, it's the same trick as what currently allows [pd] to not be recreated when its arguments change... there *is* a precedent. Hm, but generally the outlet count doesn't change when a subcanvas is renamed. Do you think, the trick can be made to work for that as well? (Note: I don't know how nothing about how the trick works.) there is a moveinletfirst command that is used for resorting inlets when using [inlet] and [outlet] inside of a [pd]. Modifying the number of [inlet] and [outlet] objects changes the number of inlets and outlets of a [pd] object. Therefore there is precedent for modifying the inlet-list and outlet-list of an object at runtime. GridFlow (since summer 2006) allows you to change the number of inlets and outlets of any object while it is on the canvas, just by saying something like self.inlets = 42 in the Ruby code. It will delete or create any number of inlets as necessary for that. If GridFlow can do it, Pd internals can do it. (GridFlow has a bug in that it expects inlets and outlets to be non-connected when they are deleted like that, but that's actually not really hard to fix, it's just that I didn't bother with it) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Mathieu Bouchard wrote: On Thu, 27 Sep 2007, Yves Degoyon wrote: but there were rudest things from you like accusing me of not doing free software, http://lists.puredata.info/pipermail/pd-dev/2005-12/005585.html http://lists.puredata.info/pipermail/pd-dev/2005-12/005587.html You have to be a bully to accuse me of defending myself against you, and pretend not to remember that you attacked first. And then, yes, the Degoyon license is legally shady, there is no doubt about that. I'm not inventing this, http://lists.puredata.info/pipermail/pd-dev/2005-12/005596.html http://lists.puredata.info/pipermail/pd-dev/2005-12/005600.html But somehow you would ever admit a mistake like that, ever, and instead you just blame the whole pd community??? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Cana da ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list all is assumed there, and with reasons, you stupid innocent i like the : This goes against FSF/GNU's FSD, rule Freedom Zero freedom zero rule ??? hahaha, can't say better of laws made by a bunch of hippies voting for democrats or conservative, you're already dead, and when i saw your ideal city ( montreal ), it was just like a copy of a consumer society, all dead. anyway, remove pidip from pd-extended, me i don't give a f*** about having users. hasta nunca, sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Sep 27, 2007, at 12:33 PM, Mathieu Bouchard wrote: On Thu, 27 Sep 2007, Yves Degoyon wrote: but there were rudest things from you like accusing me of not doing free software, http://lists.puredata.info/pipermail/pd-dev/2005-12/005585.html http://lists.puredata.info/pipermail/pd-dev/2005-12/005587.html You have to be a bully to accuse me of defending myself against you, and pretend not to remember that you attacked first. And then, yes, the Degoyon license is legally shady, there is no doubt about that. I'm not inventing this, http://lists.puredata.info/pipermail/pd-dev/2005-12/005596.html http://lists.puredata.info/pipermail/pd-dev/2005-12/005600.html But somehow you would ever admit a mistake like that, ever, and instead you just blame the whole pd community??? How about you two settle this in a different forum? Let's not scare the newbies! :D .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list http://at.or.at/hans/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Thu, 27 Sep 2007, Hans-Christoph Steiner wrote: How about you two settle this in a different forum? Let's not scare the newbies! :D I know beforehand that nothing will ever get settled, so I will just refrain from replying anything to Degoyon in the future. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Atte André Jensen wrote: If someone could enlighten me, I'd be most happy :-) generally i often find it easier to use a list instead of separate outlets. this way elements that belong together are also grouped together. (if you need the separate values, you can always use [pack]) mfga.dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote: Right now I'm pretty confused. What did I miss? In retrospect, it seems very odd to me that switching the lines sending velocity ad note in arp would have any effect. I would expect those to lines to happen simultaneously at least from interconnected pd-objects point of view. But that's exactly where the do *not* happen simultaneously! Imaging a [+] object connected to the outlets to add note and velocity. The result depends on which one comes first, as only the left inlet of [+] is hot. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Right now I'm pretty confused. What did I miss? In retrospect, it seems very odd to me that switching the lines sending velocity ad note in arp would have any effect. I would expect those to lines to happen simultaneously at least from interconnected pd-objects point of view. Personally I consider this to be a somewhat fundamental problem in Pd: There is actually no way, looking at an outlet with several lines coming out of it, to determine what order they will trigger. It actually depends on what order you connected them in. To me this is important information that is simply _missing_ in Pd's graphical representation. Note that this is not true in Max/MSP: messages are always triggered from right to left. It would be nice to fix it, but unfortunately doing so would probably affect backwards-compatibility with people's patches. Anyways, if you have something which absolutely depends on the order in which a message is sent out multiple connections, insert the [t] object to re-trigger the same message several times, and make one connection per outlet. Messages will be ordered from right to left. My patches are just full of triggers like this. Steve ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On 9/26/07, Stephen Sinclair [EMAIL PROTECTED] wrote: Right now I'm pretty confused. What did I miss? In retrospect, it seems very odd to me that switching the lines sending velocity ad note in arp would have any effect. I would expect those to lines to happen ... My patches are just full of triggers like this. Steve This is not a fundamental problem if you program PD idiomatically. PD is not Max! In PD, having multiple lines out of an outlet is typically considered to be a patching error. Sometimes I do it from laziness in situations where order doesn't matter, but really it's incorrect. Using triggers is the correct way of programming in the PD idiom. Actually, once you get used to PD, max patches typically look far less 'logical', in my opinion. Why do you consider this a fundamental problem exactly? ~David ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Howdy all, David Powers wrote: Actually, once you get used to PD, max patches typically look far less 'logical', in my opinion. Actually, the fact that on-screen position affects order of operations at all is very illogical if you ask me. It can get especially confusing when sends and receives get involved. If the subpatch with the receive is nested three layers deep on the left hand side of the screen, but the send is on the right, when does it do it's thing? (Don't ask me, I've never really used MAX...) And if moving that subpatch a few pixels to the right can change the functioning of an entire patch, that is a very fundamental flaw for sure! Getting used to [trigger] is fundamental to using PD. It confuses the hell out of workshop participants the first time you explain it, but by the end every one of them has usually come up to me asking me to sort out an order of operations problem that can be easily solved by using it. best, d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 28: Change nothing and continue consistently ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Sep 26, 2007, at 11:57 AM, Stephen Sinclair wrote: Right now I'm pretty confused. What did I miss? In retrospect, it seems very odd to me that switching the lines sending velocity ad note in arp would have any effect. I would expect those to lines to happen simultaneously at least from interconnected pd-objects point of view. Personally I consider this to be a somewhat fundamental problem in Pd: There is actually no way, looking at an outlet with several lines coming out of it, to determine what order they will trigger. It actually depends on what order you connected them in. To me this is important information that is simply _missing_ in Pd's graphical representation. Note that this is not true in Max/MSP: messages are always triggered from right to left. It would be nice to fix it, but unfortunately doing so would probably affect backwards-compatibility with people's patches. Anyways, if you have something which absolutely depends on the order in which a message is sent out multiple connections, insert the [t] object to re-trigger the same message several times, and make one connection per outlet. Messages will be ordered from right to left. My patches are just full of triggers like this. Graphical execution order is a much worse problem than Pd's 'undefined' execution order of connections. It is far too easy to break a patch by moving bits around, and then it would be very difficult to debug. Graphical execution order was explicitly removed from Pd because of the trouble it caused. If you need to have a specific execution order, then you should use a [trigger]. It makes it explicit, which is a good thing. .hc Steve ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list If you are not part of the solution, you are part of the problem. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Derek Holzer wrote: It can get especially confusing when sends and receives get involved. the pd solution is not much better, you most of the times can not tell which receive will get a message first. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Hallo, David Powers hat gesagt: // David Powers wrote: Actually, once you get used to PD, max patches typically look far less 'logical', in my opinion. Actually I believe that even among Max users, using the trigger is considered good practice (at least the Max users in my area tell me this.) In Pd, this good practice is enforced or rather, the bad practice will get you into trouble soon, while in Max you have a bit more time before you get into trouble as well. ;) Triggers are a bit inconventient, of course, as it's an additional object to create plus more connections to make. I think, Matju once had the idea of a magically appearing trigger-like outlet extension, that would pop up as soon as you try to draw another patch cord from an already connected outlet. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Sep 26, 2007, at 1:01 PM, Derek Holzer wrote: Howdy all, David Powers wrote: Actually, once you get used to PD, max patches typically look far less 'logical', in my opinion. Actually, the fact that on-screen position affects order of operations at all is very illogical if you ask me. It can get especially confusing when sends and receives get involved. If the subpatch with the receive is nested three layers deep on the left hand side of the screen, but the send is on the right, when does it do it's thing? (Don't ask me, I've never really used MAX...) And if moving that subpatch a few pixels to the right can change the functioning of an entire patch, that is a very fundamental flaw for sure! Getting used to [trigger] is fundamental to using PD. It confuses the hell out of workshop participants the first time you explain it, but by the end every one of them has usually come up to me asking me to sort out an order of operations problem that can be easily solved by using it. Do you have any good examples to illustrate that? I wrote this one, but it's a bit boring: http://pure-data.cvs.sourceforge.net/*checkout*/pure-data/doc/ tutorials/intro/16.ordering_messages.pd?revision=1.4 .hc best, d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 28: Change nothing and continue consistently ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, IOhannes m zmoelnig wrote: Atte André Jensen wrote: If someone could enlighten me, I'd be most happy :-) generally i often find it easier to use a list instead of separate outlets. this way elements that belong together are also grouped together. (if you need the separate values, you can always use [pack]) you mean [unpack]... and it makes me think of what i thought about for documentation and factorisation purposes: think of some classes as being unpack-like, which means that when it outputs something, it outputs one value per outlet while respecting right-to-left order, and every output is an atom. It happens that the easiest way to implement this is by putting a [unpack] object near the bottom with a bunch of [outlet] objects on it. Regardless of the implementation, objects could be tested from the outside for accurate order: if I declare that a certain class is an unpack-like with 4 outlets then a wrapper would be made which would figure out whether any outputs are correctly made. It would be a nice shortcut to have a class called [outlets] which would count as N [outlet]s in a row and an [unpack]. Currently, documentation does not systematically say when it is that the order is right-to-left and when it is not. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, Derek Holzer wrote: Actually, the fact that on-screen position affects order of operations at all is very illogical if you ask me. If it is so, then please figure out what to do with [inlet]s and [outlet]s because those objects change behaviour according to position in the patch! Getting used to [trigger] is fundamental to using PD. It confuses the hell out of workshop participants the first time you explain it, Is it that it confuses them, or they were already confused by looking at pd and then you see them in the process of getting deconfused? I think that any significant concept will confuse users like that, especially if so far they had to make guesses and assumptions that are potentially and probably wrong, because they had to use a feature before understanding the feature. This can be especially unavoidable near the beginning, because there is that big knot of concepts that would ideally need to be digested all at once but the conceptual stomach is not big enough to hold all those new concepts together. One has to start *somewhere*... IMHO the more you delay explanations about fundamental stuff like that, the more you have to make students unlearn preconceptions that they built by practising pd without the explanations that they needed. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 2007-09-26 at 11:57 -0400, Stephen Sinclair wrote: It would be nice to fix it, but unfortunately doing so would probably affect backwards-compatibility with people's patches. Anyways, if you have something which absolutely depends on the order in which a message is sent out multiple connections, insert the [t] object to re-trigger the same message several times, and make one connection per outlet. Messages will be ordered from right to left. My patches are just full of triggers like this. ...so are my _Max_ patches, otherwise I find things quickly become a complete mess (visually and logically). Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On 26/09/2007, at 17.57, Stephen Sinclair wrote: looking at an outlet with several lines coming out of it, to determine what order they will trigger. I think the question, from Atte, was about the order in case of multiple outlets of an object. That is not about multiple lines/ connections out of a single outlet. The remaining question is, as i see it, the following. Atte wrote in the original email in this thread: So I thought, let's go through [legato] and in a similar fashion send velocities before notes. However that didn't work, there were no sound, probably because somewhere in the midi stream noteon's were thrown away. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, marius schebella wrote: Derek Holzer wrote: It can get especially confusing when sends and receives get involved. the pd solution is not much better, you most of the times can not tell which receive will get a message first. This depends on creation order of objects, that is, in which order they appear in the patch file, or when you create them in the patch. If you save and reload, you won't necessarily get the same order, if the multiple receives involve any subpatch or abstraction. I very much advise not to rely on any specific order, even when making predictable patterns of dynamic patching, although pd probably won't change its multiple-receive handler anytime soon. I think that the best reason for this is because in a visual language you should be seeing all of your code: all objects and all wires as they are and you shouldn't need anything else (several GUI objects don't respect this rule though, but it's not as bad as relying on creation order). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On 26/09/2007, at 20.33, Mathieu Bouchard wrote: Currently, documentation does not systematically say when it is that the order is right-to-left and when it is not. Risking to repeat your point(?): Since it's possible to make it not right-to-left, shouldn't that be considered a flaw (in the doc for that object/class)? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, Steffen wrote: On 26/09/2007, at 20.33, Mathieu Bouchard wrote: Currently, documentation does not systematically say when it is that the order is right-to-left and when it is not. Risking to repeat your point(?): Since it's possible to make it not right-to-left, shouldn't that be considered a flaw (in the doc for that object/class)? One of my big points about documentation, in my paper a type theory for the documentation of PureData, is that documentation should be as complete as that, mentioning little details like this all of the time, so that there is no ambiguities and nothing hidden. This is more work. More work means that it's more effort to write documentation like that in the current style of documentation. This is one reason why I propose a style of documentation in which there is a vocabulary of concepts that are not directly found as object classes and which categorise object classes in multiple ways about what you can expect from them. This makes the necessary shortcuts in documentation that improves the ease of writing documentation enough that it becomes easy to mention every little detail and at the same time spend less time writing documentation and at the same time need less time to read documentation and at the same time learn more about pd. Maybe I didn't write as much as that on that topic in the actual paper, as I was already well over the maximum allowed length. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Why do you consider this a fundamental problem exactly? Because there is information about the data-flow of the program that is simply not represented by what you are seeing. I consider that pretty fundamental. However, as I said, there is the [trigger] work-around, and that's fine. I don't personally like to require these extra objects however. (Of course they are quite useful sometimes, but I don't want to be forced to use so many of them..) I didn't mean to push people's buttons by making the faux pas of a comparison with Max, but in this respect I do find that at least Max has a deterministic way of showing what messages are going to send in what order. I consider this an improvement, but you certainly don't have to. It's also not necessarily the *best* way this problem could be solved, because as others have suggested, too much dependence on the locations of objects creates its own issues. Another solution might be to explicitly number the patch cords, for example. Personally I just consider that if a program is represented graphically, one should be able to take a look at this representation and figure out how it works by inspection, without having to do any testing. If the patch makes use of multiple outs from an outlet, this is simply not the case. Steve ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On 26/09/2007, at 21.06, Mathieu Bouchard wrote: Maybe I didn't write as much as that on that topic in the actual paper, as I was already well over the maximum allowed length. Id say: Spice that paper with all of that and distribute it. I'd like to read it. Lenght should not be a problem as long as you stay true to your reductionist and concise approach -- that's what it seam to promise anyhoo. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Steffen wrote: I think the question, from Atte, was about the order in case of multiple outlets of an object. That is not about multiple lines/ connections out of a single outlet. I've been working a lot on the external since then. And after a complete rewrite 2 times, it works very robust even with two outlets. I still have a few ideas I might throw in, but for now it works really well. -- peace, love harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://atte.dk/compositions ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, Stephen Sinclair wrote: I didn't mean to push people's buttons by making the faux pas of a comparison with Max, but in this respect I do find that at least Max has a deterministic way of showing what messages are going to send in what order. I consider this an improvement, but you certainly don't have to. It's also not necessarily the *best* way this problem could be solved, because as others have suggested, too much dependence on the locations of objects creates its own issues. If you start with the idea that there should be this feature, then you should have some kind of support from the editor that prevents the downside of it, which is to change behaviour accidentally by trying to reformat the appearance of a patch (moving objects around). If right-to-left order of wires is so important, prevent simple object motion from going past another object connected to from the same outlet, and introduce some different way of permuting those wires. Another solution might be to explicitly number the patch cords, for example. This wouldn't prevent the reformatting problems, unless there is obvious highlighting of any permutation of destinations. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Hallo, Steffen hat gesagt: // Steffen wrote: On 26/09/2007, at 17.57, Stephen Sinclair wrote: looking at an outlet with several lines coming out of it, to determine what order they will trigger. I think the question, from Atte, was about the order in case of multiple outlets of an object. That is not about multiple lines/ connections out of a single outlet. But it's all connected! ;) The generally right-to-left temperature agreement of hot and cold inlets in objects has very deep consequences. Outlets generally fire right to left *because* generally the cold inlets are are on the right and they get hotter until you reach the hot inlet on the left. Even the usual example of a reversed inlet-order, [timer], is reversed *because* outlets of important other objects fire right to left, namely [t b b] which gives the nice [t b b] | | [timer] idiom without crossing wires. And connected to the problem of ordering is the problem of how to deal with multiple cords leaving one outlet, that in Pd practically have undefined order. Another thing, people often forget is that they should take great care to also make abstractions fire accordingly, usually right-to-left, and also make them expect their inlet data in that order (or in another order like [timer], but then deliberatly, not just because one didn't think of the order). Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Sorry I can't quote correctly, I'm typing from a mobile. Regarding [outlet]s (and inlets) being position dependent, I've always felt they should accept an argument like [outlet 0] etc to specify which they should be on the outside, and perhaps revert to the current behavior with no argument. Also, regarding timer and other exceptions for cosmetics, I think these do more harm than good; I often have trouble remembering their specialness. On 9/26/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Steffen hat gesagt: // Steffen wrote: On 26/09/2007, at 17.57, Stephen Sinclair wrote: looking at an outlet with several lines coming out of it, to determine what order they will trigger. I think the question, from Atte, was about the order in case of multiple outlets of an object. That is not about multiple lines/ connections out of a single outlet. But it's all connected! ;) The generally right-to-left temperature agreement of hot and cold inlets in objects has very deep consequences. Outlets generally fire right to left *because* generally the cold inlets are are on the right and they get hotter until you reach the hot inlet on the left. Even the usual example of a reversed inlet-order, [timer], is reversed *because* outlets of important other objects fire right to left, namely [t b b] which gives the nice [t b b] | | [timer] idiom without crossing wires. And connected to the problem of ordering is the problem of how to deal with multiple cords leaving one outlet, that in Pd practically have undefined order. Another thing, people often forget is that they should take great care to also make abstractions fire accordingly, usually right-to-left, and also make them expect their inlet data in that order (or in another order like [timer], but then deliberatly, not just because one didn't think of the order). Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ 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
Re: [PD] fundamental hot/cold midi question
On Wed, 2007-09-26 at 11:57 -0400, Stephen Sinclair wrote: Right now I'm pretty confused. What did I miss? In retrospect, it seems very odd to me that switching the lines sending velocity ad note in arp would have any effect. I would expect those to lines to happen simultaneously at least from interconnected pd-objects point of view. Personally I consider this to be a somewhat fundamental problem in Pd: There is actually no way, looking at an outlet with several lines coming out of it, to determine what order they will trigger. this is clearly a problem of your side, and i would even consider it as a bug of the patch. use [trigger]s, whereever you can. this is MUCH cleaner, than max' graphic representation, that can be messed up so easily. 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
Re: [PD] fundamental hot/cold midi question
On Wed, 2007-09-26 at 13:12 -0400, marius schebella wrote: Derek Holzer wrote: It can get especially confusing when sends and receives get involved. the pd solution is not much better, you most of the times can not tell which receive will get a message first. marius. also here: if it order matters, just don't use the same [receive], but a separate one. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, Steffen wrote: On 26/09/2007, at 21.06, Mathieu Bouchard wrote: Maybe I didn't write as much as that on that topic in the actual paper, as I was already well over the maximum allowed length. Id say: Spice that paper with all of that and distribute it. I'd like to read it. Lenght should not be a problem as long as you stay true to your reductionist and concise approach -- that's what it seam to promise anyhoo. I had to look up the word reductionist, because I had been so much filled with the postmodern mysticism that permeates contemporary culture, that I was assuming it meant something else. In the general sense offered by http://en.wikipedia.org/wiki/Reductionism , it makes a lot more sense. About the other meanings: http://www.cato.org/pub_display.php?pub_id=3045 talks in favour of reductionism in an interesting way. Also, I've seen the concept of Greedy Reductionism being said Reductionism, which certainly confuses matters, and confused me for a long time. For a written program (including pd patches but excluding the training of neural networks), the complete construction of the program is based on other existing constructions, so actually it can't be anything else than reductionist in terms of looking at the implementation or even the interface, but certainly it is the case that introducing intermediate levels of structure of explanations, can be called more reductionist than not doing it. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
this is clearly a problem of your side, and i would even consider it as a bug of the patch. use [trigger]s, whereever you can. this is MUCH cleaner, than max' graphic representation, that can be messed up so easily. After some thought on the subject, I realize that of course if the Pd language states that multiple lines coming from an outlet have an undefined order, then the inability to determine their ordering cannot be considered a deficit. So I'll rephrase my previous assertion that this is a fundamental problem with Pd: This is a fundamental _issue_ with Pd, which some might consider problematic, or at the very least, annoying. But by definition, not technically erroneous. I think that perhaps better summarizes my opinion here.. Since [t] is the official work-around for this issue it's certainly no show-stopper, but I think it would be nice, imho, if there were a cleaner way of representing this. But it's certainly not as important as other things that need work. However, as seen in this thread, it is sometimes an very confusing issue for beginners in Pd, especially if they have any kind of previous experience with Max. Steve ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
Hi again, Stephen Sinclair wrote: However, as seen in this thread, it is sometimes an very confusing issue for beginners in Pd, especially if they have any kind of previous experience with Max. Generally, the beginners I am teaching have *no* experience with PD or MAX, so it is simply a matter of teaching them that computers are dumb animals, and that you have to be very clear about what order you want them to do things, or they might do them in the wrong order (or not at all!). Explaining that screen position determines it is one way out, and saying that they must declare what order things will happen with [trigger] is another way out. Which one seems to make more sense? It depends on who you ask, and what their background is. If they have a background with programming at all, of course. People coming to visual programming languages from text-based ones, with very clear DO, WHILE, UNTIL and etc loops, are often horrified by what they see as an absolute arbitrariness in the order of operations. They might argue that basing it on screen position is entirely too arbitrary. I am inclined to agree. So I am very careful when instructing newcomers about these kinds of things. Unlike Mathieu's (hopefully facetious) comment some emails back on this thread, I would rather not leave them in the dark to struggle for themselves about it, because that's exactly the point where most people throw up their hands and leave PD behind. When working with beginners, I don't think that [trigger] throws up any more difficulties than any other thing in PD. It's the concept of an order of operations in computing that is confusing and must be learned, regardless of the way in which it is handled. best, d. -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 38: Courage! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
If you need to have a specific execution order, then you should use a [trigger]. It makes it explicit, which is a good thing. Hello, What makes this a bit tedious is that, if you insert a new argument inside [t b b b] to get [t f b b b], the connections already in place don't move one place to the right, so you have to manually remove and redraw all of them. Tim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
hola, in my paper a type theory for the documentation of PureData this is very useless to quote oneself, gosh all this blah blah just to say everyone should use triggers, i speak of this in day 1 of a workshop. saludos, sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Thu, 27 Sep 2007, Yves Degoyon wrote: in my paper a type theory for the documentation of PureData this is very useless to quote oneself, gosh all this blah blah just to say everyone should use triggers, i speak of this in day 1 of a workshop. yves sévy encore... rien à faire... rien à cirer... _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Thu, 27 Sep 2007, Derek Holzer wrote: So I am very careful when instructing newcomers about these kinds of things. Unlike Mathieu's (hopefully facetious) comment some emails back on this thread, I would rather not leave them in the dark to struggle for themselves about it, because that's exactly the point where most people throw up their hands and leave PD behind. I never advised you anything else than teaching it as soon as possible. I think you could reread my other email and tell me what is wrong with it. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, Stephen Sinclair wrote: Since [t] is the official work-around for this issue it's certainly no show-stopper, but I think it would be nice, imho, if there were a cleaner way of representing this. Perhaps you need to think about why you think that it is unclean. What is cleanliness? Perhaps [t] is clean and just needs some advocacy about it? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, Luke Iannini (pd) wrote: Regarding [outlet]s (and inlets) being position dependent, I've always felt they should accept an argument like [outlet 0] etc to specify which they should be on the outside Chances are that I requested this in 2002. I was using that feature from 2001 to 2003, but I had to give it up when switching to pd... with tears, or something. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fundamental hot/cold midi question
On Wed, 26 Sep 2007, Frank Barknecht wrote: Even the usual example of a reversed inlet-order, [timer], is reversed *because* outlets of important other objects fire right to left, namely [t b b] which gives the nice [t b b] | | [timer] idiom without crossing wires. There is a use for both [t b b] | | [realtime] and [t b b] \ / X / \ [realtime] and I don't think that the straight line pattern is any cleaner than the crossed line pattern. I use both all of the time. Many object classes have both a use with straight lines and a use with crossed lines. Crossed lines themselves are not bad. It's not like it's any hard to follow the flow along a small cross. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
