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
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..
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
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
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
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
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_
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 (
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~
: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
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
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:
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
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
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
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
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,
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
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
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
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
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
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
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.
_ _ __ ___ _
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,
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
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
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
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
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
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
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
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.)
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
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
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
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
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
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,
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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 à
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
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
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
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
59 matches
Mail list logo
