Hallo,
Patco hat gesagt: // Patco wrote:
Patco a écrit :
The most deluding stuff is $0 for my concern, it's very harassing to
not being able to use it in messages.
all the other craps are quite tolerable here with last versions.
[i $0]
|
[$1(
is harassing/boring too.
What about this?
Frank Barknecht a écrit :
Hallo,
Patco hat gesagt: // Patco wrote:
Patco a écrit :
The most deluding stuff is $0 for my concern, it's very harassing to
not being able to use it in messages.
all the other craps are quite tolerable here with last versions.
[i $0]
|
[$1(
is
On Dec 31, 2006, at 4:32 PM, Mathieu Bouchard wrote:
On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote:
But how does the type of those cords represent anything else than
limitations of the implementation? How does the choice of
On Dec 31, 2006, at 5:09 PM, carmen wrote:
Yes, a lot of this kind of stuff is done for efficiency's sake,
like messages vs. audio rate data.
also for efficieny's sake (on the implementation side), some of the
newer graphical dataflow / patcher engines consider them one and
the same,
On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote:
On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote:
Much more importantly, the thick coords represent that a different
data type is passing thru the coords. It's not really an issue of
representing the implementation, instead it's
On Dec 30, 2006, at 10:41 PM, David NG McCallum wrote:
On 27/12/06, Tim Blechmann [EMAIL PROTECTED] wrote:
Do you mean that it would be difficult to figure out what's a
DSP object
and what's not, in terms of figuring out what's in the DSP chain?
from the user point of view, i think,
On Dec 30, 2006, at 5:14 PM, Mathieu Bouchard wrote:
On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote:
Pd is strongly typed, so floats and signal data are different
types, just like floats and symbols.
What is a type? (without just giving a list of the existing types
in pd)
What does
On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 30, 2006, at 5:14 PM, Mathieu Bouchard wrote:
Have you read what I wrote to you, about strongly typed being vague
wording?
I think the wikipedia page does a pretty good job of describing it:
http://en.wikipedia.org/wiki/Strong_typing
On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote:
But how does the type of those cords represent anything else than
limitations of the implementation? How does the choice of considering those
things as distinct types, and the choice to not
Yes, a lot of this kind of stuff is done for efficiency's sake, like messages
vs. audio rate data.
also for efficieny's sake (on the implementation side), some of the newer
graphical dataflow / patcher engines consider them one and the same, and solve
the rate-efficiency issue by allowing a
Patco a écrit :
The most deluding stuff is $0 for my concern, it's very harassing to
not being able to use it in messages.
all the other craps are quite tolerable here with last versions.
[i $0]
|
[$1(
is harassing/boring too.
On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote:
Much more importantly, the thick coords represent that a different data
type is passing thru the coords. It's not really an issue of
representing the implementation, instead it's representing that those
two types of coords can not be
On 27/12/06, Tim Blechmann [EMAIL PROTECTED] wrote:
Do you mean that it would be difficult to figure out what's a DSP object
and what's not, in terms of figuring out what's in the DSP chain?
from the user point of view, i think, it's a good idea, to have a
specific separation between dsp and
On Sat, 30 Dec 2006, David NG McCallum wrote:
If we're to think about the metaphor of dataflow languages, which is
essentially modelled after electronics and circuits (and I'm thinking
about analogue circuits, although I'm sure a similar argument could be
made for digital), then there should
why is there no |!/~| object like in max/msp?
I don't know. Where's the [swap] that can support signals? ;)
well, a |swap| object itself is not a really good solution without an
optimizing compiler for the dsp chain ...
and why is expr~ so slow?
I don't know, this might deserve a look
If there was no DSP chain, or if the chain included all of the non-DSP,
we might delay such determination until later... (but should we?)
if there was no dsp chain, it would be easier to utilize several audio
threads (see jackdmp) ... caching would definitely be worse, though ...
But
--- Tim Blechmann [EMAIL PROTECTED] schrieb:
and why is expr~ so slow?
I don't know, this might deserve a look (or a
rewrite).
sample-wise dsp processing is usually way slower
than block-wise. iirc,
i read something about a factor 2 ...
afaik, [expr~] does non-recursive /
On Dec 27, 2006, at 12:01 PM, Mathieu Bouchard wrote:
I have some newbie questions here...
why is it that [*] is only for floats, whereas if you want to
multiply two signals one has to use [*~] ?
Pd is strongly typed, so floats and signal data are different types,
just like floats and
Haha at first I didn't see who posted this and thought, 'what a newb...'
Now I'm thinking that some philosophic sparring of Pd fundamentals is about
to begin. I'll make some popcorn and watch this one from the sidelines...
~Kyle
On 12/27/06, Mathieu Bouchard [EMAIL PROTECTED] wrote:
I
some follow-ups:
why is it that [*] is only for floats, whereas if you want to multiply two
signals one has to use [*~] ?
why do patch cords have different width?
And then why is it that [*~] can multiply a signal by a float, but [*]
can't do that?
why can |*~| multiply two signals, but
Hallo!
Hm ... what do you want to say ?
You want polymorphism ?
LG
Georg
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
I have some newbie questions here...
why is it that [*] is only for floats, whereas if you want to multiply two
signals one has to use [*~] ?
And then why is it that [*~] can multiply a signal by a float, but [*] can't
do that?
because according to Pd rules its not OK to confuse the user
What about efficiency? There may be certain advantages to defining
the data types, and constraining _inlets_ and atom types during
editing, rather than at run time. (that's just a guess)
Hm ... what do you want to say ? You want polymorphism ?
I say what I say. I'm asking, would we prefer
On Wed, 2006-12-27 at 13:43 -0500, Mathieu Bouchard wrote:
On Wed, 27 Dec 2006, Georg Holzmann wrote:
Hm ... what do you want to say ? You want polymorphism ?
I say what I say. I'm asking, would we prefer polymorphism in this
particular circumstance, and why or why not.
(Of course I
On Wed, 27 Dec 2006, carmen wrote:
Matju wrote:
why is it that [*] is only for floats, whereas if you want to multiply
two signals one has to use [*~] ? And then why is it that [*~] can
multiply a signal by a float, but [*] can't do that?
because according to Pd rules its not OK to confuse the
On Wed, 27 Dec 2006, Tim Blechmann wrote:
well, does polymorphism improve the expressive power in terms of
determination between messaging and dsp?
I can't answer because I can't guess what you mean by determination
here.
Do you mean that it would be difficult to figure out what's a DSP
On Wed, 2006-12-27 at 15:40 -0500, Mathieu Bouchard wrote:
On Wed, 27 Dec 2006, Tim Blechmann wrote:
well, does polymorphism improve the expressive power in terms of
determination between messaging and dsp?
I can't answer because I can't guess what you mean by determination
here.
Do
On Wed, 27 Dec 2006, Tim Blechmann wrote:
Matju wrote:
why is it that [*] is only for floats, whereas if you want to multiply two
signals one has to use [*~] ?
why do patch cords have different width?
Because Miller added that in 0.35 or 0.36 or some other release. But more
deeply: because
On Wed, 27 Dec 2006, Tim Blechmann wrote:
from the user point of view, i think, it's a good idea, to have a
specific separation between dsp and messaging, because both work with
very different concepts.
But of the difference between dsp and messaging, which ones of the very
differences of
29 matches
Mail list logo
