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 it reflects the nature of the implementation of pd or of its limitations. If it wanted to make more distinctions, it could have separated the patchcord types by message types and add several kind of zigzags, stipples, colours, etc. For example, in this diagram,

http://www.videogamecritic.net/images/coleco/jumpman_junior.gif

There are short zigzag cords vs long zigzag cords, and those inform the user about what those cords are for. (The red vs green distinction is optional, so that the visual appearance of the diagram communicates the same information if a two-tone display is used.)

why is there no |!/~| object like in max/msp?

I don't know. Where's the [swap] that can support signals? ;)

and why is expr~ so slow?

I don't know, this might deserve a look (or a rewrite).

why are the inlets of |pow~| reversed?

Because it was supposed to be called [!pow~] instead?

I had nothing to offer anybody except my own confusion Jack Kerouac

I'd rather have your confusion, than the certainty that some people offer...

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

--- Tim Blechmann tim@klingt.org 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 / block-wise processing, whereas [fexpr~] does sample-wise / recursive processing. so, your explanation would apply to [fexpr~], if i am not totally wrong.

roman

___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

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 intermixed.

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 auto-convert between types, constitute wise design decisions, beyond just being things that we have to accept as fact in the context of Pd?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

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 auto-convert between types, constitute wise design decisions, beyond just being things that we have to accept as fact in the context of Pd?

Its a design choice, its part of the language.

This is not an answer to any of the above questions, Unless you're asserting that I should not ask such questions.

Any implementation would have to include that in order to be compatible.

And that's false, unless you include as a requirement that programs that fail to run with pd should also fail with any replacement of pd (which is usually not something considered a requirement).

Removing type constraints doesn't break compatibility, It's not like removing all type information, which would break the parts of programs that make decisions based on type information.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

Le Samedi 30 Décembre 2006 23:27, Mathieu Bouchard a écrit :

But how does the type of those cords represent anything else than limitations of the implementation?

Why should all the limitations of the implementation be hidden ?

Be it under the guise of unexplainable behavior or inefficient patches, the Law of Leaky Abstractions will bite those who venture too far along the road of "We have to hide this because the user really don't want to know."

How does the choice of considering those things as distinct types, and the choice to not auto-convert between types, constitute wise design decisions, beyond just being things that we have to accept as fact in the context of Pd?

Would

