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
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
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 derek@umatic.nl 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"
[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 derek@umatic.nl 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"
On Mon, 21 Apr 2008 16:27:17 -0400 Julian Peterson julianpeterson@mac.com 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
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?
On Tue, 22 Apr 2008 00:17:09 +0200 Derek Holzer derek@umatic.nl 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?
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 derek@umatic.nl 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.
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 derek@umatic.nl 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?
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
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__
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
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
On Tue, 22 Apr 2008 09:52:17 +0200 Frank Barknecht fbar@footils.org 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).
Andy Farnell wrote:
On Tue, 22 Apr 2008 09:52:17 +0200 Frank Barknecht fbar@footils.org 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.
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
On Tue, 22 Apr 2008 00:17:09 +0200 Derek Holzer derek@umatic.nl 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__
On Tue, 22 Apr 2008 09:38:25 +0200 Frank Barknecht fbar@footils.org 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
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~~~
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
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__
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__
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.
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.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
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
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.
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
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
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.
On Thu, 24 Apr 2008 08:01:26 -0400 marius schebella marius.schebella@gmail.com 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
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 marius.schebella@gmail.com 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
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 derek@umatic.nl 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
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 hans@eds.org 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 derek@umatic.nl 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
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
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 marius.schebella@gmail.com 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
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 marius.schebella@gmail.com 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
On Thu, 24 Apr 2008 09:38:07 -0700 Miller Puckette mpuckett@imusic1.ucsd.edu 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 marius.schebella@gmail.com 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
Andy Farnell wrote:
On Thu, 24 Apr 2008 09:38:07 -0700 Miller Puckette mpuckett@imusic1.ucsd.edu 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
On Thu, 24 Apr 2008 18:17:29 +0100 Claude Heiland-Allen claudiusmaximus@goto10.org 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.
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.
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.
On Thu, 24 Apr 2008 20:30:44 +0200 Steffen Juul stffn@dibidut.dk 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.
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 marius.schebella@gmail.com 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
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 marius.schebella@gmail.com wrote:
counter, which are the real troublemakes regarding backwards compatibility and shareability. marius.
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
honestly, I think not many people used it... I ran grep -R " pow~" * in my pd-directories and found only two patches (of 10000+) 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 marius.schebella@gmail.com wrote:
counter, which are the real troublemakes regarding backwards compatibility and shareability. marius.
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 10000+) 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
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 10000+) 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
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.
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 10000+)
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
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.
On Fri, 25 Apr 2008 16:39:04 +0200 Frank Barknecht fbar@footils.org 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
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.
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
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
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.
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.
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.
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__
On Fri, 25 Apr 2008 18:27:53 +0200 Frank Barknecht fbar@footils.org wrote:
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 am comitted to making substatial changes already, so in for a penny in for a pound...
All I ask is that we settle on something soon (within weeks) and stick to it. It will take me about two more weeks to make changes to all the practicals that use [pow~] after that.
If we can arrive at a solid statement about any other audio objects that will make it into an enlarged Vanilla soon, then all the better. That really helps me make plans.
I am about 70% through the changes you, Marius and Steffen have given for the first proofreading pass. After that I will give you the updated introductory chapters (and also to Miller)
On Fri, 25 Apr 2008 09:52:43 -0400 Julian Peterson julianpeterson@mac.com 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.
-
Andy Farnell -
Chris McCormick -
Claude Heiland-Allen -
Derek Holzer -
Frank Barknecht -
Hans-Christoph Steiner -
hard off -
Jamie Bullock -
Julian Peterson -
marius schebella -
Miller Puckette -
Steffen Juul -
Thomas Grill