Re: [PD] [*] vs [*~]
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 -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 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. You are free to believe anything you want. But if you look at all the implementations of Java, C, C++, etc. you will see that they all handle strong typing, static typing, whatever the exact same way with only minor caveats here and there that are usually labeled as incompatible. .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 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? Its a design choice, its part of the language. Any implementation would have to include that in order to be compatible. .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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, 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 strongly typed mean? 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. .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 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! -- __ _ _ _ __ _ http://sintheta.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 be no difference between control and audio, because they're the exact same thing. If pd's message system was designed while thinking of any kind of hardware, it must've been MIDI hardware (nevermind undo the MIDI revolution...) while analogue circuits can transmit float-like messages by sending appropriate events (either in the data wire or as an auxiliary wire), they lack the dynamic range and the precision of the floats or even the integers. Fixing that requires a digital protocol, which is also what is required for supporting symbols. G-Pointers (at the heart of so-called Data Structures) require more than just a digital protocol, they require a common digital memory accessible by any object that is supposed to work on them. The main differences between messages and signals, is that messages have a very variable rate, an execution order, and more flexible feedback than signals. Also, the variable rate can convey meaning: there's a big difference between getting no message, and getting an empty (bang) message. Dataflow as a concept is not limited to a metaphor of electronic circuits, though lots of dataflow systems limit themselves like that. IMHO, dataflow is about outlets and inlets being connected and something (possibly anything) getting sent from outlet to inlet. [...] because we've learned to think within the dataflow paradigm. Actually you may call it the Miller paradigm instead: afaik, it's very appropriate to do so (factually speaking). If this distinction never existed, we wouldn't think twice about mixing the types, because there wouldn't be any types. Mostly agreed. 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?) Trouble comes when you try to emulate messages using signals... efficiently... and without making things much more complicated than using messages. In the end, what's important is not so much to make the system simple, it's about making the system such that it makes the problem-solving simple. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 (or a rewrite). sample-wise dsp processing is usually way slower than block-wise. iirc, i read something about a factor 2 ... t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The aim of education is the knowledge, not of facts, but of values William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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? i'm not sure, if you can use traditional dsp chains for multi-threaded systems. probably you'd be better off, if you implement some multi-threaded graph traversal, so that parallel nodes can be run on separate cores. for now, i see several problems though: - the scheduling overhead of traversing a graph in contrary to iterating over an array - i'm not sure, if current general purpose operating systems are able to allow a thread scheduling, that's fine enough, maybe a linux-rt kernel with high-resolution timers and dyntick would be required for lowest latencies ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Your mind will answer most questions if you learn to relax and wait for the answer. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
--- 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 / 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 symbols. And then why is it that [*~] can multiply a signal by a float, but [*] can't do that? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? The right inlet is generally matched to the first argument in the object box. In this context, it makes sense to have only [*~]'s right inlet violate the strict typing because you can't type signal data into the object box. .hc _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 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? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://theradioproject.com http://perhapsidid.blogspot.com (()()()(()))()()())( (())(())()((( ))(__ _())(()))___ (((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 why can't |*~ 1| do that? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? why is there no |!/~| object like in max/msp? and why is expr~ so slow? why are the inlets of |pow~| reversed? -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk I had nothing to offer anybody except my own confusion Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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
Re: [PD] [*] vs [*~]
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 with seperate objects/operators for floats vs ints or symbols vs strings, but ok for signals vs floats? why is it that [*] can't multiply a list by an integer? or is that what you mean by signal, a list of floats? And then why is it that [*~] can't multiply a float by a signal, the signal has to be on the left? Why is it that if I want to divide a float by a signal, then I have to explicitly cast the float to signal (using [sig~]) or use [expr~] ? the main reason i can think of is it's a lossy operation if the return value is a float. what value for the signal are you operating on - the value of the first sample in the DSP block? the average of all the samples in the block? the * vs *~ distinction might be useful to specify a desired return type.. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 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). ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 want polymorphism, but I don't want to push that into the question, else the question would be less questioning.) well, does polymorphism improve the expressive power in terms of determination between messaging and dsp? t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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 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. 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... 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 ... t -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The price an artist pays for doing what he wants is that he has to do it. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [*] vs [*~]
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___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