[bang( | [dac]

produce any sound if pd was automagically converting types ?

On Wed, 3 Jan 2007, Cyrille.Damez@laposte.net wrote:

Le Samedi 30 Décembre 2006 23:27, Mathieu Bouchard a écrit :

...

But how does the type of those cords represent anything else than limitations of the implementation?

Why should all the limitations of the implementation be hidden ?

If each limitation, individually, is worth hiding. Each limitation that is visible is worthy of a separate question.

In the case of the signals vs messages distinction: there isn't much of a difference between a signal cord, and a message cord that would carry a list of floats, which we'd call a "dsp block", and then there would be some kind of hidden [metro] to drive all of this. I say that there isn't much of a difference, because none of the existing patches would notice, and because the speed difference that exists between messages and signals can be (mostly) ironed out.

Be it under the guise of unexplainable behavior or inefficient patches, the Law of Leaky Abstractions will bite those who venture too far along the road of "We have to hide this because the user really don't want to know."

Yes, yes, but how far is too far? and why?

Abstraction (implementation) leakage hasn't so much stopped anyone from using abstractions, does it? And I don't see how my proposal is any more outrageously sweep-under-the-carpet than what pd already is.

Would [bang( -> [dac] produce any sound if pd was automagically converting types ?

most likely nothing: if a signal-inlet isn't already defining bang for a specific purpose, it will default to doing the same as an empty list, which would be treated as a block of size 0.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

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 user with seperate objects/operators for floats vs ints or symbols vs strings, but ok for signals vs floats?

Well, signals have also that special mojo that makes their execution order fly high above the mortal mofos like floats and stuff... that would be a reason to keep them different.

why is it that [*] can't multiply a list by an integer?

[*], like many arithmetic classes, interpret a 2-element list as if it were:

[unpack] | | [* ]

there's a lot of implicit [unpack] all over pd. If lists are to be supported in [*], we need to have them implemented differently... have another kind of list, a list-atom (A_LIST), but then, because it means a new way of interacting with atoms (unlike strings that can be handled just like symbols), it has to be given a new selector. This can't be 'list' because it's a conflict with an existing name that has different expectations (the existing 'list' is closer to 'anything'; the new selector goes with a single A_LIST element instead of having the message be the collection).

or is that what you mean by signal, a list of floats?

It could be, but there are three major distinctions:

1. that list is float-only, stored as t_float[] instead of t_atom[].
2. that list would be A_LIST so that it doesn't get caught in [unpack].
3. that list has the mojo.

...

And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left?

the main reason i can think of is it's a lossy operation if the return value is a float.

The assumption that you are making is interesting: you assume that in this case the output would/could be a float, according to some unspecified rule which appears to be that the output type follows the type of the left input.

In MAX (and jMax), float vs int is decided by the right input, not the left one.

In GridFlow's [#], output size is determined by left input, which is sort of suggesting that output type should also be determined by left input (although this feature has not been implemented there).

In Pd, the mode of [*~] (and such) is determined by right input. Actually, I should stress that this is determined by right argument, which then forces a specific right inlet type. I don't remember whether MAX/jMax's float-vs-int input type can be changed at runtime, but for atom-vs-signal I think I recall that they do it like Pd.

what value for the signal are you operating on - the value of the first sample in the DSP block?

In the logic of [#], it would be the first sample, because [#] causes an implicit [#redim] on its right input.

the average of all the samples in the block?

That wouldn't be so often useful for sound, would it? In any case, it's the same difference as between those two:

[#downscale_by 64] [#downscale_by 64 smoothly]

the * vs *~ distinction might be useful to specify a desired return type..

... but that's only one way to specify a rule. doing it by the type of the right input (inlet and/or argument) is another way.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

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 want polymorphism, but I don't want to push that into the question, else the question would be less questioning.)

(In PureUnity I have to do strange hacks so that a box can be [+] or [+~] depending on the context, because I can't be satisfied just doing copy+paste and adding/deleting the ~ sign wherever needed: it's ugly to have to do that).

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On Wed, 27 Dec 2006, Charles Henry wrote:

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)

Yes, it's an easy way to get such efficiency, and for example, this is what happens in very-typed (expression-typed) languages like C++ and Ocaml and Haskell (and maybe Java 1.5 but not Java 1.4 nor C nor ObjectiveC). This is good because it means that those things can run very fast without requiring a runtime compiler, so, the compiler can be kept separate from the program being compiled. (In Ocaml and Haskell though, types are implicit AND already known before the program starts.)

In Pd, the only compilation going on is dsp_add(), and it's done at runtime already (during editing). So, the compiler is never in a different process (task) than the DSP. The only advantage remaining is predictibility of execution time, but only if it's assumed that the more implicit system (the more "runtime" one) doesn't have strict rules that allows one to know the type of an object's output. This might be a strawman, if we don't take the time to figure out whether any such strict rules can be defined: either implicit expression-typed, or a more runtime-oriented system in which the runtime compiler is taken into account when computing realtime constraints.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

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 object and what's not, in terms of figuring out what's in the DSP chain?

Why do we need a DSP chain? Why do those tilde have the mojo dsp_chain() stuff while the message mofos don't deserve such a cache-locality?

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?)

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

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 the very different concepts need to be emphasized, and which ones need to be downplayed? Just because there are differences, doesn't mean they need to be outlined in bold or tilde.

...

Why do we need a DSP chain? Why do those tilde have the mojo dsp_chain() stuff while the message mofos don't deserve such a cache-locality?

well, computing audio signals is usually way more expensive then computing messaging. for my personal performance patch, the messaging is usually less than 2% of the cpu usage...

Ok, but messaging tends to happen in bursts. In a single-thread system, this has to happen between the processing of two blocks. If a [metro] gets only triggered every 100 blocks, that's 200% of CPU usage which ends up delaying the next block, so latency has to be increased in order to remove jitter.

...

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 what if there was one dsp_chain per thread, and that when the dsp_add() phase happens, it adds to one of several dsp_chains depending on some kind of load-balancing metric?

The price an artist pays for doing what he wants is that he has to do it. -- William S. Burroughs

Damn right.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On 27/12/06, Tim Blechmann tim@klingt.org 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 messaging, because both work with very different concepts.

Maybe I shouldn't be jumping into this discussion so late, with little programming knowledge, but…

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 be no difference between "control" and "audio," because they're the exact same thing.

We might think that separating control and audio makes perfect sense from a user standpoint---I even think so. But I'm pretty sure that we only think that way because we've learned to think within the dataflow paradigm. If this distinction never existed, we wouldn't think twice about mixing the types, because there wouldn't be any types.

I remember learning the difference between floats and ints. From a user's standpoint, why bother? I remember resigning myself to "well that's annoying, but I guess it's necessary." Why does Pd not distinguish, but Max does?

As far as I understand, the difference between control and audio data exists purely for computational efficiency, and has no real conceptual basis. (Maybe I'm asking for a beatdown with that statement…)

D!

On Dec 30, 2006, at 10:41 PM, David NG McCallum wrote:

On 27/12/06, Tim Blechmann tim@klingt.org 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 messaging, because both work with very different concepts.

Maybe I shouldn't be jumping into this discussion so late, with little programming knowledge, but…

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 be no difference between "control" and "audio," because they're the exact same thing.

We might think that separating control and audio makes perfect sense from a user standpoint---I even think so. But I'm pretty sure that we only think that way because we've learned to think within the dataflow paradigm. If this distinction never existed, we wouldn't think twice about mixing the types, because there wouldn't be any types.

I remember learning the difference between floats and ints. From a user's standpoint, why bother? I remember resigning myself to "well that's annoying, but I guess it's necessary." Why does Pd not distinguish, but Max does?

As far as I understand, the difference between control and audio data exists purely for computational efficiency, and has no real conceptual basis. (Maybe I'm asking for a beatdown with that statement…)

Yes, a lot of this kind of stuff is done for efficiency's sake, like
messages vs. audio rate data. Its hard to get around that. But the
strong types of symbol vs. float are an human-computer interface
question.

.hc

D!

-- __ _ _ _ __ _ http://sintheta.org

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore

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, and solve the rate-efficiency issue by allowing a mix of
a wide range of threads of varying execution rate (chuck calls them
Shreds) in synch in the same subpatch...

Since there is often talk of threading on here, I want to clarify
ChucK's "shreds" a bit. ChucK does not use threads like pthreads, or
Mac OS X/Windows threads. Its shreds are more like Windows 3.1
threads, i.e. cooperative or "non-preemptive" as they put it.
Basically, its structured quite similarly to Pd, Csound, etc., except
that the scheduler is more flexible and exposed. Plus, you have to
handle a lot of the scheduling.

.hc

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore

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.

___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

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 harassing/boring too.

What about this?

[bang( | [list append pd-$0-happy-new-year and all the best for 2007!] | [print]

Ciao

This is pretty elegant! Thanks.

[r <number of pd-list users>] | [until] | [t a b] | | | [i 0][+1] | | | [s $0demux] [list append pd-$0-happy-new-year 2007] | [r $0demux] | | [demultiplex] | ..............| [s user1] [s usern]

Cheers. Pc.

___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

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 "strongly typed" mean?

Have you read what I wrote to you, about "strongly typed" being vague wording?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

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 The bullet points in particular.

No, not the bullet points, I mean like the part at the end that says:

« For this reason, writers who wish to write unambiguously about type systems often eschew the term "strong typing" in favor of specific expressions such as "static typing" or "type safety". »

However, after dealing with types that long, I've come to believe that "static typing" is vague too.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada