Re: [PD] cyclone into vanilla
if someone built abstractions with the same name, is it likely that they have different behaviour? Some of the signal objects would have to have a different behavior because of how [inlet~] works. If [inlet~] could take an optional float arg to output a constant sig (tough because it takes symbol args as well, but not impossible), then you could have abstractions which could take creation arguments *or* signals in all inlets in one abstraction implementation. Otherwise [inlet~] promotes float messages already, but it's very buggy in canvases that have an [inlet] to the left of [inlet~](s). With the current tools it's hard to implement some of them efficiently, too. Other problems with abstractions would be something like gate -- you need [initbang] for that one, which is not in vanilla (it's otherwise very easy to make an abstraction out of) -- or [spigot] could become a multi-outlet object whose only difference from [gate] is the (proper, IMO) right inlet controls Pd style -- this is one of the proper behavior problems that has come up recently; [pow~] was another, if my memory isn't shot. One slightly different tack would be instead of trying to bring cyclone (etc.) into vanilla, to just ensure the existence of standalone control and signal objects for all the functions and operators in the expr suite -- that would be a decent start. It would at least satisfy those who want a more complete set of mathematical tools without needing to use expr; it seems that's where most of the complaints have come of late. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cyclone into vanilla
Matt Barber wrote: [inlet~] promotes float messages already, but it's very buggy in canvases that have an [inlet] to the left of [inlet~](s). err.. very buggy? why? no, scratch that, actually; i don't want to know. i'm sure it will lead to wtf's. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cyclone into vanilla
Try moving the [inlet] and the [outlet] around in different combinations in the attached abstraction [weirdinlet] -- I included a test patch as well. See if you get freakish bugs when trying to set the [inlet~]s with floats. Matt On Fri, Jul 18, 2008 at 3:32 PM, Damian Stewart [EMAIL PROTECTED] wrote: Matt Barber wrote: [inlet~] promotes float messages already, but it's very buggy in canvases that have an [inlet] to the left of [inlet~](s). err.. very buggy? why? no, scratch that, actually; i don't want to know. i'm sure it will lead to wtf's. weirdinlet.pd Description: Binary data weirdinlettest.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cyclone into vanilla
Strange, Must not have saved the [outlet] in the abstraction originally. Sorry about that -- new ones attached. M On Fri, Jul 18, 2008 at 3:46 PM, Matt Barber [EMAIL PROTECTED] wrote: Try moving the [inlet] and the [outlet] around in different combinations in the attached abstraction [weirdinlet] -- I included a test patch as well. See if you get freakish bugs when trying to set the [inlet~]s with floats. Matt On Fri, Jul 18, 2008 at 3:32 PM, Damian Stewart [EMAIL PROTECTED] wrote: Matt Barber wrote: [inlet~] promotes float messages already, but it's very buggy in canvases that have an [inlet] to the left of [inlet~](s). err.. very buggy? why? no, scratch that, actually; i don't want to know. i'm sure it will lead to wtf's. weirdinlet.pd Description: Binary data weirdinlettest.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, marius schebella hat gesagt: // marius schebella wrote: honestly, I think not many people used it... I ran grep -R pow~ * in my pd-directories and found only two patches (of 1+) besides the helppatch for pow~, that use it. nusmuk for distortion.pd, tb for sigmoid_booster~.pd I don't know other big collections like net-pd (I think I just checked pdmtl). and maybe official tutorial patches floating around. anyway, I can only speak for myself, and I would like to see pow~ with a new behaviour. This would break or make necessary an update to Cyclone's Max importer: Cyclone's goal always was to make Pd a bit mor Max compatible, and many Max patches use pow~. Ciao -- Frank ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Enrique Erne wrote: or [biquad~ 0 0 0 1] Miller Puckette wrote: I believe z~ is just rzero~ 0. no. both of them are equivalent to [z~ 1] you could also argue that [f] is just the same as [0( :-) fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Tue, 2008-04-22 at 17:23 +0200, Thomas Grill wrote: Me for one, i have really missed pow~ or abs~ but i have been missing many other things. I don't see the necessity for the objects you mentioned when they can be built as abstractions using expr~ within seconds. But isn't expr~ an external? I don't see using expr~ as a 'vanilla pd' solution to this problem. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
frank, you are right that the importer would probably use pd's internal pow~, but from my own experience I can only say max and pd are becoming less and less compatible, I ported a lot of patches and also big patches, I always did this by hand, because there are too many things that can go wrong. with max 5 I am not sure, if it is still possible to export the patches text files at all? but there are mor tricky differences, and I don't think cyclone did take care of them (see below), so why hold up the flag for a feature that is not really used by anyone and does not work reliably anyway. (although I agree with you and think it would still be a good idea to rewrite this part of the importer) other max/puredata differences in max messages save their last values, so you can retrigger them by a bang, in pd not. trigger behaves different with number arguments. in max the number will be consistent, in pd it is a placeholder for float(and gets replaced by another number). in max there is this right to left order of execution for objects that are connected without trigger that does not exist in pd. some other things rather apply when you try to expor pd patches. unpack does not work for symbols in max. pd has no integers. a [+] in pd will work for floats and integers, but when you port it to max, it will default to integers. (the same with a lot of other objects, like line...) select does not output a list on its right outlet in max. all the best, marius. Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: honestly, I think not many people used it... I ran grep -R pow~ * in my pd-directories and found only two patches (of 1+) besides the helppatch for pow~, that use it. nusmuk for distortion.pd, tb for sigmoid_booster~.pd I don't know other big collections like net-pd (I think I just checked pdmtl). and maybe official tutorial patches floating around. anyway, I can only speak for myself, and I would like to see pow~ with a new behaviour. This would break or make necessary an update to Cyclone's Max importer: Cyclone's goal always was to make Pd a bit mor Max compatible, and many Max patches use pow~. Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
I don't really think PD-Max compatibility should factor much into decisions about improving PD, especially when it would force 'untidy' concessions on the part of PD to facilitate awkward max paradigms (like right to left execution order, etc.). If [1]**[2] (where [1] and [2] are inlets) seems the cleanest and most consistent syntax, then it should certainly be used; and bite our thumbs at Max. I believe the PD is better than Max; this is certainly true in one important sense: if you write a PD patch, you can give it to anyone with a reasonably modern computer; they will be able to download PD on their machine/OS and execute with full rights and privileges. The same cannot be said of Max. Onward and Upward! JP On Apr 25, 2008, at 9:33 AM, marius schebella wrote: frank, you are right that the importer would probably use pd's internal pow~, but from my own experience I can only say max and pd are becoming less and less compatible, I ported a lot of patches and also big patches, I always did this by hand, because there are too many things that can go wrong. with max 5 I am not sure, if it is still possible to export the patches text files at all? but there are mor tricky differences, and I don't think cyclone did take care of them (see below), so why hold up the flag for a feature that is not really used by anyone and does not work reliably anyway. (although I agree with you and think it would still be a good idea to rewrite this part of the importer) other max/puredata differences in max messages save their last values, so you can retrigger them by a bang, in pd not. trigger behaves different with number arguments. in max the number will be consistent, in pd it is a placeholder for float(and gets replaced by another number). in max there is this right to left order of execution for objects that are connected without trigger that does not exist in pd. some other things rather apply when you try to expor pd patches. unpack does not work for symbols in max. pd has no integers. a [+] in pd will work for floats and integers, but when you port it to max, it will default to integers. (the same with a lot of other objects, like line...) select does not output a list on its right outlet in max. all the best, marius. Frank Barknecht wrote: Hallo, marius schebella hat gesagt: // marius schebella wrote: honestly, I think not many people used it... I ran grep -R pow~ * in my pd-directories and found only two patches (of 1+) besides the helppatch for pow~, that use it. nusmuk for distortion.pd, tb for sigmoid_booster~.pd I don't know other big collections like net-pd (I think I just checked pdmtl). and maybe official tutorial patches floating around. anyway, I can only speak for myself, and I would like to see pow~ with a new behaviour. This would break or make necessary an update to Cyclone's Max importer: Cyclone's goal always was to make Pd a bit mor Max compatible, and many Max patches use pow~. Ciao ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
just asking, but does ANYONE actually import max patches into pd? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
hard off wrote: just asking, but does ANYONE actually import max patches into pd? people want to do that all the time, so if we had a conversion system, then I guess people would use it. (right now it does not work well enough to be usable). but the same goes for pd to java, pd to C++. and it does not only apply to sound, but also to graphics. people would take their gem patches and port them to any webbrowser readable format (processing, even flash) if this would be possible. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, another point to take into account are arguments: What should pow 2 output? Ciao -- Frank Julian Peterson hat gesagt: // Julian Peterson wrote: I don't really think PD-Max compatibility should factor much into decisions about improving PD, especially when it would force 'untidy' concessions on the part of PD to facilitate awkward max paradigms (like right to left execution order, etc.). If [1]**[2] (where [1] and [2] are inlets) seems the cleanest and most consistent syntax, then it should certainly be used; and bite our thumbs at Max. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, hard off hat gesagt: // hard off wrote: just asking, but does ANYONE actually import max patches into pd? The whole RTC-lib was (im)ported with Cyclone. Ciao -- Frank ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Fri, 25 Apr 2008 09:52:43 -0400 Julian Peterson [EMAIL PROTECTED] wrote: if you write a PD patch, you can give it to anyone with a reasonably modern computer; they will be able to download PD on their machine/OS and execute with full rights and privileges. For the last 2 years I have very much kept democratisation of tools and universal access in the front of my mind. The entry barrier to any career should always be hard work and learning and not access to an elite club of expensive tools. The computing/IT economy has blossomed because our generation had access to C compilers and cheap hardware as we grew up. I hope the next generation of sound designers will enjoy the same opportunity of commodity tools. At one time I seriously considered using Max because of the readership potential and it was better known within sound design circles. Perhaps my efforts in this area are starting to pay off because I think that has changed. Several job specifications I've seen lately from games developers venturing into procedural audio have mentoned Pd, not Max. Another thing I've tried to do with the book is keep all examples working within 800MHz CPU requirements. That said, beyond using Pd as the teaching vehicle I tried to keep an implementation agnostic approach, with the idea that if you understand the algorithm and model you can implement a sound object in Pd, Max, CPS or any in-house proprietry synthesis framework. Being able to translate synthesis models between Csound, Pd, Max or whatever is a skill that comes with time. Automatic translation or import scripts are useful for sure, but I think we should recognise that they have now diverged into different things. Since I still believe Pd is the superior design application (by miles) a far more useful automated path would be to spit out Faust symbolic DSP algebra from Pd patches so you could compile patches into externals, Max objects, VST plugins or stand-alone applications. a. -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Fri, 25 Apr 2008 16:39:04 +0200 Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, another point to take into account are arguments: What should pow 2 output? Well, presuming we do keep compatability [pow~ 2] will continue to behave as it does in Cyclone. For the proposed intrinsic [**~ ] operator then [**~ 2] would place the argument in the exponent position according to established Pd convention, so [**~ 2] would be the same as squaring. It would replace /\ [*~] though I expect most of us will continue to use that form. For altering the base then one would say [sig~ 3] | [**~ ] which weems in keeping with other uses. Ciao -- Frank Julian Peterson hat gesagt: // Julian Peterson wrote: I don't really think PD-Max compatibility should factor much into decisions about improving PD, especially when it would force 'untidy' concessions on the part of PD to facilitate awkward max paradigms (like right to left execution order, etc.). If [1]**[2] (where [1] and [2] are inlets) seems the cleanest and most consistent syntax, then it should certainly be used; and bite our thumbs at Max. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
OMG, is it really true that pow and pow~ are reversed from each other in Max (and hence cyclone)!? That's genuinely strange - and if it's true, I'd definitely make pow~ act as the present pow (left inlet raiesed to right inlet as a power) and just print out a warning for a year or two. cheers M On Fri, Apr 25, 2008 at 10:57:59AM -0400, marius schebella wrote: Frank Barknecht wrote: Hallo, another point to take into account are arguments: What should pow 2 output? do you mean [pow 2] or [pow~ 2]? because pow 2 already outputs the square, I think pow~ should behave the same, also output the square (x^2) and not 2^x. like [+ 2] outputs x+2, *2 outputs x*2. no? marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Miller Puckette wrote: OMG, is it really true that pow and pow~ are reversed from each other in Max (and hence cyclone)!? That's genuinely strange - and if it's true, I'd definitely make pow~ act as the present pow (left inlet raiesed to right inlet as a power) and just print out a warning for a year or two. in max (4.6) you get [6\ | [pow 2] | [36\ and [sig~ 6] | [pow~ 2] | [snapshot~] | [64\ marius. cheers M On Fri, Apr 25, 2008 at 10:57:59AM -0400, marius schebella wrote: Frank Barknecht wrote: Hallo, another point to take into account are arguments: What should pow 2 output? do you mean [pow 2] or [pow~ 2]? because pow 2 already outputs the square, I think pow~ should behave the same, also output the square (x^2) and not 2^x. like [+ 2] outputs x+2, *2 outputs x*2. no? marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On 25/04/2008, at 17.06, Miller Puckette wrote: OMG, is it really true that pow and pow~ are reversed from each other in Max (and hence cyclone)!? no (the assumption in the above is not true). according to the reference manuals downloadable from C74's website [0], pow and pow~ are consistent with each other. Ie. left inlet sets the exponent and the right inlet and the argument sets the base. [0] http://www.cycling74.com/download/maxmsp463doc.zip ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On 25/04/2008, at 17.37, marius schebella wrote: in max (4.6) you get [6\ | [pow 2] | [36\ That is odd. It matches the example in their reference manuals but not the text unless base and exponent momentarily means something else while reading that text. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Steffen Juul wrote: On 25/04/2008, at 17.37, marius schebella wrote: in max (4.6) you get [6\ | [pow 2] | [36\ That is odd. It matches the example in their reference manuals but not the text unless base and exponent momentarily means something else while reading that text. their manual is wrong! cite: pow raises the base value (set in the right inlet) to the power of the exponent (set in the left inlet). Input: float or int In left inlet: Sets the exponent. In right inlet: Sets the base value. Arguments: float or int, Optional. Sets the base value. The default value is 0. Output: float The base value (from the right inlet) raised to the exponent (from the left inlet). and then they have an example as it really works [2( [-0.5( | / [pow] | [0.707107\ but -0.5**2 is actually 0.25. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: OMG, is it really true that pow and pow~ are reversed from each other in Max (and hence cyclone)!? Not in Max, but in Cyclone, which uses the [pow] from Pd, which is reverse from the [pow] in Max. According to the Max 4.6 manual both pow~ and pow in Max have base right, exponent left, and the argument sets the base. [pow] in Pd has base left and exponent right, argument sets the exponent (i.e. the message at the right inlet). In the C-math-library, pow is: pow(x=base, y=exponent). I guess, I'm convinced now that [pow~] in Pd should behave like Pd's [pow] and the hell with Max-compatibility. However for Andy this probably means even more work now ... I think, Cyclone's [pow~] should be renamed to something like [rpow~] then. IIRC Cyclone can be made to do some translations when importing Max-patches like for [Snapshot~], a translation pow~ to rpow~ then maybe could be added. I don't think, a warning message in Pd would be necessary, it may be annoying. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Steffen Juul wrote: On 25/04/2008, at 17.37, marius schebella wrote: in max (4.6) you get [6\ | [pow 2] | [36\ That is odd. It matches the example in their reference manuals but not the text unless base and exponent momentarily means something else while reading that text. btw, http://www.cycling74.com/docs/max5/refpages/max-ref/pow.html marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Fri, 2008-04-25 at 11:37 -0400, marius schebella wrote: in max (4.6) you get [sig~ 6] | [pow~ 2] | [snapshot~] | [64\ Same with cyclone/pow~ Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
I think the one-sample delay is given by [rzero_rev~ 0] -- (y[n] = -a[n] * x[n] + x[n-1]) -- but [z~] takes an argument for any delay by sample. Also, using a filter to achieve the delay might be putting the cart before the horse in pedagogical situations -- here [fexpr~] is probably better, but its maximum delay is the current vector length, and to me it feels somewhat expensive in production situations. Another option for something like [z~] that might integrate better with delay representation in pd could be an object that simply reads from [delwrite~] like [delread~] and [vd~], but whose argument is a sample-wise delay -- however, this is easily done via an abstraction. This would obviate the need for each instance to have its own internal delay allocation which could be useful for someone who wanted to use it to build something like a several-hundred-point direct convolution patch. Still, if others are used to the [z~] in zexy, it might be better to go with that model if it's going to be implemented in vanilla. Thanks, Matt Date: Wed, 23 Apr 2008 13:17:40 -0700 From: Miller Puckette [EMAIL PROTECTED] Subject: Re: [PD] Cyclone in vanilla? To: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii I believe z~ is just rzero~ 0. cheers Miller On Wed, Apr 23, 2008 at 11:24:34AM +0200, Frank Barknecht wrote: Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...). You don't need to set the block~-size to 1, and personally I would just make the delwrite~ big enough. It's cheap to store things in a delay. But anyway, attached is a z~-clone with delwrite~/delread~ that uses a helper abstraction created dynamically. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
or [biquad~ 0 0 0 1] eni Miller Puckette wrote: I believe z~ is just rzero~ 0. cheers Miller On Wed, Apr 23, 2008 at 11:24:34AM +0200, Frank Barknecht wrote: Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...). You don't need to set the block~-size to 1, and personally I would just make the delwrite~ big enough. It's cheap to store things in a delay. But anyway, attached is a z~-clone with delwrite~/delread~ that uses a helper abstraction created dynamically. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: It seems the cleanest solution would be to just include the objects that Andy has pointed out. Otherwise, I think adding the whole of cyclone will be opening up a big can of worms. Cyclone has a lot of redundant Max-leftovers in it and some of its classes already have cleaner solutions in Pd itself (e.g. [list] is better designed than [zl] because of the automatic conversion to list-messages etc.) And [z~] is not part of Cyclone, but it's redundant anyway. The Capitalized Objects like Append or Snapshot~ may be a problem as well (their help-files may clash on Windows). So I would vote for including only a selected number of the Cyclone objects and leave the rest as externals. Clashes with cxc as Marius mentioned wouldn't bother me at all, cxc is not a very useful or big library anyways - IMO it should be deprecated and removed from pd-condensed. ;) Ciao -- Frank Barknecht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Am 24.04.2008 um 06:21 schrieb marius schebella: record conflicts (?) with record from xsample Why should it? the name o the object is xrecord~ gr~~~ smime.p7s Description: S/MIME cryptographic signature ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hans-Christoph Steiner wrote: It seems the cleanest solution would be to just include the objects that Andy has pointed out. Otherwise, I think adding the whole of cyclone will be opening up a big can of worms. mmh!! worms! the U.N. food and agriculture organization estimates 1,400 species of insects and worms are eaten in almost 90 countries in africa, latin america and asia. among the most popular are silk and bamboo worms. I would be glad to see some of these new cyclone worms on my plate... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Thu, 24 Apr 2008 08:01:26 -0400 marius schebella [EMAIL PROTECTED] wrote: I've always wanted to try chocolate ants, but you can't get them round here, not even in Southall. http://www.lazyboneuk.com/store/pro501.html Hans-Christoph Steiner wrote: It seems the cleanest solution would be to just include the objects that Andy has pointed out. Otherwise, I think adding the whole of cyclone will be opening up a big can of worms. mmh!! worms! the U.N. food and agriculture organization estimates 1,400 species of insects and worms are eaten in almost 90 countries in africa, latin america and asia. among the most popular are silk and bamboo worms. I would be glad to see some of these new cyclone worms on my plate... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
DIY! You can make your own chocolate ants! .hc On Apr 24, 2008, at 9:51 AM, Andy Farnell wrote: On Thu, 24 Apr 2008 08:01:26 -0400 marius schebella [EMAIL PROTECTED] wrote: I've always wanted to try chocolate ants, but you can't get them round here, not even in Southall. http://www.lazyboneuk.com/store/pro501.html Hans-Christoph Steiner wrote: It seems the cleanest solution would be to just include the objects that Andy has pointed out. Otherwise, I think adding the whole of cyclone will be opening up a big can of worms. mmh!! worms! the U.N. food and agriculture organization estimates 1,400 species of insects and worms are eaten in almost 90 countries in africa, latin america and asia. among the most popular are silk and bamboo worms. I would be glad to see some of these new cyclone worms on my plate... marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list 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] Cyclone in vanilla?
btw, are all pow~ objects reversed? right inlet^left inlet? marius. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Yep. What is to be done about that? Should we keep to the conventions of vanilla and Pd generally by changing that? I am torn on this. I would have a lot of rewriting to do but would like to see conventions observed. OTOH, maybe compatibility with patches out there using Cyclone [pow~] should be respected as a priority. BTW it's very important for to know. If it changes after I publish the book I will hire a bounty hunter to bring me the fingers of whoever made the changes :) On Thu, 24 Apr 2008 11:39:07 -0400 marius schebella [EMAIL PROTECTED] wrote: btw, are all pow~ objects reversed? right inlet^left inlet? marius. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
This is a serious problem -- putting a backwards pow~ into Pd might be worse than having none at all. But writing a book that uses pow backwards would be even worse than having one in Pd! Maybe the right thing would be to use another name such as power~. On Thu, Apr 24, 2008 at 05:16:08PM +0100, Andy Farnell wrote: Yep. What is to be done about that? Should we keep to the conventions of vanilla and Pd generally by changing that? I am torn on this. I would have a lot of rewriting to do but would like to see conventions observed. OTOH, maybe compatibility with patches out there using Cyclone [pow~] should be respected as a priority. BTW it's very important for to know. If it changes after I publish the book I will hire a bounty hunter to bring me the fingers of whoever made the changes :) On Thu, 24 Apr 2008 11:39:07 -0400 marius schebella [EMAIL PROTECTED] wrote: btw, are all pow~ objects reversed? right inlet^left inlet? marius. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Thu, 24 Apr 2008 09:38:07 -0700 Miller Puckette [EMAIL PROTECTED] wrote: This is a serious problem -- putting a backwards pow~ into Pd might be worse than having none at all. But writing a book that uses pow backwards would be even worse than having one in Pd! Agreed. This is a difficult choice. Since it would be in core how about ^ or ** I need a day to think about this and ideas are very welcome. Remember compactness is an issue in the patch diagrams as they are typeset to tight constraints. BTW it's very important for to know. If it changes after I publish the book I will hire a bounty hunter to bring me the fingers of whoever made the changes :) Hmm, the dark side reveals fears unworthy of a Jedi. Perhaps the fear is for the sanity of students, or of those who will email me every day saying why doesn't this patch work? :) My instinct says that clarity and consistency are paramount and if I need to rewrite those parts so be it. We all still have the choice now, so let's make the decision the right one. On Thu, 24 Apr 2008 11:39:07 -0400 marius schebella [EMAIL PROTECTED] wrote: btw, are all pow~ objects reversed? right inlet^left inlet? marius. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Andy Farnell wrote: On Thu, 24 Apr 2008 09:38:07 -0700 Miller Puckette [EMAIL PROTECTED] wrote: This is a serious problem -- putting a backwards pow~ into Pd might be worse than having none at all. But writing a book that uses pow backwards would be even worse than having one in Pd! Agreed. This is a difficult choice. Since it would be in core how about ^ or ** ^ is usually bitwise XOR (in C, and Pd's expr). ** is used for powers in a number of languages (Haskell, Fortran too I think). But, there is the potential confusion of [pow][pow~][**][**~], it would be nice if the signal version of maths behaved the same as the non-signal maths with the same name (confusing if [pow] exists but the signal equivalent is [**~]). Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Thu, 24 Apr 2008 18:17:29 +0100 Claude Heiland-Allen [EMAIL PROTECTED] wrote: Since it would be in core how about ^ or ** ^ is usually bitwise XOR (in C, and Pd's expr). I think the presence in [expr~] is enough to exclude that option. ** is used for powers in a number of languages (Haskell, Fortran too I think). It's a strong choice notwithstanding: But, there is the potential confusion of [pow][pow~][**][**~], it would be nice if the signal version of maths behaved the same as the non-signal maths with the same name (confusing if [pow] exists but the signal equivalent is [**~]). This would mean breaking backwards with Cyclone. It would also be a nasty break because patches would simply fail to compute correctly rather than throwing any kind of detectable error. However, for my vote I am ready to take this step. Cyclones ordering really seems to be in error. x^y seems natural to put the exponent in the second argument. -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Miller Puckette wrote: This is a serious problem -- putting a backwards pow~ into Pd might be worse than having none at all. But writing a book that uses pow backwards would be even worse than having one in Pd! Maybe the right thing would be to use another name such as power~. then the max way is the wrong way? maybe there was a reason to put it the other side around? pow~ will be in an elitist club together with atan and gate, and maybe counter, which are the real troublemakes regarding backwards compatibility and shareability. maybe the new pow~ can spit out a compatibility warning during the first few months? but if we agree that pow~ 2 should be left inlet ^ 2 and not 2 ^ left inlet, then it should be changed. because there is also good chance to use pow~ as expected and then having to debug a patch (which happened to me before I found out that it works the cyclone way)... marius. On Thu, Apr 24, 2008 at 05:16:08PM +0100, Andy Farnell wrote: Yep. What is to be done about that? Should we keep to the conventions of vanilla and Pd generally by changing that? I am torn on this. I would have a lot of rewriting to do but would like to see conventions observed. OTOH, maybe compatibility with patches out there using Cyclone [pow~] should be respected as a priority. BTW it's very important for to know. If it changes after I publish the book I will hire a bounty hunter to bring me the fingers of whoever made the changes :) On Thu, 24 Apr 2008 11:39:07 -0400 marius schebella [EMAIL PROTECTED] wrote: btw, are all pow~ objects reversed? right inlet^left inlet? marius. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Andy Farnell wrote: x^y seems natural to put the exponent in the second argument. I would not go so far to call it natural, but maybe conventional. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Andy Farnell wrote: This would mean breaking backwards with Cyclone. well, we still could keep cyclone/pow~. ... pd still has the 0 in the version number. break because patches would simply fail to compute correctly rather than throwing any kind of detectable error. they could throw a warning. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On 24/04/2008, at 19.17, Claude Heiland-Allen wrote: But, there is the potential confusion of [pow][pow~][**][**~], it would be nice if the signal version of maths behaved the same as the non-signal maths with the same name (confusing if [pow] exists but the signal equivalent is [**~]). Right. I think odd naming like **~, power~ and the like cause more harm then if the inlets are swapped, since they are harder to recall or guess for both current and new users. And to be frank, does it really matter if it's one way or the other? I mean, they are both hot. So it only a matter of what one would think is natural or the convention or how you'd normally use such function. I'm very sure i have a TI calculator floating somewhere where it is the cyclone/max way. So there is no right thing only preferences, and no trigger-particle issues, hence in that respect i can not see how it contradicts with current Pd tilde-class behavior. just my opinion. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Yes, a backwards clash is horrible Marius, and I want to avoid that too. The question would be over a new name I guess. There's plenty of room in the name space to avoid clashing if we do reverse [pow~] [pwr~] for eample (anyone building a pressurised water reactor?...) It may seem weird to fuss over a few characters but I would choose [**~] or [pwr~] over [power~] simply for that tiny bit of diagram space. a. On Thu, 24 Apr 2008 13:59:08 -0400 marius schebella [EMAIL PROTECTED] wrote: counter, which are the real troublemakes regarding backwards compatibility and shareability. marius. -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Thu, 24 Apr 2008 20:30:44 +0200
Steffen Juul [EMAIL PROTECTED] wrote:
And to be frank, does it really matter if it's one way or the other?
I think it does. No doubt there are exeptions that go against this, but
it seems well established that all Pd objects order arguments like
standard western math operators. For commutative operators it's not
a big deal obviously, but when making sense of [-~] or [/~] then
[**~] (I'm going to optimistically start calling it that :) would
catch out a lot of people (as [pow~] did for me) by breaking the
convention that x {operator} y has a Pd object with x on the left
and y on the right.
--
Use the source
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote: Yes, a backwards clash is horrible Marius, and I want to avoid that too. The question would be over a new name I guess. What about the [list OP] approach for signal math, as I implemented with my [math~ OP] abstraction? This would also make a radians-accepting [math~ cos] possible. [math~] should of course follow the C-library conventions. Ciao -- Frank ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
honestly, I think not many people used it... I ran grep -R pow~ * in my pd-directories and found only two patches (of 1+) besides the helppatch for pow~, that use it. nusmuk for distortion.pd, tb for sigmoid_booster~.pd I don't know other big collections like net-pd (I think I just checked pdmtl). and maybe official tutorial patches floating around. anyway, I can only speak for myself, and I would like to see pow~ with a new behaviour. marius. Andy Farnell wrote: Yes, a backwards clash is horrible Marius, and I want to avoid that too. The question would be over a new name I guess. There's plenty of room in the name space to avoid clashing if we do reverse [pow~] [pwr~] for eample (anyone building a pressurised water reactor?...) It may seem weird to fuss over a few characters but I would choose [**~] or [pwr~] over [power~] simply for that tiny bit of diagram space. a. On Thu, 24 Apr 2008 13:59:08 -0400 marius schebella [EMAIL PROTECTED] wrote: counter, which are the real troublemakes regarding backwards compatibility and shareability. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Tue, Apr 22, 2008 at 09:38:25AM +0200, Frank Barknecht wrote: Note that I also think, the math objects (abs~, pow~ etc.) should be part of Pd, and probably symbol2list. I second this. Miller, what do you think? You have mentioned importing Cyclone into Pd; is it just a matter of yourself not having had the time to do this yet? Would you rather this happened in pd-extended first, or would you accept and apply patches rectifying this and making basic math tilde internals if they didn't conflict with Cyclone externals? Sorry to be so direct! Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...). You don't need to set the block~-size to 1, and personally I would just make the delwrite~ big enough. It's cheap to store things in a delay. But anyway, attached is a z~-clone with delwrite~/delread~ that uses a helper abstraction created dynamically. Ciao -- Frank Barknecht _ __footils.org__ zelwrite~.pd Description: application/puredata zel~-help.pd Description: application/puredata zel~.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Frank, Thanks for the attachment. You're right about the block~ size; I was thinking about if you wanted to later use it in recursive delay networks, but I had forgotten that an abstraction will block~ to its parent patch (yes?). As a note, to make it compatible with earlier versions of PD, you can't embed $0 in the middle of a symbol -- to send a message to pd-$0-name you have to use [makefilename] or some such (this would currently be important for users of the vanilla subset within extended, say under planetccrma). Thanks, Matt Date: Wed, 23 Apr 2008 11:24:34 +0200 From: Frank Barknecht [EMAIL PROTECTED] Subject: Re: [PD] Cyclone in vanilla? To: pd-list@iem.at Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...). You don't need to set the block~-size to 1, and personally I would just make the delwrite~ big enough. It's cheap to store things in a delay. But anyway, attached is a z~-clone with delwrite~/delread~ that uses a helper abstraction created dynamically. Ciao -- Frank Barknecht _ __footils.org__ -- next part -- A non-text attachment was scrubbed... Name: zelwrite~.pd Type: application/puredata Size: 116 bytes Desc: not available Url : http://lists.puredata.info/pipermail/pd-list/attachments/20080423/bc1a4a5a/attachment-0003.bin -- next part -- A non-text attachment was scrubbed... Name: zel~-help.pd Type: application/puredata Size: 531 bytes Desc: not available Url : http://lists.puredata.info/pipermail/pd-list/attachments/20080423/bc1a4a5a/attachment-0004.bin -- next part -- A non-text attachment was scrubbed... Name: zel~.pd Type: application/puredata Size: 893 bytes Desc: not available Url : http://lists.puredata.info/pipermail/pd-list/attachments/20080423/bc1a4a5a/attachment-0005.bin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
I believe z~ is just rzero~ 0. cheers Miller On Wed, Apr 23, 2008 at 11:24:34AM +0200, Frank Barknecht wrote: Hallo, Matt Barber hat gesagt: // Matt Barber wrote: Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...). You don't need to set the block~-size to 1, and personally I would just make the delwrite~ big enough. It's cheap to store things in a delay. But anyway, attached is a z~-clone with delwrite~/delread~ that uses a helper abstraction created dynamically. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hi all, I think I tried putting cyclone in Pd a couple of years ago and got hung up over some problem or other. I'll look at it and see if I can just do it... cheers M On Wed, Apr 23, 2008 at 02:26:42PM +0800, Chris McCormick wrote: On Tue, Apr 22, 2008 at 09:38:25AM +0200, Frank Barknecht wrote: Note that I also think, the math objects (abs~, pow~ etc.) should be part of Pd, and probably symbol2list. I second this. Miller, what do you think? You have mentioned importing Cyclone into Pd; is it just a matter of yourself not having had the time to do this yet? Would you rather this happened in pd-extended first, or would you accept and apply patches rectifying this and making basic math tilde internals if they didn't conflict with Cyclone externals? Sorry to be so direct! Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Miller Puckette wrote: Hi all, I think I tried putting cyclone in Pd a couple of years ago and got hung up over some problem or other. I'll look at it and see if I can just do it... awesome! here is a short list of nameclashing objects. (at least what I found in pd-extended). Append conflicts with append from vanilla (which means helpfiles at least on win will be broken) Borax compatible with with borax from maxlib (helpfiles will be broken) Clip compatible with clip from vanilla uzi compatible with kalashnikov (uzi) from ext13. counter conflicts with counter from markex and cxc gate conflicts with gate from iemlib1 maximum compatible with max from vanilla mean conflicts with mean from zexy minimum compatible with min from vanilla prepend compatible with prepend from cxc record conflicts (?) with record from xsample urn conflicts with zexy urn but is compatible with maxlib urn but besides that it will offer a lot of great object classes like MouseState and sprintf and a somehow redundant zl. oh, and colored width adjustable comments! if you also get [cyclone] to work which had some import functionality for max patches... although I think max 5 will break any compatibility... marius. cheers M On Wed, Apr 23, 2008 at 02:26:42PM +0800, Chris McCormick wrote: On Tue, Apr 22, 2008 at 09:38:25AM +0200, Frank Barknecht wrote: Note that I also think, the math objects (abs~, pow~ etc.) should be part of Pd, and probably symbol2list. I second this. Miller, what do you think? You have mentioned importing Cyclone into Pd; is it just a matter of yourself not having had the time to do this yet? Would you rather this happened in pd-extended first, or would you accept and apply patches rectifying this and making basic math tilde internals if they didn't conflict with Cyclone externals? Sorry to be so direct! Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
It seems the cleanest solution would be to just include the objects that Andy has pointed out. Otherwise, I think adding the whole of cyclone will be opening up a big can of worms. .hc On Apr 23, 2008, at 4:16 PM, Miller Puckette wrote: Hi all, I think I tried putting cyclone in Pd a couple of years ago and got hung up over some problem or other. I'll look at it and see if I can just do it... cheers M On Wed, Apr 23, 2008 at 02:26:42PM +0800, Chris McCormick wrote: On Tue, Apr 22, 2008 at 09:38:25AM +0200, Frank Barknecht wrote: Note that I also think, the math objects (abs~, pow~ etc.) should be part of Pd, and probably symbol2list. I second this. Miller, what do you think? You have mentioned importing Cyclone into Pd; is it just a matter of yourself not having had the time to do this yet? Would you rather this happened in pd-extended first, or would you accept and apply patches rectifying this and making basic math tilde internals if they didn't conflict with Cyclone externals? Sorry to be so direct! Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote: On Tue, 22 Apr 2008 00:17:09 +0200 Derek Holzer [EMAIL PROTECTED] wrote: no worries, just thinking practically rather than wishfully ;-) :) always appreciate a practical attitude Practically, it's looking more and more like I need to drop the wishful thinking that I can write a useful and easy to understand textbook based around vanilla Pd. And instead write an easy-to-understand explanation of how to deal with the current situation re. externals, namespaces, nameclashes, library-loading and path-settings when your book is about sound design first and when a lot of these issues are still in flux? I'd rather use [expr~] a bit in the book, as your book will definitely outlast the current situation (from what I've read so far). Oh, and when [abs~] becomes part of Pd-vanilla, patches using [markex/abs~], [zexy/abs~], [cyclone/abs~], [creab/abs~] are in danger. Note that I also think, the math objects (abs~, pow~ etc.) should be part of Pd, and probably symbol2list. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote: I therefore define missing as when the best answer on the table is use [expr~] or use this equivalence made of more than 2 or 3 objects What about vanilla-abstractions? Pd-vanilla currently only ships with a handful of abstractions (rev123~.pd, hilbert~.pd) intended to be put in the path. Some of the missing math objects could be included as simple default abstractions, like [sin~]. Zexy went this route for [abs~]. Another point to take into account could be how many times an operation has been coded as an external before. [abs~] currently was coded four times to my knowledge (markex, zexy, creb, cyclone). This shows, that there is a demand for this operation, otherwise people wouldn't have bothered to code it. So yes, [abs~] would be good to have in Pd. I'm reluctant to mention [counter] here, which also was coded many times, unfortunatly in incompatible ways. I'm reluctant, because [counter] is too basic to be included. Call me elitist, but I believe counting is such a basic and important operation, Pd users should't learn how to count in Pd itself. Finally a motivation to include more binary objects may be efficiency. Some [list]-abs are much slower than necessary ([list-idx], [list-drip]) and these operations would be good to have in Pd as well. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Apr 22, 2008, at 3:52 AM, Frank Barknecht wrote: Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote: I therefore define missing as when the best answer on the table is use [expr~] or use this equivalence made of more than 2 or 3 objects What about vanilla-abstractions? Pd-vanilla currently only ships with a handful of abstractions (rev123~.pd, hilbert~.pd) intended to be put in the path. Some of the missing math objects could be included as simple default abstractions, like [sin~]. Zexy went this route for [abs~]. Another point to take into account could be how many times an operation has been coded as an external before. [abs~] currently was coded four times to my knowledge (markex, zexy, creb, cyclone). This shows, that there is a demand for this operation, otherwise people wouldn't have bothered to code it. So yes, [abs~] would be good to have in Pd. I'm reluctant to mention [counter] here, which also was coded many times, unfortunatly in incompatible ways. I'm reluctant, because [counter] is too basic to be included. Call me elitist, but I believe counting is such a basic and important operation, Pd users should't learn how to count in Pd itself. Finally a motivation to include more binary objects may be efficiency. Some [list]-abs are much slower than necessary ([list-idx], [list-drip]) and these operations would be good to have in Pd as well. Then we should also add streaming... wait this is starting to sound a bit like Pd-extended ;) .hc 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Tue, 22 Apr 2008 09:38:25 +0200 Frank Barknecht [EMAIL PROTECTED] wrote: Practically, it's looking more and more like I need to drop the wishful thinking that I can write a useful and easy to understand textbook based around vanilla Pd. And instead write an easy-to-understand explanation of how to deal with the current situation re. externals, namespaces, nameclashes, library-loading and path-settings when your book is about sound design first and when a lot of these issues are still in flux? Good advice Frank, it helps me think this through. The problem is the many examples (you haven't seen even 1/10 of the book yet :) There are almost 500 pages of detailed sound design examples. Each is constructed so that the student can build and explore the sound from practical patches. I've carefully tested and documented every step of each practical, so even (apparently) small problems like this thing with [pow~] rock the foundations of everything I've done. I am torn between trying to provide a solid introduction to Pd in its current state and just assuming the students can work these things out for themselves. As you can imagine, what I want to avoid is lots of caveats and special cases. It's very disruptive to the teaching/understanding flow to have to keep explaining why something doesn't actually work (the way it should) as given. Especially when the reasons for this are not technical and there's no good reason for it to be that way. I'd rather use [expr~] a bit in the book, as your book will definitely outlast the current situation (from what I've read so far). Well, for the fluid models I've had no choice, so [expr~] is already included along with a quick explanation because there is no [z~]. Unfortunately I've used [pow~] in dozens of other patches and it's quite unfeasible to go back and rewrite all of them and the accompanying text. It would take me weeks, and so I feel (on an emotional level) quite pissed off because adding [pow~] to vanilla Pd is only a matter of will and possibly 10 mins work to push it into the next build. If I'm going to aim this at Millers Pd rather than Extended then I feel it's only fair to have some movement making these small but vital improvements to vanilla. Note that I also think, the math objects (abs~, pow~ etc.) should be part of Pd, and probably symbol2list. Two of us doesn't make a concensus, but I've got the feeling most would agree. Can we make this a catalyst to get a definite commitment to patch up vanilla with the missing essentials? I still can't find the message, but I'm sure Miller said something about bringing Cyclone into vanilla. Can I please ask all the maths heads here to help define what would constitute a mathematically complete object set for audio signal processing? Right now my 'missing' list includes [z~], [abs~], [ln~], [log~], [pow~], [tanh~], [cosh~] Andy Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Andy Farnell wrote: Right now my 'missing' list includes [z~], [abs~], [ln~], [log~], [pow~], [tanh~], [cosh~] aren't you also referring to moog~ sometimes? marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Am 22.04.2008 um 17:02 schrieb Andy Farnell: Note that I also think, the math objects (abs~, pow~ etc.) should be part of Pd, and probably symbol2list. Two of us doesn't make a concensus, but I've got the feeling most would agree. Me for one, i have really missed pow~ or abs~ but i have been missing many other things. I don't see the necessity for the objects you mentioned when they can be built as abstractions using expr~ within seconds. How about an appendix to your book with a list of objects you used that are not included in pd-vanilla and the respective abstractions? gr~~~ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Then we should also add streaming... wait this is starting to sound a bit like Pd-extended ;) Is this the pattern that this debate always follows when someose suggests adding essential and sensible changes to Pd vanilla? Are we unable to distinguish between gaps in the axiomatic object set and non-essential accesories? Why sabotage the process by making a mockery of it? .hc 'You people have such restrictive dress for women,_ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - _Hijab Scene #2, by Mohja Kahf ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Tue, 22 Apr 2008 09:52:17 +0200 Frank Barknecht [EMAIL PROTECTED] wrote: I'm reluctant to mention [counter] here, which also was coded many times, unfortunatly in incompatible ways. I'm reluctant, because [counter] is too basic to be included. I heartily agree. In fact I don't suggest any message domain changes to vanilla right now, just the missing signal processing operators. [counter] is a perfect example of something that should never be in core Pd, it is ill defined. Things like [tanh~] however are fundamentally defined, so there's no change of two conflicting implementations (unless one is wrong). -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Andy Farnell wrote: On Tue, 22 Apr 2008 09:52:17 +0200 Frank Barknecht [EMAIL PROTECTED] wrote: I'm reluctant to mention [counter] here, which also was coded many times, unfortunatly in incompatible ways. I'm reluctant, because [counter] is too basic to be included. I heartily agree. In fact I don't suggest any message domain changes to vanilla right now, just the missing signal processing operators. [counter] is a perfect example of something that should never be in core Pd, it is ill defined. Things like [tanh~] however are fundamentally defined, so there's no change of two conflicting implementations (unless one is wrong). If you look at counter as a class of several methods, then you will agree, that it should have more features than just adding 1 everytime you send it a bang message. It should be able to count in different steps, start and end at different values, should be resettable, and probably should incorporate some more features like report when it hits the maximum or when it jumps back to the lowest value. there needs to be a place where the functionality of such kind of higher level object classes need to be discussed and specified, and then provided as whatever (c-internal, c-external, abstraction-internal, abstraction-external). I don't care. but from the practical viewpoint this is inevitable. everybody that codes in pd is dependent on a set of such objects. please, please, I apply to all pd developers and users to agree on a set of higher level objects or standard externals. even if they don't get shipped with every distribution (although I think they should be shipped and incorporated into pd vanilla), everybody should be aware of a canon of objectclasses. this would save hours, if not days of patching time. putting cyclone in vanilla would be a good start. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote: Unfortunately I've used [pow~] in dozens of other patches and it's quite unfeasible to go back and rewrite all of them and the accompanying text. It would take me weeks, and so I feel (on an emotional level) quite pissed off because adding [pow~] to vanilla Pd is only a matter of will and possibly 10 mins work to push it into the next build. If you want to avoid too much search-and-replace editing, maybe you could introduce your own wrapper abstraction version of [pow~] with [expr~ pow($v2, $v1)] inside? Call it [andypowell~] and do a search/replace session. Or call it [pow~] and tell people, that they either use the wrapper or install Cyclone or wait for a math.h-enhanced Pd-vanilla. The only thing left to check would be if you ever used [pow~ ARG] with an argument and maybe make that into a different abstraction. It's not totally beautiful, but well, at least it's possible to move back and forth a bit (i.e. if during your writing of the book Miller includes [pow~] you can just delete the pow~-abstraction paragraph.) If I'm going to aim this at Millers Pd rather than Extended then I feel it's only fair to have some movement making these small but vital improvements to vanilla. Note that I also think, the math objects (abs~, pow~ etc.) should be part of Pd, and probably symbol2list. Two of us doesn't make a concensus, but I've got the feeling most would agree. Can we make this a catalyst to get a definite commitment to patch up vanilla with the missing essentials? I still can't find the message, but I'm sure Miller said something about bringing Cyclone into vanilla. He mentioned on pd-dev, that he has considered this. Quote: there's text-editor code in Krzysztof Chaya's library, that I've wanted to glom into the vanilla Pd source for some time now (exactly so that people can pop up text editor windows for any 'binbuf' contents). Only thing holding me back is two minor issues: 1. I can't decide whether it's appropriate to glom te whole of Cyclone into Pd; and 2. assuming I don't do that, I'm worried it might break cyclone itself to export symbols from Pd that are also defined by cyclone. http://lists.puredata.info/pipermail/pd-list/2008-03/060677.html Can I please ask all the maths heads here to help define what would constitute a mathematically complete object set for audio signal processing? Right now my 'missing' list includes [z~], [abs~], [ln~], [log~], [pow~], [tanh~], [cosh~] I think, most operations from the standard C math library should be included as (signal) objects in Pd. The selection Lua took would be my guideline: http://www.lua.org/manual/5.1/manual.html#5.6 Note that there's no [ln~] here or rather: the natural log. would be called [log~] if following math.h. And as known [cos~] doesn't follow math.h nor [cos] either. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: If you want to avoid too much search-and-replace editing, maybe you could introduce your own wrapper abstraction version of [pow~] with [expr~ pow($v2, $v1)] inside? Call it [andypowell~] and do a search/replace session. Or call it [pow~] and tell people, that they either use the wrapper or install Cyclone or wait for a math.h-enhanced Pd-vanilla. Okay, not pow~, but attached [math~] object wraps all unary signal operations of expr~ in a trival, but nicer-looking abstraction. [math2~] for pow~ is left as an exercise for the reader. ;) Ciao -- Frank Barknecht _ __footils.org__ math~-help.pd Description: application/puredata math~.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Date: Tue, 22 Apr 2008 16:02:37 +0100 From: Andy Farnell [EMAIL PROTECTED] Subject: Re: [PD] Cyclone in vanilla? To: pd-list@iem.at = Right now my 'missing' list includes [z~], [abs~], [ln~], [log~], [pow~], [tanh~], [cosh~] One might put [atan~] and [atan2~] on this list as well. [ln~] and [log~] probably ought instead to be [log~] and [log10~], respectively. Actually, for those of us who insist on vanilla and do everything with expr/expr~/fexpr~ or abstractions, is it possible to implement [z~] in fexpr~ for a delay larger than its vector size? You could do it with an abstraction using [delwrite~] and [delread~], setting the [block~] to 1, and then set the delay as a ratio to the [samplerate~] -- the difficulty in making it work correctly here is setting the size of the [delwrite~] efficiently (this could maybe be done with a loadbang routine that would send a message to a subpatch in the abstraction instance to add and connect a delwrite~ with the proper delay allocation...). In pedagogical situations such an example might also be useful for gently introducing the block/vector structure of PD that you would need anyway for proper delay/feedback examples as well as FFT (and possibly for sending messages to subpatches), but I'm pretty sure it's not the most efficient model available. On a similar note, is it possible to recreate things like [zexy/noish~] or [zexy/noisi~] in vanilla PD as an abstraction? It would be great to have these for building pinkish noise or random control of other audio parameters, and these seem fairly primitive to any serious synthesis engine. Thanks, Matt ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Can the job be done with [expr~]? d. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 190: You can only make one dot at a time ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Yes. Please don't take this the wrong way Derek, I sincerely appreciate the suggestion. Everything can be done with [expr~], so why don't we just rename Pd to [expr~]? :) Seriously, raising one number to a power is an essential, fundamental operation Is there any plausible excuse for its omission from core Pd? On Mon, 21 Apr 2008 20:53:00 +0200 Derek Holzer [EMAIL PROTECTED] wrote: Can the job be done with [expr~]? d. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 190: You can only make one dot at a time -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Hi Andy, no worries, just thinking practically rather than wishfully ;-) Maybe some of the math-heads here can make a contest to see how much of a PD patch/instrument they could make using ONLY [expr] and [expr~]... the winner gets a Heineken and a bar of Dial soap, or something . I only suggested this because [~] and [~], which I use to create basic square waves, were problematic during my workshops for a while, depending on which flavor of PD the participants installed, and also whether the OS (or whatever) could handle the Greater Than or Less Than symbol in the external object name. The only solution seemed to be to replace these two objects with an [expr~] in my tutorials. Your mileage may vary. Best, d. Andy Farnell wrote: Yes. Please don't take this the wrong way Derek, I sincerely appreciate the suggestion. Everything can be done with [expr~], so why don't we just rename Pd to [expr~]? :) Seriously, raising one number to a power is an essential, fundamental operation Is there any plausible excuse for its omission from core Pd? -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 59: Don't avoid what is easy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
[expr pow($f1,$f2)] or [expr~ pow($v1,$f2)] or [expr~ pow($v1,$v2)] etc. I don't know why you consider this an omission? JP Andy Farnell wrote: Yes. Please don't take this the wrong way Derek, I sincerely appreciate the suggestion. Everything can be done with [expr~], so why don't we just rename Pd to [expr~]? :) Seriously, raising one number to a power is an essential, fundamental operation Is there any plausible excuse for its omission from core Pd? On Mon, 21 Apr 2008 20:53:00 +0200 Derek Holzer [EMAIL PROTECTED] wrote: Can the job be done with [expr~]? d. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 190: You can only make one dot at a time ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Mon, 21 Apr 2008 16:27:17 -0400 Julian Peterson [EMAIL PROTECTED] wrote: [expr pow($f1,$f2)] or [expr~ pow($v1,$f2)] or [expr~ pow($v1,$v2)] etc. I don't know why you consider this an omission? JP Hi Julian, Thanks for the suggestion I consider it an omission because [pow~] is a fundamental operation that deserves its own object in core Pd. For the same reason you would consider [cos~] to be an omission if you were forced to construct it from a series approximation. [expr~] is unsatisfactory. It does not suit beginners because of its syntax and is computationally inefficient. It is a useful catch-all for certain situations and should only be used where necessary and when no other option is available. Same goes for [z~], another fundamental (vital) DSP primitive that is bizzarely missing from vanilla Pd. There are several other objects that, while possible to construct using combinations of primititives, are clumsy and confusing for students to work around, such as [abs~] It is high time we got together as a community with Miller and patched up these holes in the axiomatic object set. Vanilla Pd is incomplete without some additions. Andy -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
On Tue, 22 Apr 2008 00:17:09 +0200 Derek Holzer [EMAIL PROTECTED] wrote: no worries, just thinking practically rather than wishfully ;-) :) always appreciate a practical attitude Practically, it's looking more and more like I need to drop the wishful thinking that I can write a useful and easy to understand textbook based around vanilla Pd. Using [expr~ pow($v1,$v2)] instead of [pow~] is exactly the sort of ugly and confusing thing that sabotages learning, don't you agree? Why we don't make the vanilla object set operationally complete is beyond me. There are less than 10 essential missing objects and less than 20 desirable ones. Why build a bridge 90% across the river and expect people to jump the last few meters? -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
Fair point Hans. My main consideration though is ease of understanding. What this looks like to students when you have to explain there isn't an object to raise to a power in Pd, but there is a button dedicated to it on every desktop calculator. On Mon, 21 Apr 2008 18:59:46 -0400 Hans-Christoph Steiner [EMAIL PROTECTED] wrote: And to stir the pot, expr is GPL, almost all the rest of Pd is BSD, so you might not always be able to use expr. .hc On Apr 21, 2008, at 3:55 PM, Andy Farnell wrote: Yes. Please don't take this the wrong way Derek, I sincerely appreciate the suggestion. Everything can be done with [expr~], so why don't we just rename Pd to [expr~]? :) Seriously, raising one number to a power is an essential, fundamental operation Is there any plausible excuse for its omission from core Pd? On Mon, 21 Apr 2008 20:53:00 +0200 Derek Holzer [EMAIL PROTECTED] wrote: Can the job be done with [expr~]? d. Andy Farnell wrote: Did I read that Cyclone is to be incorporated into vanilla Pd? Having discovered too late that [pow~] is not part of vanilla I am about to remove the constraint of using vanilla Pd for the synthetic sound design book since it is incomplete without basic mathematical operators. andy -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 190: You can only make one dot at a time -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list 'You people have such restrictive dress for women,_ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - _Hijab Scene #2, by Mohja Kahf -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
I think this is definitely a good thing in terms of accessability. If someone codes these missing 10 and submitted them to the patch tracker, I'll bet there is a good chance that they would be accepted. .hc On Apr 21, 2008, at 7:52 PM, Andy Farnell wrote: On Tue, 22 Apr 2008 00:17:09 +0200 Derek Holzer [EMAIL PROTECTED] wrote: no worries, just thinking practically rather than wishfully ;-) :) always appreciate a practical attitude Practically, it's looking more and more like I need to drop the wishful thinking that I can write a useful and easy to understand textbook based around vanilla Pd. Using [expr~ pow($v1,$v2)] instead of [pow~] is exactly the sort of ugly and confusing thing that sabotages learning, don't you agree? Why we don't make the vanilla object set operationally complete is beyond me. There are less than 10 essential missing objects and less than 20 desirable ones. Why build a bridge 90% across the river and expect people to jump the last few meters? -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
the question is a very blasphemic one, and I am not sure, if I should bring this into discussion at all... but how long is miller going to develop pd, and when should vanilla become a group effort rather than a one man show? and who is ever willing to take responsibility for the future direction? right now I don't see a reason why the objects you were mentioning should not be in vanilla, and only miller knows the answer to that. and I probably will be expelled from the pd-community from now on. marius. Andy Farnell wrote: On Tue, 22 Apr 2008 00:17:09 +0200 Derek Holzer [EMAIL PROTECTED] wrote: no worries, just thinking practically rather than wishfully ;-) :) always appreciate a practical attitude Practically, it's looking more and more like I need to drop the wishful thinking that I can write a useful and easy to understand textbook based around vanilla Pd. Using [expr~ pow($v1,$v2)] instead of [pow~] is exactly the sort of ugly and confusing thing that sabotages learning, don't you agree? Why we don't make the vanilla object set operationally complete is beyond me. There are less than 10 essential missing objects and less than 20 desirable ones. Why build a bridge 90% across the river and expect people to jump the last few meters? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Cyclone in vanilla?
the question is a very blasphemic one, and I am not sure, if I should bring this into discussion at all... It's vital we discuss this. It took a while for me to appreciate what I believe to be Millers philosophy, and in principle I agree with and respect it. To keep the core of Pd as small and maintainable as possible using a minimal set of objects is smart. I hope that tradition continues whatever the future and that the requirements for entry into the Pd core are very strict indeed. Many times I've learned my lesson thinking that some higher level object was irreplaceable only to be put right by someone showing an equivalence using two or three existing primitives. This has been very educational. However, while two or three objects combined is acceptable it breaks down when one must implement elaborate patches to do fundamental things. Everyone knows that sin(x) = 1 - cos(x) [in rotation normalised Pd speak], and [abs~] can be trivially constructed using [min~] and [max~]. No big problems there. But what of things like [z~], [pow~], [tanh~], [ln~] and so forth? These are basic operations that MUST be in any signal processing framework if it is to be considered complete. The existence of pd-extended as a system of non-essential objects around the core seems the perfect solution. But I submit that the core is incomplete and therefore I have the ridiculous situation of either having to jump through ugly hoops to do simple things or having to suggest the students download the entirety of extended for the sake of a few vital but missing objects. I therefore define missing as when the best answer on the table is use [expr~] or use this equivalence made of more than 2 or 3 objects The question must be What defines vanilla Pd? Is it, as I have assumed above, Millers intention to maintain a minimal but axiomatically complete set of objects. If so then we must surely agree that the set is incomplete. The question then becomes Why are certain primitives missing? There may be many good reasons such as platform compilation problems, licensing obstacles or namespace issues, but I venture that none are insurmountable if we work as a community to submit robust implementations and work around the problems. I'm not talking about elaborate objects like autocorrelation or YIN pitch estimation, just the basic, primitive essentials. I feel uncomfortable talking about this as if Miller were absent, so I do hope the discussion will be joined soon. We have many good mathematicians here who could help define what is the minimal axiomatic object set, prove that it's complete and show the theorems to build everything higher. This also requires practical input from people like myself who use Pd every day to say Sure, you can build an abstraction using x, y and z, but that is __unacceptably impractical__ when a simple core object could be added. As you know this has come up before, regarding [delta~] (which I foolishly assumed was intrinsic - my fault). But I never considered for a moment that [pow~] or [ln~] are not core objects! Time is a factor now and I need to choose (again) whether vanilla Pd can be the recommended installation for the book, or whether to drop many valuable examples, or whether to make pd-extended mandatory. Very frustrating. most sincerely Andy -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
