Hi
So I made to externals, [arp] (arpeggiator) and [legato] (legato monophonic midi module). My idea for both of them to be insertable "in a midi stream" for instance just after [notein], so they both have (amongst other things) a note inlet (leftmost, hot) and velocity (second to the left, cold).
They both worked fine by themselves, but one of my tests for [arp] show a problem: when it's note and velocity outlets were connected to the corresponding inlets of legato, legato would miss some noteoff's (resulting in hanging notes).
After some debugging I the hot/cold inlet thing came to mind. It turned out that in the code of [arp] I had outputted the note value (just) before the velocity, and if I reversed that sending order, [legato] would get all it's noteoffs and the hanging problem is gone.
Fine. I thought I had it all sorted out, it must have been because [arp] was sending its note first. Since the note outlet was connected to the hot note-inlet of [legato], legato would be triggered of the note and look at the velocity outlet, where [arp] hadn't yet made anything available.
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.
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.
If someone could enlighten me, I'd be most happy :-)
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
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
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)?
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
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.
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
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
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
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
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
Yves Degoyon wrote:
anyway, remove pidip from pd-extended, me i don't give a f*** about having users.
Hmmm. If we take this to the extreme all externals, actually pd itself should be removed from public download.
I'm sad that my initial post has stated this flamewar :-(
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
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
: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
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
On Sat, Sep 29, 2007 at 05:22:07AM +0200, Yves Degoyon wrote:
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..
cat > .procmailrc << EOF :0
- ^From: matju@artengine.ca
/dev/null EOF
Best regards,
Chris.
cat > .procmailrc << EOF :0
- ^From: matju@artengine.ca
/dev/null EOF
Best regards,
Chris.
yeh i think people understand me when i complain about MB's spam, and also, about the fact that the pd convention was MB convention ( of course, when you're in the convention comittee and that you worked previously with all the curators out there ), the main point is that all his communication is 'du vent' to speak french, actually just nothing ( advertising things that do not work )
but i think the group with hans, marius, thomas, .. ( sorry for those i forget ) started to make some good work there, like the pd-extended is a nice effort, and i don't want to break this.
so, back to serious code, please.
saludos, sevy
On Sun, Sep 30, 2007 at 04:47:59PM +0200, Yves Degoyon wrote:
cat > .procmailrc << EOF :0
- ^From: matju@artengine.ca
/dev/null EOF
Best regards,
Chris.
yeh i think people understand me when i complain about MB's spam, and also, about the fact that the pd convention was MB convention ( of course, when you're in the convention comittee and that you worked previously with all the curators out there ), the main point is that all his communication is 'du vent' to speak french, actually just nothing ( advertising things that do not work )
but i think the group with hans, marius, thomas, .. ( sorry for those i forget ) started to make some good work there, like the pd-extended is a nice effort, and i don't want to break this.
so, back to serious code, please.
Just to be clear; the aim of my email is to provide you with a technical solution to your problem with Matju's verbosity, nothing else. I am super-uninterested in what either of you have to say about each other, and I am hoping this solution will mean I don't have to read about it again.
Keep on hacking, best regards,
Chris.
ola,
your problem with Matju's verbosity
believe me that i have other things to do that spending time and energy in childish arguments, if it was not more serious than that, and that's it's not only about verbosity, it's about pedantness, sexist and white american 'scientific' logic that is spreaded here, and that becomes, de facto, the image of the _whole_ pd community, if ever there is one.
so yeh comments like 'i can teach pd to some girls' or 'girls don't dive into pd' should be banned from here, just to quote the most obvious.
saludos, sevy
last one, promised!
so yeh comments like 'i can teach pd to some girls' or 'girls don't dive into pd' should be banned from here, just to quote the most obvious.
just to finish with that, why should i read such cynical shit like this ?
On Aug 22, 2007, at 8:25 AM, Mathieu Bouchard wrote:
/
/>/ Because those threads are woven by illegal Mexican immigrants who
/>/ steal the jobs of citizens of California, that's why!
/
haha, so funny to make jokes on immigrants... when canadians are surely immigrants somehow that kicked out the initial dwellers and not softly ( do you know khanawakee ? that's where they park indians, just outside of MTL ) / ciao, sevy /
/
/
On Sun, 2007-09-30 at 16:47 +0200, Yves Degoyon wrote:
cat > .procmailrc << EOF :0
- ^From: matju@artengine.ca
/dev/null EOF
Best regards,
Chris.
yeh i think people understand me when i complain about MB's spam,
sorry, no. i do not understand that at all.
and also, about the fact that the pd convention was MB convention ( of course, when you're in the convention comittee and that you worked previously with all the curators out there ),
i ask you to keep respectful for any other person on the list.
actually, i wanted to stay completely out of this, but since you are starting a hate campaign against one single person on a public mailing list, i think, i should at least ask you to calm down, please.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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
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
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/
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
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
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__
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
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.
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
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
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
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
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__
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
On 9/26/07, Stephen Sinclair radarsat1@gmail.com 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
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.
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
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
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
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
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
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__
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
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
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
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.
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.
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__
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 fbar@footils.org 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
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
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
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
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
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.
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
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
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__
-
Atte André Jensen -
Chris McCormick -
David Powers -
Derek Holzer -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock -
Luke Iannini (pd) -
marius schebella -
Mathieu Bouchard -
Roman Haefeli -
Steffen -
Steffen Leve Poulsen -
Stephen Sinclair -
tim -
Yves Degoyon