Re: [PD] abs~ and exp~ fixes [was: rjdj]

2009-03-30 Thread volker böhm


On 29 Mar 2009, at 19:09, Frank Barknecht wrote:






You could copy over some abs~.pd_darwin from pd-extended, pd-0.42  
will happily

use that instead.



i tried that, but here pd vanilla always prefers its own internal abs~.
sticking the external abs~ into /Contents/Resources/extra/ didn't help.
neither did creating an extra folder (with abs~ inside) and adding  
its path to pd's path preferences (this normally works for adding my  
own externals).


where would i put the external, to overrule the internal?
as i understand from the recent discussions this process is rather  
convoluted, but is it also unpredictable?


vb


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


Re: [PD] abs~ and exp~ fixes [was: rjdj]

2009-03-30 Thread Frank Barknecht
Hallo,
volker b?hm hat gesagt: // volker b?hm wrote:

 i tried that, but here pd vanilla always prefers its own internal abs~.
 sticking the external abs~ into /Contents/Resources/extra/ didn't help.
 neither did creating an extra folder (with abs~ inside) and adding its 
 path to pd's path preferences (this normally works for adding my own 
 externals).

 where would i put the external, to overrule the internal?
 as i understand from the recent discussions this process is rather  
 convoluted, but is it also unpredictable?

It's strange and in the opinion of several other developers like IOhannes
(and I think me, too) buggy by design, too. But if you load the abs~.pd_darwin
with -lib abs~ then that should override the internal. 

However it's better for now to replace the [abs~] with the tabread~ solution I
posted as absolute~.pd yesterday. Just embed it into the patch.

Ciao
-- 
Frank

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


Re: [PD] building vanilla on os x (Was: Re: abs~ and exp~ fixes [was: rjdj])

2009-03-30 Thread volker böhm


On 30 Mar 2009, at 00:31, Hans-Christoph Steiner wrote:


On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:



On 29/03/2009, at 17.41, volker böhm wrote:

however i never succeeded in building pd vanilla on osx myself  
(anyone?).


No, not with the makefile shipped with vanilla. It would be nice  
to know who Miller actually builds it.



You can build it with the Pd-extended build system.  You just have  
to remove the --enable-jack or use the old version of JackOSX.


thanks hc, i remember you mentioned that before.
i did try it some time ago, but didn't get very far either.
didn't spend much time on this, so no complaints. it probably works  
that way.
but i remember downloading a lot of files (part of which i didn't  
actually want), trying to compile a huge amount of code and finally  
stranding in some chaotic/confused state ;)
i thought that the documentation to end up with a simple vanilla  
build wasn't particulary clear.

(if it's useful, i could go into greater detail here)

what remains is the impression that it shouldn't be so complicated  
(compared to a simple linux build!).

but obviously osx doesn't play well in this respect.

vb
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] abs~ and exp~ fixes [was: rjdj]

2009-03-30 Thread volker böhm


On 30 Mar 2009, at 12:23, Frank Barknecht wrote:
However it's better for now to replace the [abs~] with the tabread~  
solution I

posted as absolute~.pd yesterday. Just embed it into the patch.


yes, thanks.
vb

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


Re: [PD] building vanilla on os x (Was: Re: abs~ and exp~ fixes [was: rjdj])

2009-03-30 Thread Luke Iannini
On Mon, Mar 30, 2009 at 3:52 AM, volker böhm vbo...@gmx.ch wrote:

 On 30 Mar 2009, at 00:31, Hans-Christoph Steiner wrote:

 On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:


 On 29/03/2009, at 17.41, volker böhm wrote:

 however i never succeeded in building pd vanilla on osx myself
 (anyone?).

 No, not with the makefile shipped with vanilla. It would be nice to know
 who Miller actually builds it.
Hmm.. I build Pd on OS X all the time!  I don't think I've done
anything special but perhaps I did long ago.  Of course, I don't know
the process by which Miller assembles the Pd app bundle, but I simply
build the pd binary and drop it in to the latest Pd.app from Miller's
site.

Where is it failing?
Best
Luke



 You can build it with the Pd-extended build system.  You just have to
 remove the --enable-jack or use the old version of JackOSX.

 thanks hc, i remember you mentioned that before.
 i did try it some time ago, but didn't get very far either.
 didn't spend much time on this, so no complaints. it probably works that
 way.
 but i remember downloading a lot of files (part of which i didn't actually
 want), trying to compile a huge amount of code and finally stranding in some
 chaotic/confused state ;)
 i thought that the documentation to end up with a simple vanilla build
 wasn't particulary clear.
 (if it's useful, i could go into greater detail here)

 what remains is the impression that it shouldn't be so complicated (compared
 to a simple linux build!).
 but obviously osx doesn't play well in this respect.

 vb
 ___
 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] GEM on the web?

2009-03-30 Thread Ben Baker-Smith
Hello list,

I've been hearing bits and pieces recently about using PD across
networks and the internet.  I believe some people were actually
working on developing a website where multiple users could upload and
manipulate the same PD patch in close-to realtime.

What I'm wondering is this:  Is it possible, or could it be possible,
to display an active Gemwindow on a website?

Ideally, visitors to the site would be able to interact with the
patch, either through microphone input on their computer or
keystrokes, etc.  However, I'd even be happy with a way to run an
ongoing, non-interactive patch.

I know basically nothing about the networking side of PD, and I'm sure
this is over my head right now, but I'd really appreciate any
feedback.

Thanks,
-Ben

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


Re: [PD] pd book sprint

2009-03-30 Thread Alexandre Porres
Hi, I am really interested in helping!
I actually have some stuff I wanted to corrrect, or bring some attention
to, like the DC OFFSET. You dont cover it, and when you show how to get a
Square Wave, the DC Offset is not properly adjusted.

thanks

cheers

On Mon, Mar 30, 2009 at 11:20 AM, Derek Holzer de...@umatic.nl wrote:

 Hey Alexandre,

 I just posted the announcement of the Pd FLOSS Manuals Book Sprint:

 http://lists.puredata.info/pipermail/pd-list/2009-03/069107.html

 I was wondering if you'd be interested to help out next weekend? It
 shouldn't be a problem to contribute remotely, and it would really help
 build up the momentum to finish this manual.

 Have a look over the topics and see if there is anything you'd like to
 cover and let me know.

 Best!
 Derek

 --
 ::: derek holzer ::: http://blog.myspace.com/macumbista :::
 http://www.vimeo.com/macumbista :::
 ---Oblique Strategy # 11:
 Always first steps





-- 
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer

Alexandre,

Yes please, get on board!

In the case of the square wave chapter, I had assumed that doing it with 
digital logic would result in either 0 (no amplitude) or 1 (full 
amplitude). So there shouldn't be any DC offset when it's at 0. Of 
course, there are some other real-world problems with those patches, 
namely that there is also no antialiasing.


Since the FLOSS Manuals are modular, they can be remixed as needed for 
any kind of workshop, class or curriculum, including or leaving out 
sections from all the different FLOSS Manuals as needed.


So my suggestion to you would be to write a short chapter on DC offset 
which can then be referred to in the square wave tutorial, or in any 
other tutorial or manual where such a situation might arise.


Likewise, I'd love it if someone could do a single chapter on the 
different antialiasing methods (Miller's, Frank's...). The idea would be 
to simplify the explanations so that one doesn't need a background in 
DSP or computer science in order to understand them.


Would you be interested to do either of those?

D.

Alexandre Porres wrote:

Hi, I am really interested in helping!

I actually have some stuff I wanted to corrrect, or bring some 
attention to, like the DC OFFSET. You dont cover it, and when you show 
how to get a Square Wave, the DC Offset is not properly adjusted.


thanks

cheers

On Mon, Mar 30, 2009 at 11:20 AM, Derek Holzer de...@umatic.nl 
mailto:de...@umatic.nl wrote:


Hey Alexandre,

I just posted the announcement of the Pd FLOSS Manuals Book Sprint:

http://lists.puredata.info/pipermail/pd-list/2009-03/069107.html

I was wondering if you'd be interested to help out next weekend? It
shouldn't be a problem to contribute remotely, and it would really help
build up the momentum to finish this manual.

Have a look over the topics and see if there is anything you'd like to
cover and let me know.

Best!
Derek

-- 
::: derek holzer ::: http://blog.myspace.com/macumbista :::

http://www.vimeo.com/macumbista :::
---Oblique Strategy # 11:
Always first steps





--
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres



--
::: derek holzer ::: http://blog.myspace.com/macumbista ::: 
http://www.vimeo.com/macumbista :::

---Oblique Strategy # 109:
Lost in useless territory

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


[PD] Background Colour...

2009-03-30 Thread Simon Ball
Hi there, simple question...

How do I change the background colour of the window?

I'm still learning, obviously.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer
Actually, DC offset could be covered in What is Digital Audio, since 
it is a concept that needs explaining. Then, my suggestion still is to 
include it after the basics of the Square Waves. I'd like to keep the 
patches there as simple as possible, and since the DC Offset can be done 
at the end, why not have it there?


Triangle wave would also be good. Write it first and we'll see where 
exactly to put it.


D.


Alexandre Porres wrote:

sure, I could do both.

But I think it would be inportant to start just after
 


* AUDIO TUTORIALS
* SimpleSynthIntroduction
  http://en.flossmanuals.net/PureData/SimpleSynthIntroduction


and before the oscilators with the Short DC offset chapter.

Then edit and correct the oscilator patches with values from -1 to 1

I also can create and put in the oscilator chapter a Triangle wave 
oscilator made with phasor


what do you say?

Cheers


On Mon, Mar 30, 2009 at 11:43 AM, Derek Holzer de...@umatic.nl 
mailto:de...@umatic.nl wrote:


Alexandre,

Yes please, get on board!

In the case of the square wave chapter, I had assumed that doing it
with digital logic would result in either 0 (no amplitude) or 1
(full amplitude). So there shouldn't be any DC offset when it's at
0. Of course, there are some other real-world problems with those
patches, namely that there is also no antialiasing.

Since the FLOSS Manuals are modular, they can be remixed as needed
for any kind of workshop, class or curriculum, including or leaving
out sections from all the different FLOSS Manuals as needed.

So my suggestion to you would be to write a short chapter on DC
offset which can then be referred to in the square wave tutorial, or
in any other tutorial or manual where such a situation might arise.

Likewise, I'd love it if someone could do a single chapter on the
different antialiasing methods (Miller's, Frank's...). The idea
would be to simplify the explanations so that one doesn't need a
background in DSP or computer science in order to understand them.

Would you be interested to do either of those?

D.

Alexandre Porres wrote:

Hi, I am really interested in helping!

I actually have some stuff I wanted to corrrect, or bring some
attention to, like the DC OFFSET. You dont cover it, and when
you show how to get a Square Wave, the DC Offset is not properly
adjusted.

thanks

cheers

On Mon, Mar 30, 2009 at 11:20 AM, Derek Holzer de...@umatic.nl
mailto:de...@umatic.nl mailto:de...@umatic.nl
mailto:de...@umatic.nl wrote:

   Hey Alexandre,

   I just posted the announcement of the Pd FLOSS Manuals Book
Sprint:

   http://lists.puredata.info/pipermail/pd-list/2009-03/069107.html

   I was wondering if you'd be interested to help out next
weekend? It
   shouldn't be a problem to contribute remotely, and it would
really help
   build up the momentum to finish this manual.

   Have a look over the topics and see if there is anything
you'd like to
   cover and let me know.

   Best!
   Derek

   --::: derek holzer ::: http://blog.myspace.com/macumbista :::
   http://www.vimeo.com/macumbista :::
   ---Oblique Strategy # 11:
   Always first steps





-- 
Alexandre Torres Porres

cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres


-- 
::: derek holzer ::: http://blog.myspace.com/macumbista :::

http://www.vimeo.com/macumbista :::
---Oblique Strategy # 109:
Lost in useless territory




--
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres



--
::: derek holzer ::: http://blog.myspace.com/macumbista ::: 
http://www.vimeo.com/macumbista :::

---Oblique Strategy # 67:
Emphasize the flaws

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


Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer
I've noticed that some systems actually don't create [~] or [~], so I 
was thinking to redo those sections with [expr~] anyways. If you'd like 
to jump in and do all that, it could work. The main part of that chapter 
is that it is also covering digital logic, so I wanted to stick with 
values of 0 and 1 for clarity. Do you see any way we can work this out?


D.

Alexandre Porres wrote:

well, for instance

inside the Squarewaves and Logic  chapter

the DC Offset could be easilly built inside the EXPR object, either in 
the one that is already there, or in an object right after to make the 
visualization easier. I could edit all thos patches that need to adjust 
the DC offset.


On this case, it would also be nice to have the Tables just a bit larger 
that -1 - 1, (1.1 or 1.2) so we can better see the Square Waves.


cheers


On Mon, Mar 30, 2009 at 11:50 AM, Alexandre Porres por...@gmail.com 
mailto:por...@gmail.com wrote:


sure, I could do both.

But I think it would be inportant to start just after
 


* AUDIO TUTORIALS
* SimpleSynthIntroduction
  http://en.flossmanuals.net/PureData/SimpleSynthIntroduction


and before the oscilators with the Short DC offset chapter.

Then edit and correct the oscilator patches with values from -1 to 1

I also can create and put in the oscilator chapter a Triangle wave
oscilator made with phasor

what do you say?

Cheers


On Mon, Mar 30, 2009 at 11:43 AM, Derek Holzer de...@umatic.nl
mailto:de...@umatic.nl wrote:

Alexandre,

Yes please, get on board!

In the case of the square wave chapter, I had assumed that doing
it with digital logic would result in either 0 (no amplitude) or
1 (full amplitude). So there shouldn't be any DC offset when
it's at 0. Of course, there are some other real-world problems
with those patches, namely that there is also no antialiasing.

Since the FLOSS Manuals are modular, they can be remixed as
needed for any kind of workshop, class or curriculum, including
or leaving out sections from all the different FLOSS Manuals as
needed.

So my suggestion to you would be to write a short chapter on DC
offset which can then be referred to in the square wave
tutorial, or in any other tutorial or manual where such a
situation might arise.

Likewise, I'd love it if someone could do a single chapter on
the different antialiasing methods (Miller's, Frank's...). The
idea would be to simplify the explanations so that one doesn't
need a background in DSP or computer science in order to
understand them.

Would you be interested to do either of those?

D.

Alexandre Porres wrote:

Hi, I am really interested in helping!

I actually have some stuff I wanted to corrrect, or bring
some attention to, like the DC OFFSET. You dont cover it,
and when you show how to get a Square Wave, the DC Offset is
not properly adjusted.

thanks

cheers

On Mon, Mar 30, 2009 at 11:20 AM, Derek Holzer
de...@umatic.nl mailto:de...@umatic.nl
mailto:de...@umatic.nl mailto:de...@umatic.nl wrote:

   Hey Alexandre,

   I just posted the announcement of the Pd FLOSS Manuals
Book Sprint:

 
 http://lists.puredata.info/pipermail/pd-list/2009-03/069107.html


   I was wondering if you'd be interested to help out next
weekend? It
   shouldn't be a problem to contribute remotely, and it
would really help
   build up the momentum to finish this manual.

   Have a look over the topics and see if there is anything
you'd like to
   cover and let me know.

   Best!
   Derek

   --::: derek holzer :::
http://blog.myspace.com/macumbista :::
   http://www.vimeo.com/macumbista :::
   ---Oblique Strategy # 11:
   Always first steps





-- 
Alexandre Torres Porres

cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres


-- 
::: derek holzer ::: http://blog.myspace.com/macumbista :::

http://www.vimeo.com/macumbista :::
---Oblique Strategy # 109:
Lost in useless territory




-- 
Alexandre Torres Porres

cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres




--
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres



--
::: derek holzer ::: http://blog.myspace.com/macumbista ::: 

Re: [PD] pd book sprint

2009-03-30 Thread Claude Heiland-Allen

Alexandre Porres wrote:

and before the oscilators with the Short DC offset chapter.


[hip~ 1]


I also can create and put in the oscilator chapter a Triangle wave oscilator
made with phasor


[phasor~]   [r~ shape]
[expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]


Claude
--
http://claudiusmaximus.goto10.org

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


Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer

Hello Claude,

Claude Heiland-Allen wrote:

Alexandre Porres wrote:

and before the oscilators with the Short DC offset chapter.


[hip~ 1]


Yes, my thought also, just take care of it with [hip~]. But also, I 
think the problem of the digital logic system I've created isn't so big, 
as it can be scaled later, at the end of the whole signal chain:


[*~ 2]
|
[-~ 1]

with the [hip] for extra protection if needed. No need to completely 
rewrite the chapter. There is more than one right way to do things in 
Pd ;-)




I also can create and put in the oscilator chapter a Triangle wave 
oscilator

made with phasor


[phasor~]   [r~ shape]
[expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]


Ah, but can you explain in non-technical English why this works? 
Remember our reader base aren't mathematicians like Miller ;-)


best,
D.

--
::: derek holzer ::: http://blog.myspace.com/macumbista ::: 
http://www.vimeo.com/macumbista :::

---Oblique Strategy # 22:
Be less critical more often

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


Re: [PD] pd book sprint

2009-03-30 Thread Frank Barknecht
Hallo,
Derek Holzer hat gesagt: // Derek Holzer wrote:

 [phasor~]   [r~ shape]
 [expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]

 Ah, but can you explain in non-technical English why this works?  
 Remember our reader base aren't mathematicians like Miller ;-)

A past post by me describes a different algorithm (without skew) but it 
shows the generation of a triangle from a phasor using a message analogy:
http://lists.puredata.info/pipermail/pd-list/2006-11/044253.html
which I find quite intuitive. 

Ciao
-- 
Frank

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


Re: [PD] [OT] Re: DIY GSoC: getting those projects done

2009-03-30 Thread Mathieu Bouchard

On Sat, 28 Mar 2009, Chris McCormick wrote:


When I was thinking about writing a general purpose dataflow programming
language which addresses some of Pd's shortcomings, I did a lot of thinking
about the hot and cold inlet paradigm. What I came up with was the following
scheme:
* Hot inlets are red
* Cold inlets are blue
* Neutral inlets are grey
* A class has a default hot/cold/neutral inlet configuration defined by the
 author.
* The UI allows the user to change the hot/cold/neutral status of inlets.
* An instance's 'run' method is executed when any of the following conditions


Well, it would be cool to have a way to configure that in Pd using a 
uniform syntax all over Pd, or using Pd's GUI. Even without that, I think 
that it would be important to introduce the run concept anyway, because 
it could help structuring the documentation; I mean it could be introduced 
at the documentation level first. For implementation, it's currently 
harder, especially in GridFlow where the implementation currently uses the 
hot/cold asymmetry to optimise.


* A class has a default hot/cold/neutral inlet configuration defined by 
the author.
* The UI allows the user to change the hot/cold/neutral status of 
inlets.
* An instance's 'run' method is executed when any of the following 
conditions are met:

  * Every cold inlet has been pinged (receives data)
  * Any hot inlet has been pinged (receives data)
* Inlets cache their last received data if no new data arrives.
In Pd, DSP inlets act like the 'cold' inlets above


Well, perhaps you should rename 'neutral' inlets to 'cold' and find 
another name for what you call 'cold'. Even then, DSP inlets still don't 
work like your 'cold' inlets because of how they combine together a fan-in 
(several wires to one inlet) and because of how they handle a 
non-connected inlet.



I like the idea of this behaviour being defined by the class author, but
(re)configurable by the user.


Then this would need a special 'run' method to be defined in t_class, 
preferably outside of the normal method-list. At first thought I think I'm 
in favour of reconfigurable inlets, but I'd like to see a proof-of-concept 
first.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
5B___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] building vanilla on os x (Was: Re: abs~ and exp~ fixes [was: rjdj])

2009-03-30 Thread volker böhm


On 30 Mar 2009, at 14:01, Luke Iannini wrote:

On Mon, Mar 30, 2009 at 3:52 AM, volker böhm vbo...@gmx.ch wrote:


On 30 Mar 2009, at 00:31, Hans-Christoph Steiner wrote:


On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:



On 29/03/2009, at 17.41, volker böhm wrote:


however i never succeeded in building pd vanilla on osx myself
(anyone?).


No, not with the makefile shipped with vanilla. It would be nice  
to know

who Miller actually builds it.

Hmm.. I build Pd on OS X all the time!  I don't think I've done
anything special but perhaps I did long ago.  Of course, I don't know
the process by which Miller assembles the Pd app bundle, but I simply
build the pd binary and drop it in to the latest Pd.app from Miller's
site.



aha, that's interesting - thanks, luke, this works indeed!
i'm still on ppc and had to run ./configure with --disable-fat to  
make the compilation work.
so far so good. i had already found that during my earlier attempts  
to build pd.

doing this i end up with
libPdTcl.dylib, pd, pd-watchdog, pd.tk, pdreceive, pdsend
in the /bin folder.

BUT i wrongly assumed, i could start pd on osx just (as under linux)  
directly from the bin folder by typing ./pd
this turned out to not work, giving me a pd window, but a  
nonfunctional app (menus not filled, no reaction to key strokes,  
indicating wish instead of pd etc.).


but replacing the pd bin in an old application bundle by the freshly  
compiled pd binary did the trick.

(and now abs~ is performing fine!)

actually i have just tried with an old copy of pd-0.37-1 for osx and  
there it works by starting pd directly from /bin - something  
obviously changed in between.
i would be interested in knowing what's the startup sequence when  
double clicking on the app bundle.

(and how one can build the app bundle after all).

thanks,
vb




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


Re: [PD] pd book sprint

2009-03-30 Thread Frank Barknecht
Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:

 Hallo,
 Derek Holzer hat gesagt: // Derek Holzer wrote:
 
  [phasor~]   [r~ shape]
  [expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]
 
  Ah, but can you explain in non-technical English why this works?  
  Remember our reader base aren't mathematicians like Miller ;-)
 
 A past post by me describes a different algorithm (without skew) but it 
 shows the generation of a triangle from a phasor using a message analogy:
 http://lists.puredata.info/pipermail/pd-list/2006-11/044253.html
 which I find quite intuitive. 

Ups: Use that instead: 
http://lists.puredata.info/pipermail/pd-list/2006-11/044256.html

Ciao
-- 
Frank

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


Re: [PD] Background Colour...

2009-03-30 Thread Max

hi simon,

since your previos posts are about Gem i recon you are talking about  
the gem window.
please refer to the help patch for [gemwin], then see the subpatch [pd  
lighting and fog] since color perception is needs lighting i guess it  
somehow makes sense to look for it there.


you will find there that by simply sending a [color 0 1 1( message to  
gemwin you can set the background color of it.


hope tht helps.



Am 30.03.2009 um 16:43 schrieb Simon Ball:


Hi there, simple question...

How do I change the background colour of the window?

I'm still learning, obviously.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list




PGP.sig
Description: Signierter Teil der Nachricht
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pd book sprint

2009-03-30 Thread Alexandre Porres
Hi D.

Yeah, DC Offset could be covered in what is digital Audio, or maybe briefly
mentioned. The thing is that it needs patches to explain and show how
adjusting the DC Offset works.
I know things must be kept as simple as possible, but not simpler than that,
because it could be misleading. I had that problem myself when teaching with
Floss Manuals, students had doubts why the square and sawtooth oscilators
were different, or wrong.

The DC Offset is an extremely important parameter that should be a part of
the synthesizer section of Floss Manuals. It could also be a part of the
Amplitude Modulation Examples. Actually, changing DC Offset is all it needs
to change from an Amplitude Modulation to a Ring Modulation. So having a DC
Offset parameter there can explain the differences between the two.

For instance, I find the osc7.pd example really misleading. At first, it is
supposed to be a Ring Modulation instead of an Amplitude Modulation, since
there is no DC offset in the modulator sigal. But, as the sawtooth wave
oscilator has a DC Offset (that shouldnt be tghere anyway, and it is not
even mentioned), it is actually an Amplitude modulation after all, with the
Remark that the Carrier signal has the role of the Modulator signal, and Not
the carrier signal itself. So, in any way (either presenting it as a Ring
Modulation or Amplitude Modulation) corrections should be made.

So I dont see a way of not editing these patches, because it could be even
more confusing if we would write a disconected chapter that complements and
gives the tools to correct things that could have been presented before.

I just don't see how simplicity here compensates the misleading way the
theory is presented.

The DC Offset is the main problem I see in Floss Manuals. And I actually
give my students an altered version of Floss Manuals to work with because of
that. I am developing a book of my own that complements well with the Floss
Manuals, but I still need to do make this Remark.

I could show my book, but it is in Portuguese only, so far...

by the way, we have people in Brazil who would like to collaborate and
translate this to portuguese.

I can send you a triangle wave oscilator right away.

cheers
alex


On Mon, Mar 30, 2009 at 11:56 AM, Derek Holzer de...@umatic.nl wrote:

 Actually, DC offset could be covered in What is Digital Audio, since it
 is a concept that needs explaining. Then, my suggestion still is to include
 it after the basics of the Square Waves. I'd like to keep the patches there
 as simple as possible, and since the DC Offset can be done at the end, why
 not have it there?

 Triangle wave would also be good. Write it first and we'll see where
 exactly to put it.

 D.


 Alexandre Porres wrote:

 sure, I could do both.

 But I think it would be inportant to start just after

* AUDIO TUTORIALS
* SimpleSynthIntroduction
  http://en.flossmanuals.net/PureData/SimpleSynthIntroduction


 and before the oscilators with the Short DC offset chapter.

 Then edit and correct the oscilator patches with values from -1 to 1

 I also can create and put in the oscilator chapter a Triangle wave
 oscilator made with phasor

 what do you say?

 Cheers


 On Mon, Mar 30, 2009 at 11:43 AM, Derek Holzer de...@umatic.nl mailto:
 de...@umatic.nl wrote:

Alexandre,

Yes please, get on board!

In the case of the square wave chapter, I had assumed that doing it
with digital logic would result in either 0 (no amplitude) or 1
(full amplitude). So there shouldn't be any DC offset when it's at
0. Of course, there are some other real-world problems with those
patches, namely that there is also no antialiasing.

Since the FLOSS Manuals are modular, they can be remixed as needed
for any kind of workshop, class or curriculum, including or leaving
out sections from all the different FLOSS Manuals as needed.

So my suggestion to you would be to write a short chapter on DC
offset which can then be referred to in the square wave tutorial, or
in any other tutorial or manual where such a situation might arise.

Likewise, I'd love it if someone could do a single chapter on the
different antialiasing methods (Miller's, Frank's...). The idea
would be to simplify the explanations so that one doesn't need a
background in DSP or computer science in order to understand them.

Would you be interested to do either of those?

D.

Alexandre Porres wrote:

Hi, I am really interested in helping!

I actually have some stuff I wanted to corrrect, or bring some
attention to, like the DC OFFSET. You dont cover it, and when
you show how to get a Square Wave, the DC Offset is not properly
adjusted.

thanks

cheers

On Mon, Mar 30, 2009 at 11:20 AM, Derek Holzer de...@umatic.nl
mailto:de...@umatic.nl mailto:de...@umatic.nl

mailto:de...@umatic.nl wrote:

   Hey Alexandre,

   I just 

Re: [PD] Chicago Patching Circle (Sunday, March 29th 5pm)

2009-03-30 Thread Ben Baker-Smith
Thanks to Mike for organizing the Chicago meeting yesterday, and to
Kyle for also showing up.

It was good to connect with some other PD users here, and totally
interesting to see what you've been working on / have worked on.  Even
(or especially) when it was over my head.

I'd like to do it again some time, assuming that you both haven't
gotten completely jaded and stopped using PD completely ;)
I'll be sure to bring some of my own material.

-Ben

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


Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer
Could you post the adjusted patches, I'd like to see where your 
corrections are before I agree to change stuff that is already there.


best!
D.

Alexandre Porres wrote:

Hi D.

Yeah, DC Offset could be covered in what is digital Audio, or maybe 
briefly mentioned. The thing is that it needs patches to explain and 
show how adjusting the DC Offset works.


I know things must be kept as simple as possible, but not simpler than 
that, because it could be misleading. I had that problem myself when 
teaching with Floss Manuals, students had doubts why the square and 
sawtooth oscilators were different, or wrong.


The DC Offset is an extremely important parameter that should be a part 
of the synthesizer section of Floss Manuals. It could also be a part of 
the Amplitude Modulation Examples. Actually, changing DC Offset is all 
it needs to change from an Amplitude Modulation to a Ring Modulation. So 
having a DC Offset parameter there can explain the differences between 
the two.


For instance, I find the osc7.pd example really misleading. At first, it 
is supposed to be a Ring Modulation instead of an Amplitude Modulation, 
since there is no DC offset in the modulator sigal. But, as the sawtooth 
wave oscilator has a DC Offset (that shouldnt be tghere anyway, and it 
is not even mentioned), it is actually an Amplitude modulation after 
all, with the Remark that the Carrier signal has the role of the 
Modulator signal, and Not the carrier signal itself. So, in any way 
(either presenting it as a Ring Modulation or Amplitude Modulation) 
corrections should be made.


So I dont see a way of not editing these patches, because it could be 
even more confusing if we would write a disconected chapter that 
complements and gives the tools to correct things that could have been 
presented before.


I just don't see how simplicity here compensates the misleading way the 
theory is presented.


The DC Offset is the main problem I see in Floss Manuals. And I actually 
give my students an altered version of Floss Manuals to work with 
because of that. I am developing a book of my own that complements well 
with the Floss Manuals, but I still need to do make this Remark.


I could show my book, but it is in Portuguese only, so far... 

by the way, we have people in Brazil who would like to collaborate and 
translate this to portuguese.


I can send you a triangle wave oscilator right away.

cheers
alex


On Mon, Mar 30, 2009 at 11:56 AM, Derek Holzer de...@umatic.nl 
mailto:de...@umatic.nl wrote:


Actually, DC offset could be covered in What is Digital Audio,
since it is a concept that needs explaining. Then, my suggestion
still is to include it after the basics of the Square Waves. I'd
like to keep the patches there as simple as possible, and since the
DC Offset can be done at the end, why not have it there?

Triangle wave would also be good. Write it first and we'll see where
exactly to put it.

D.


Alexandre Porres wrote:

sure, I could do both.

But I think it would be inportant to start just after
 
   * AUDIO TUTORIALS

   * SimpleSynthIntroduction
 http://en.flossmanuals.net/PureData/SimpleSynthIntroduction



and before the oscilators with the Short DC offset chapter.

Then edit and correct the oscilator patches with values from -1 to 1

I also can create and put in the oscilator chapter a Triangle
wave oscilator made with phasor

what do you say?

Cheers


On Mon, Mar 30, 2009 at 11:43 AM, Derek Holzer de...@umatic.nl
mailto:de...@umatic.nl mailto:de...@umatic.nl
mailto:de...@umatic.nl wrote:

   Alexandre,

   Yes please, get on board!

   In the case of the square wave chapter, I had assumed that
doing it
   with digital logic would result in either 0 (no amplitude) or 1
   (full amplitude). So there shouldn't be any DC offset when
it's at
   0. Of course, there are some other real-world problems with those
   patches, namely that there is also no antialiasing.

   Since the FLOSS Manuals are modular, they can be remixed as
needed
   for any kind of workshop, class or curriculum, including or
leaving
   out sections from all the different FLOSS Manuals as needed.

   So my suggestion to you would be to write a short chapter on DC
   offset which can then be referred to in the square wave
tutorial, or
   in any other tutorial or manual where such a situation might
arise.

   Likewise, I'd love it if someone could do a single chapter on the
   different antialiasing methods (Miller's, Frank's...). The idea
   would be to simplify the explanations so that one doesn't need a
   background in DSP or computer science in order to understand
them.

   Would you 

Re: [PD] pd book sprint

2009-03-30 Thread Alexandre Porres
On Mon, Mar 30, 2009 at 12:02 PM, Claude Heiland-Allen 
claudiusmaxi...@goto10.org wrote:


 [phasor~]   [r~ shape]
 [expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]


I tried that, but it didnt actually worked, I just get actual sawtooths, and
no real triangles.


here is what I got.


[phasor~]

[expr~ (min($v1, 1 - $v1) * 4) -1]


this is explained step by step with boxes and commentaries for the non
matematicians (like me).


I tried to send the patch as text to this message, hope it works.


-



#N canvas 233 52 823 501 10;

#X obj 385 316 phasor~ 200;

#X obj 125 92 *~ -1;

#X obj 125 114 +~ 1;

#X obj 104 159 min~;

#X obj 385 337 expr~ (min($v1 \, 1 - $v1) * 4) - 1;

#X obj 145 333 tgl 15 0 empty empty empty 0 -6 0 10 -262144 -1 -1 0

1;

#X obj 130 352 *~;

#X obj 114 59 phasor~ 220;

#X obj 104 264 *~ 4;

#X obj 104 301 -~ 1;

#X obj 130 373 dac~;

#X text 163 102 Inverts to Ramp Down generator (1 - 0);

#X text 202 59 Ramp Generator (0 - 1);

#X text 139 159 compares ramp up and ramp down and passes the smaller

value.;

#X text 123 205 This creates a Triangle wave with DC offset and gain

from (0 - 0.5). Now we need to adjust the gaind and DC ofsset;

#X text 379 290 Expr Version;

#X text 136 264 Normalize values to (0 -2);

#X text 141 303 corrects DC Offset;

#X obj 409 383 tgl 15 0 empty empty empty 0 -6 0 10 -262144 -1 -1 0

1;

#X obj 394 402 *~;

#X obj 394 423 dac~;

#X connect 0 0 4 0;

#X connect 1 0 2 0;

#X connect 2 0 3 1;

#X connect 3 0 8 0;

#X connect 4 0 19 0;

#X connect 5 0 6 1;

#X connect 6 0 10 0;

#X connect 7 0 1 0;

#X connect 7 0 3 0;

#X connect 8 0 9 0;

#X connect 9 0 6 0;

#X connect 18 0 19 1;

#X connect 19 0 20 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Chicago Patching Circle (Sunday, March 29th 5pm)

2009-03-30 Thread Kyle Klipowicz
Yeah it was fun to share some meat-space with fellow geeks.
We'll have to plan another one soon, and try to promote it a bit more.

~Kyle

On Mon, Mar 30, 2009 at 10:18 AM, Ben Baker-Smith bbakersm...@gmail.comwrote:

 Thanks to Mike for organizing the Chicago meeting yesterday, and to
 Kyle for also showing up.

 It was good to connect with some other PD users here, and totally
 interesting to see what you've been working on / have worked on.  Even
 (or especially) when it was over my head.

 I'd like to do it again some time, assuming that you both haven't
 gotten completely jaded and stopped using PD completely ;)
 I'll be sure to bring some of my own material.

 -Ben




-- 
-

    -
  - --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] triangle

2009-03-30 Thread Alexandre Porres
did it go?


triangle.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pd book sprint

2009-03-30 Thread Alexandre Porres
I tried again, and now it works much better than before... so I guess there
was something wrong before.

Well Claude, it seems it almost works as the [triangle~] object.

Do you guys know about this one? It comes in some external library.

Were you who did it anyway Claude? :)

[triangle~] works in a similar fashion, it goes smoothly from inverse
sawtooth to triangle and the sawtooth depending on the parameter (from 0 to
1).

The thing is that Triangle corrects the DC Offset, which could easily be
done in the expr. But now I may start to sound like an obssessed DC Offset
maniac.

Cheers
Alex


On Mon, Mar 30, 2009 at 1:25 PM, Claude Heiland-Allen 
claudiusmaxi...@goto10.org wrote:

 Alexandre Porres wrote:

 On Mon, Mar 30, 2009 at 12:02 PM, Claude Heiland-Allen 
 claudiusmaxi...@goto10.org wrote:


 [phasor~]   [r~ shape]
 [expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]


  I tried that, but it didnt actually worked, I just get actual sawtooths,
 and
 no real triangles.


 Sorry for the shortness/lack of explanation, 0shape1, where 1 for phasor,
 0.5 for triangle, 0 for backwards phasor.

 considering shape as a constant, obviously you get weird results if you
 modulate it, but that's half the fun:

 0.0   = input = shape  ~  0.0 = output = 1.0  (rising ramp)
 shape = input = 1.0~  1.0 = output = 0.0  (falling ramp)

 Hope this helps,



 Claude
 --
 http://claudiusmaximus.goto10.org




-- 
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pure Data FLOSS Manual Book Sprint 4-6 April 2009 in NYC and Berlin

2009-03-30 Thread João Pais

Hi,

I can go as well. Don't know yet exactly how much time, but should be able  
to be there each day. Some details:


- is the information below about guidelines / chapters in a wiki  
somewhere? should it be? It might be better to people to organise  
themselves before the sprint starts. So that at the time of the sprint,  
the only thing to do is to run.


- I can proof things, and give the newbie with not so much pacience for  
things that don't work point of view - specially for ubuntu


- I can bring some documentation, in case necessary: Roads' Tutorial,  
Csound book, microsound, ... (didn't look at the floss pages yet, don't  
know if that's important)


- I can do some portuguese desserts

- I'm not bad at proofing things and making them more presentable, I  
guess. at least I don't dislike it.


- and whatever

João


FLOSS Manuals is proud to announce a three day book sprint for the Pure  
Data FLOSS Manual. This sprint will take place simultaneously in New  
York City and Berlin from Saturday 4 April to Monday 6 April.


The Pure Data FLOSS Manual:

http://en.flossmanuals.net/puredata

There are possibilities to participate in person by coming to one of the  
locations below, or remotely via the IRC interface built into the FLOSS  
Manuals editing interface. Video conferencing may take place between the  
venues as well.


To participate, create a login at the PD FLOSS Manuals page:

http://en.flossmanuals.net/bin/login/TWiki/WebHome?origurl=/bin/view/PureData/Introductionskin=floss2

Discussion may also take place in the Pure Data mailing list:

http://lists.puredata.info/listinfo/pd-list

If you are in New York or Berlin, please join us at these locations!

---NEW YORK CITY

* Contact:

Hans-Christoph Steiner: h...@eds.org 718 360 4872

* Location (bring ID, you'll need to sign in):

ITP/NYU Conference Room
721 Broadway, 4th Floor
NY, NY, USA
email me or call in case you can get past security: 718 360 4872

* Schedule:
Saturday: noon-midnight
Sunday: 10am-midnight
Monday: 9am-5:30pm  (if we go later, we'll be in a different room)

---BERLIN

* Contacts

Derek Holzer: de...@umatic.nl +49 176 2812 5845
Adam Hyde: a...@flossmanuals.net +49 15 2230 54563

NK
ElsenStr. 52 (2.Hof)
Berlin, Germany
+49 176 20626386
http://www.myspace.com/enka52

* Schedule:
Saturday: noon-late
Sunday: noon-late
Monday: noon-late


SOME BASIC GUIDELINES:

* This manual should address the widest possible user-base. Therefore,  
objects which are cross-platform and in Pd Extended should have priority  
over other solutions.
* Tone should be neutral and informative. Remember that humor doesn't  
always translate well! ;-)
* Our readers are assumed to have little to no background in either  
computer programming or digital signal processing, which much of the  
existing documentation takes for granted. That's why this manual is  
necessary! Please keep this in mind when explaining things.
* Please use existing the Audio Tutorials, Installing and Getting  
Started chapters as a style guide.
* Keep the chapters small and self-contained. Ideally, chapters from  
this manual could even be remixed into other FLOSS Manuals.
* Explain any jargon or technical terminology in-line the first time you  
use it, and direct the reader to appropriate other chapters/manuals when  
necessary.
* Please enter any new technical terms in the Glossary (we need to agree  
on global format for glossary terms!).

* Screenshots:
---Resolution? (Adam and I will work on this on Monday)
---Please upload any complex patches, and make sure to label screenshot  
with appropriate filename (see Audio Tutorials for examples)
---Please keep explanatory text in the manual rather than only in the  
screenshot, so that it can be text-searched by readers.

---Please use anti-aliased fonts!
* All the chapters are moderated by Derek Holzer  Adam Hyde. Your  
contributions will only be visible in the editing section until they  
meet these guidelines, and after that they can be published to the main  
page. Please let us know when your chapter(s) are ready for publishing  
and we'll look them over.



EXISTING CHAPTERS WHICH NEED HELP:

# DataflowTutorials

---this section needs a lot of help in terms of style and content!  
Tone is very informal, which doesn't help convey the information.
---give titles to screenshots so that readers can tell which patches  
match which images (some do this, some don't...)

---Math: examples/discussion of [expr]???
---Order of connecting and [trigger]: explain the patches in-line,  
rather than only in comments in screenshots (so that text is searchable,  
copy/pasteable..)
---Luka's screencaps are very aliased, to the point where you can't read  
the ~ in the object names. Should they be redone at new resolution or  
with antialiasing?

---Possible janitors: Derek Holzer, Adam Hyde

# PureGlossary

---format of object names = [italics in square brackets], must be  
formatted correctly
---format of glossary words in 

Re: [PD] GEM pix_write bugs (timelapse)

2009-03-30 Thread mark edward grimm

hey thats pretty nice!!

much nicer than my poor gem attempt last month...

 and the patch:
 put this to / because of the bug in pix_write to make it
 work. put a folder called frames beside it.

yeah this is weird huh?

  


--- On Sat, 3/28/09, Max abonneme...@revolwear.com wrote:

 From: Max abonneme...@revolwear.com
 Subject: [PD] GEM pix_write bugs (timelapse)
 To: pd-list@iem.at
 Date: Saturday, March 28, 2009, 12:52 PM
 hi list,
 
 i've thrown together this tiny gem patch which makes a
 timelapse slideshow.
 i have encountered a few issues with it.
 
 configuration:
 Pd version 0.41.4-extended-20090223
 GEM: ver: 0.91.3 'tigital'
 GEM: compiled: Feb 23 2009
 OS X 10.5.6
 
 the issues:
 1. pix_write doesn't interpret the file path correctly. it
 seems it can't understand relative paths at all.
 
 2. pix_write accepts a message [file file
 [type](. it creates files with a .jpg ending if the
 type is 0. But in reality it still is a TIFF. no matter
 what value you write.
 
 3. pix_write creates files with an acending number 0...
 this conflicts with how other objects like pix_multiimage do
 it (0...9)
 
 just submitted that to the gem bugtracker.
 
 
 and the patch:
 put this to / because of the bug in pix_write to make it
 work. put a folder called frames beside it.
 
 
 
 
 
 
 beware: this patch will also eat up all the memory and will
 crash pd. this isn't pix_writes problem though - i'll try to
 find out why this is now.
 
 max
 -Inline Attachment Follows-
 
 ___
 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] pd book sprint

2009-03-30 Thread Frank Barknecht
Hallo,
Alexandre Porres hat gesagt: // Alexandre Porres wrote:

 I tried again, and now it works much better than before... so I guess there
 was something wrong before.
 
 Well Claude, it seems it almost works as the [triangle~] object.
 
 Do you guys know about this one? It comes in some external library.

Hm, it's pretty common name for a triangle-wave abstraction. We also have one
included in s_osc.pd which is the standard multiwaveform oscillator for synth
building in rjlib and does sine, tri, pwm-square and saw (the latter two
bandlimited). 

 [triangle~] works in a similar fashion, it goes smoothly from inverse
 sawtooth to triangle and the sawtooth depending on the parameter (from 0 to
 1).
 
 The thing is that Triangle corrects the DC Offset, which could easily be
 done in the expr. But now I may start to sound like an obssessed DC Offset
 maniac.

While the oscillators in s_osc.pd all go from -1 to 1, I don't really see why a
triangle wave should not go from 0-1 as well. This may even be useful in
certain applications. All it takes to convert it is a multiply-add. And isn't
differentiating between ring modulation and amplitude modulation according to
where the DC is old school analog thinking? ;) In Pd I prefer to think just
about multiplications of one signal with another one.

Ciao
-- 
Frank

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


Re: [PD] [OT] Re: DIY GSoC: getting those projects done

2009-03-30 Thread Claude Heiland-Allen

Mathieu Bouchard wrote:
At first thought I think 
I'm in favour of reconfigurable inlets, but I'd like to see a 
proof-of-concept first.


IIRC the [lexpr] pdlua example has reconfigurable hot/cold inlets, but 
that's implemented by hand.


Not sure I like the idea of a run method, what if there's more than 
one reasonable run action?



Claude
--
http://claudiusmaximus.goto10.org

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


Re: [PD] Pure Data FLOSS Manual Book Sprint 4-6 April 2009 in NYC and Berlin

2009-03-30 Thread marius schebella

Hi,

I'd like to participate remotely somehow. I understand that you also 
want to cover Gem(?), so I'd like to propose a chapter on video 
tracking. motion tracking, background subtraction, showing how to do 
alpha masking, color tracking, I also would like to include some 
documentation of pix_opencv, unless someone else is already doing that, 
for example face tracking, but also other possibilities of opencv 
(pattern recognition).
I also think the TUIO stuff should go there (with references to touchlib 
or touché), and multiblob.


AFAIK there is no gem section yet, so I don't know if it is possible to 
do just one chapter without a general introduction to gem??


Btw, there are tons of other topics to cover...

marius.


Derek Holzer wrote:
FLOSS Manuals is proud to announce a three day book sprint for the Pure 
Data FLOSS Manual. This sprint will take place simultaneously in New 
York City and Berlin from Saturday 4 April to Monday 6 April.


The Pure Data FLOSS Manual:

http://en.flossmanuals.net/puredata

There are possibilities to participate in person by coming to one of the 
locations below, or remotely via the IRC interface built into the FLOSS 
Manuals editing interface. Video conferencing may take place between the 
venues as well.


To participate, create a login at the PD FLOSS Manuals page:

http://en.flossmanuals.net/bin/login/TWiki/WebHome?origurl=/bin/view/PureData/Introductionskin=floss2 



Discussion may also take place in the Pure Data mailing list:

http://lists.puredata.info/listinfo/pd-list

If you are in New York or Berlin, please join us at these locations!

---NEW YORK CITY

* Contact:

Hans-Christoph Steiner: h...@eds.org 718 360 4872

* Location (bring ID, you'll need to sign in):

ITP/NYU Conference Room
721 Broadway, 4th Floor
NY, NY, USA
email me or call in case you can get past security: 718 360 4872

* Schedule:
Saturday: noon-midnight
Sunday: 10am-midnight
Monday: 9am-5:30pm  (if we go later, we'll be in a different room)

---BERLIN

* Contacts

Derek Holzer: de...@umatic.nl +49 176 2812 5845
Adam Hyde: a...@flossmanuals.net +49 15 2230 54563

NK
ElsenStr. 52 (2.Hof)
Berlin, Germany
+49 176 20626386
http://www.myspace.com/enka52

* Schedule:
Saturday: noon-late
Sunday: noon-late
Monday: noon-late


SOME BASIC GUIDELINES:

* This manual should address the widest possible user-base. Therefore, 
objects which are cross-platform and in Pd Extended should have priority 
over other solutions.
* Tone should be neutral and informative. Remember that humor doesn't 
always translate well! ;-)
* Our readers are assumed to have little to no background in either 
computer programming or digital signal processing, which much of the 
existing documentation takes for granted. That's why this manual is 
necessary! Please keep this in mind when explaining things.
* Please use existing the Audio Tutorials, Installing and Getting 
Started chapters as a style guide.
* Keep the chapters small and self-contained. Ideally, chapters from 
this manual could even be remixed into other FLOSS Manuals.
* Explain any jargon or technical terminology in-line the first time you 
use it, and direct the reader to appropriate other chapters/manuals when 
necessary.
* Please enter any new technical terms in the Glossary (we need to agree 
on global format for glossary terms!).

* Screenshots:
---Resolution? (Adam and I will work on this on Monday)
---Please upload any complex patches, and make sure to label screenshot 
with appropriate filename (see Audio Tutorials for examples)
---Please keep explanatory text in the manual rather than only in the 
screenshot, so that it can be text-searched by readers.

---Please use anti-aliased fonts!
* All the chapters are moderated by Derek Holzer  Adam Hyde. Your 
contributions will only be visible in the editing section until they 
meet these guidelines, and after that they can be published to the main 
page. Please let us know when your chapter(s) are ready for publishing 
and we'll look them over.



EXISTING CHAPTERS WHICH NEED HELP:

# DataflowTutorials

---this section needs a lot of help in terms of style and content! 
Tone is very informal, which doesn't help convey the information.
---give titles to screenshots so that readers can tell which patches 
match which images (some do this, some don't...)

---Math: examples/discussion of [expr]???
---Order of connecting and [trigger]: explain the patches in-line, 
rather than only in comments in screenshots (so that text is searchable, 
copy/pasteable..)
---Luka's screencaps are very aliased, to the point where you can't read 
the ~ in the object names. Should they be redone at new resolution or 
with antialiasing?

---Possible janitors: Derek Holzer, Adam Hyde

# PureGlossary

---format of object names = [italics in square brackets], must be 
formatted correctly
---format of glossary words in general text: we don't have one yet. Bold 
on first use in chapter maybe? Needs formatting all through text.


# 

Re: [PD] Pure Data FLOSS Manual Book Sprint 4-6 April 2009 in NYC and Berlin

2009-03-30 Thread Derek Holzer

Hey Marius,

yes we will need an introduction to GEM. My priorities are to do simple 
stuff first. I know that might be boring, and the temptation is to run 
ahead to the more interesting stuff, but really the basics need to be 
there before anything fancy. And in a simple, introductory form. I'm 
even temped to give an arbitrary limit of no more than 10 objects/atoms 
per example ;-)


So I'd prefer to get you moving on some basics. There are a collection 
of patches that Chris Clepper sent as well as ones which I have used in 
my workshops for years that could be written up. Only after these are 
finished can we move on to project specific stuff like motion tracking.


best!
Derek

marius schebella wrote:

Hi,

I'd like to participate remotely somehow. I understand that you also 
want to cover Gem(?), so I'd like to propose a chapter on video 
tracking. motion tracking, background subtraction, showing how to do 
alpha masking, color tracking, I also would like to include some 
documentation of pix_opencv, unless someone else is already doing that, 
for example face tracking, but also other possibilities of opencv 
(pattern recognition).
I also think the TUIO stuff should go there (with references to touchlib 
or touché), and multiblob.


AFAIK there is no gem section yet, so I don't know if it is possible to 
do just one chapter without a general introduction to gem??


Btw, there are tons of other topics to cover...

marius.


Derek Holzer wrote:
FLOSS Manuals is proud to announce a three day book sprint for the 
Pure Data FLOSS Manual. This sprint will take place simultaneously in 
New York City and Berlin from Saturday 4 April to Monday 6 April.


The Pure Data FLOSS Manual:

http://en.flossmanuals.net/puredata

There are possibilities to participate in person by coming to one of 
the locations below, or remotely via the IRC interface built into the 
FLOSS Manuals editing interface. Video conferencing may take place 
between the venues as well.


To participate, create a login at the PD FLOSS Manuals page:

http://en.flossmanuals.net/bin/login/TWiki/WebHome?origurl=/bin/view/PureData/Introductionskin=floss2 



Discussion may also take place in the Pure Data mailing list:

http://lists.puredata.info/listinfo/pd-list

If you are in New York or Berlin, please join us at these locations!

---NEW YORK CITY

* Contact:

Hans-Christoph Steiner: h...@eds.org 718 360 4872

* Location (bring ID, you'll need to sign in):

ITP/NYU Conference Room
721 Broadway, 4th Floor
NY, NY, USA
email me or call in case you can get past security: 718 360 4872

* Schedule:
Saturday: noon-midnight
Sunday: 10am-midnight
Monday: 9am-5:30pm  (if we go later, we'll be in a different room)

---BERLIN

* Contacts

Derek Holzer: de...@umatic.nl +49 176 2812 5845
Adam Hyde: a...@flossmanuals.net +49 15 2230 54563

NK
ElsenStr. 52 (2.Hof)
Berlin, Germany
+49 176 20626386
http://www.myspace.com/enka52

* Schedule:
Saturday: noon-late
Sunday: noon-late
Monday: noon-late


SOME BASIC GUIDELINES:

* This manual should address the widest possible user-base. Therefore, 
objects which are cross-platform and in Pd Extended should have 
priority over other solutions.
* Tone should be neutral and informative. Remember that humor doesn't 
always translate well! ;-)
* Our readers are assumed to have little to no background in either 
computer programming or digital signal processing, which much of the 
existing documentation takes for granted. That's why this manual is 
necessary! Please keep this in mind when explaining things.
* Please use existing the Audio Tutorials, Installing and Getting 
Started chapters as a style guide.
* Keep the chapters small and self-contained. Ideally, chapters from 
this manual could even be remixed into other FLOSS Manuals.
* Explain any jargon or technical terminology in-line the first time 
you use it, and direct the reader to appropriate other 
chapters/manuals when necessary.
* Please enter any new technical terms in the Glossary (we need to 
agree on global format for glossary terms!).

* Screenshots:
---Resolution? (Adam and I will work on this on Monday)
---Please upload any complex patches, and make sure to label 
screenshot with appropriate filename (see Audio Tutorials for examples)
---Please keep explanatory text in the manual rather than only in the 
screenshot, so that it can be text-searched by readers.

---Please use anti-aliased fonts!
* All the chapters are moderated by Derek Holzer  Adam Hyde. Your 
contributions will only be visible in the editing section until they 
meet these guidelines, and after that they can be published to the 
main page. Please let us know when your chapter(s) are ready for 
publishing and we'll look them over.



EXISTING CHAPTERS WHICH NEED HELP:

# DataflowTutorials

---this section needs a lot of help in terms of style and content! 
Tone is very informal, which doesn't help convey the information.
---give titles to screenshots so that readers can tell which 

Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer
Is it really DC offset when the value goes from 0 to 1 instead of -1 to 
1? I mean, that's the way [phasor~] comes right out of the box.


D.

Alexandre Porres wrote:


I tried again, and now it works much better than before... so I guess 
there was something wrong before.


Well Claude, it seems it almost works as the [triangle~] object.

Do you guys know about this one? It comes in some external library.

Were you who did it anyway Claude? :)

[triangle~] works in a similar fashion, it goes smoothly from inverse 
sawtooth to triangle and the sawtooth depending on the parameter (from 0 
to 1).


The thing is that Triangle corrects the DC Offset, which could easily be 
done in the expr. But now I may start to sound like an obssessed DC 
Offset maniac.


Cheers
Alex


On Mon, Mar 30, 2009 at 1:25 PM, Claude Heiland-Allen 
claudiusmaxi...@goto10.org mailto:claudiusmaxi...@goto10.org wrote:


Alexandre Porres wrote:

On Mon, Mar 30, 2009 at 12:02 PM, Claude Heiland-Allen 
claudiusmaxi...@goto10.org mailto:claudiusmaxi...@goto10.org
wrote:


[phasor~]   [r~ shape]
[expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]


I tried that, but it didnt actually worked, I just get actual
sawtooths, and
no real triangles.


Sorry for the shortness/lack of explanation, 0shape1, where 1 for
phasor, 0.5 for triangle, 0 for backwards phasor.

considering shape as a constant, obviously you get weird results if
you modulate it, but that's half the fun:

0.0   = input = shape  ~  0.0 = output = 1.0  (rising ramp)
shape = input = 1.0~  1.0 = output = 0.0  (falling ramp)

Hope this helps,



Claude
-- 
http://claudiusmaximus.goto10.org





--
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres



--
::: derek holzer ::: http://blog.myspace.com/macumbista ::: 
http://www.vimeo.com/macumbista :::

---Oblique Strategy # 35:
Consider transitions

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


Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer
I have to agree with Frank on this one. Luckily, unless we are 
completely pedantic engineer types, we can all be correct! ;-)

D.

Frank Barknecht wrote:


While the oscillators in s_osc.pd all go from -1 to 1, I don't really see why a
triangle wave should not go from 0-1 as well. This may even be useful in
certain applications. All it takes to convert it is a multiply-add. And isn't
differentiating between ring modulation and amplitude modulation according to
where the DC is old school analog thinking? ;) In Pd I prefer to think just
about multiplications of one signal with another one.



--
::: derek holzer ::: http://blog.myspace.com/macumbista ::: 
http://www.vimeo.com/macumbista :::

---Oblique Strategy # 202:
Back up a few steps.
What else could you have done?

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


Re: [PD] pd book sprint

2009-03-30 Thread Alexandre Porres
you know, yeah, but the thing is that phasor is not actually an oscilator at
all !!!
the name actually refers to phase, and not sawtooth.

Apart from [osc~], oscilators in puredata are basically wavetable
oscilators. You have objects such as [tabosc4~] and that is it.

What [phasor~] was designed to do is to indicate the phase of the waveform
on a table. So you have to adjust phsor to be compatible with the table
size. You do that simply by multiplying phasor (wich ramps up to one) to the
table size. So what it is meant to do is tell the position (or phase) in a
table. That is why it goes from 0 to 1. If it did go from -1 to 1, as an
ocilator, then it wouldnt work that way.

So there is a misconception of [phasor~] being a sawtooth wave generator
that can be misleading. As an oscilator, [phasor~] has a DC Offset. In order
to [phasor~] became an oscilator with no DC Offset, we have to correct it.

Maybe it is nice to be explicit about it in Floss Manuals, and say that Pd
mostly works out with Table lookup oscilators, and that [osc~] is a special
and unique object that is meant to be a Cosine wave oscilator.

Then, when explaining how to get other kinds of wavefroms on Pd, such as
sawtooth, square, triangle, we could emphasize that we are creating them,
and building them up with the objects we have. Thast also makes it implicit
that there is more than one way to di it, and that there is no official or
built in Square wave, for instance.

I actually talk a lot about that on my book. And I present examples on how
to get a triangle waveform on a table using the sinesum comand, that is, by
summing up harmonics.

Cheers
Alex

On Mon, Mar 30, 2009 at 3:02 PM, Derek Holzer de...@umatic.nl wrote:

 Is it really DC offset when the value goes from 0 to 1 instead of -1 to 1?
 I mean, that's the way [phasor~] comes right out of the box.

 D.

 Alexandre Porres wrote:


 I tried again, and now it works much better than before... so I guess
 there was something wrong before.

 Well Claude, it seems it almost works as the [triangle~] object.

 Do you guys know about this one? It comes in some external library.

 Were you who did it anyway Claude? :)

 [triangle~] works in a similar fashion, it goes smoothly from inverse
 sawtooth to triangle and the sawtooth depending on the parameter (from 0 to
 1).

 The thing is that Triangle corrects the DC Offset, which could easily be
 done in the expr. But now I may start to sound like an obssessed DC Offset
 maniac.

 Cheers
 Alex


 On Mon, Mar 30, 2009 at 1:25 PM, Claude Heiland-Allen 
 claudiusmaxi...@goto10.org mailto:claudiusmaxi...@goto10.org wrote:

Alexandre Porres wrote:

On Mon, Mar 30, 2009 at 12:02 PM, Claude Heiland-Allen 
claudiusmaxi...@goto10.org mailto:claudiusmaxi...@goto10.org
wrote:


[phasor~]   [r~ shape]
[expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]


I tried that, but it didnt actually worked, I just get actual
sawtooths, and
no real triangles.


Sorry for the shortness/lack of explanation, 0shape1, where 1 for
phasor, 0.5 for triangle, 0 for backwards phasor.

considering shape as a constant, obviously you get weird results if
you modulate it, but that's half the fun:

0.0   = input = shape  ~  0.0 = output = 1.0  (rising ramp)
shape = input = 1.0~  1.0 = output = 0.0  (falling ramp)

Hope this helps,



Claude
--http://claudiusmaximus.goto10.org




 --
 Alexandre Torres Porres
 cel. (11)8179-6226
 Website: http://porres.googlepages.com/home
 http://www.myspace.com/alexandretorresporres


 --
 ::: derek holzer ::: http://blog.myspace.com/macumbista :::
 http://www.vimeo.com/macumbista :::
 ---Oblique Strategy # 35:
 Consider transitions




-- 
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] dc offset

2009-03-30 Thread Alexandre Porres
 Is it really DC offset when the value goes from 0 to 1 instead of -1 to 1?

just to be clear and straightforward.

when the midpoint is not zero, there is a DC Offset, which means you
introduce energy in the spectrum at 0Hz, so the maximum positive value must
be equal to the absolute negative value (-0.5 to 05 ,  -0.25 to 0.25, etc).
In the case the way phasor comes out of the box, midpoint is 0.5, and not
zero...

cheers
alex


On Mon, Mar 30, 2009 at 3:02 PM, Derek Holzer de...@umatic.nl wrote:

 Is it really DC offset when the value goes from 0 to 1 instead of -1 to 1?
 I mean, that's the way [phasor~] comes right out of the box.

 D.

 Alexandre Porres wrote:


 I tried again, and now it works much better than before... so I guess
 there was something wrong before.

 Well Claude, it seems it almost works as the [triangle~] object.

 Do you guys know about this one? It comes in some external library.

 Were you who did it anyway Claude? :)

 [triangle~] works in a similar fashion, it goes smoothly from inverse
 sawtooth to triangle and the sawtooth depending on the parameter (from 0 to
 1).

 The thing is that Triangle corrects the DC Offset, which could easily be
 done in the expr. But now I may start to sound like an obssessed DC Offset
 maniac.

 Cheers
 Alex


 On Mon, Mar 30, 2009 at 1:25 PM, Claude Heiland-Allen 
 claudiusmaxi...@goto10.org mailto:claudiusmaxi...@goto10.org wrote:

Alexandre Porres wrote:

On Mon, Mar 30, 2009 at 12:02 PM, Claude Heiland-Allen 
claudiusmaxi...@goto10.org mailto:claudiusmaxi...@goto10.org
wrote:


[phasor~]   [r~ shape]
[expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]


I tried that, but it didnt actually worked, I just get actual
sawtooths, and
no real triangles.


Sorry for the shortness/lack of explanation, 0shape1, where 1 for
phasor, 0.5 for triangle, 0 for backwards phasor.

considering shape as a constant, obviously you get weird results if
you modulate it, but that's half the fun:

0.0   = input = shape  ~  0.0 = output = 1.0  (rising ramp)
shape = input = 1.0~  1.0 = output = 0.0  (falling ramp)

Hope this helps,



Claude
--http://claudiusmaximus.goto10.org




 --
 Alexandre Torres Porres
 cel. (11)8179-6226
 Website: http://porres.googlepages.com/home
 http://www.myspace.com/alexandretorresporres


 --
 ::: derek holzer ::: http://blog.myspace.com/macumbista :::
 http://www.vimeo.com/macumbista :::
 ---Oblique Strategy # 35:
 Consider transitions




-- 
Alexandre Torres Porres
cel. (11)8179-6226
Website: http://porres.googlepages.com/home
http://www.myspace.com/alexandretorresporres
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer
I agree with the principles of this approach, but perhaps not the 
complexity. The FLOSS Manual doesn't exist as a way to teach DSP. That's 
what Miller's stuff is for. It exists as a way to get people who are put 
off by the existing documentation, which is very very heavy in math, DSP 
and computer science. These are the people I get in my workshops every 
time. They just want to get an idea of how to do things and not be 
intimidated. Thus the emphasis on simple solutions rather than correct 
ones.


If people are ready for a deeper understanding of DSP, that's where 
Miller's book, and pd-tutorial.com and the Roads CMT book and all the 
rest come in. And perhaps your Portuguese one as well. I don't want this 
book to step into a niche which already has many options, I want it to 
fill a niche which is still wide open: Pd for absolute beginners, no 
prerequisites required.


D.

Alexandre Porres wrote:
you know, yeah, but the thing is that phasor is not actually an 
oscilator at all !!!


the name actually refers to phase, and not sawtooth.

Apart from [osc~], oscilators in puredata are basically wavetable 
oscilators. You have objects such as [tabosc4~] and that is it. 

What [phasor~] was designed to do is to indicate the phase of the 
waveform on a table. So you have to adjust phsor to be compatible with 
the table size. You do that simply by multiplying phasor (wich ramps up 
to one) to the table size. So what it is meant to do is tell the 
position (or phase) in a table. That is why it goes from 0 to 1. If it 
did go from -1 to 1, as an ocilator, then it wouldnt work that way.


So there is a misconception of [phasor~] being a sawtooth wave generator 
that can be misleading. As an oscilator, [phasor~] has a DC Offset. In 
order to [phasor~] became an oscilator with no DC Offset, we have to 
correct it.


Maybe it is nice to be explicit about it in Floss Manuals, and say that 
Pd mostly works out with Table lookup oscilators, and that [osc~] is a 
special and unique object that is meant to be a Cosine wave oscilator.


Then, when explaining how to get other kinds of wavefroms on Pd, such as 
sawtooth, square, triangle, we could emphasize that we are creating 
them, and building them up with the objects we have. Thast also makes it 
implicit that there is more than one way to di it, and that there is no 
official or built in Square wave, for instance.


I actually talk a lot about that on my book. And I present examples on 
how to get a triangle waveform on a table using the sinesum comand, that 
is, by summing up harmonics.


Cheers
Alex

On Mon, Mar 30, 2009 at 3:02 PM, Derek Holzer de...@umatic.nl 
mailto:de...@umatic.nl wrote:


Is it really DC offset when the value goes from 0 to 1 instead of -1
to 1? I mean, that's the way [phasor~] comes right out of the box.

D.

Alexandre Porres wrote:


I tried again, and now it works much better than before... so I
guess there was something wrong before.

Well Claude, it seems it almost works as the [triangle~] object.

Do you guys know about this one? It comes in some external library.

Were you who did it anyway Claude? :)

[triangle~] works in a similar fashion, it goes smoothly from
inverse sawtooth to triangle and the sawtooth depending on the
parameter (from 0 to 1).

The thing is that Triangle corrects the DC Offset, which could
easily be done in the expr. But now I may start to sound like an
obssessed DC Offset maniac.

Cheers
Alex


On Mon, Mar 30, 2009 at 1:25 PM, Claude Heiland-Allen
claudiusmaxi...@goto10.org mailto:claudiusmaxi...@goto10.org
mailto:claudiusmaxi...@goto10.org
mailto:claudiusmaxi...@goto10.org wrote:

   Alexandre Porres wrote:

   On Mon, Mar 30, 2009 at 12:02 PM, Claude Heiland-Allen 
   claudiusmaxi...@goto10.org
mailto:claudiusmaxi...@goto10.org
mailto:claudiusmaxi...@goto10.org
mailto:claudiusmaxi...@goto10.org

   wrote:


   [phasor~]   [r~ shape]
   [expr~ if($v1$v2,$v1/$v2,(1-$v1)/(1-$v2))]


   I tried that, but it didnt actually worked, I just get actual
   sawtooths, and
   no real triangles.


   Sorry for the shortness/lack of explanation, 0shape1, where
1 for
   phasor, 0.5 for triangle, 0 for backwards phasor.

   considering shape as a constant, obviously you get weird
results if
   you modulate it, but that's half the fun:

   0.0   = input = shape  ~  0.0 = output = 1.0  (rising ramp)
   shape = input = 1.0~  1.0 = output = 0.0  (falling ramp)

   Hope this helps,



   Claude
   --http://claudiusmaximus.goto10.org




-- 
Alexandre Torres Porres

cel. (11)8179-6226

Re: [PD] pd book sprint

2009-03-30 Thread Alexandre Porres
errata
 it wouldnt even be smart to repeat some stuff redundantly.


On Mon, Mar 30, 2009 at 3:41 PM, Alexandre Porres por...@gmail.com wrote:

 well, I totally agree with you, and that is why my stuff does not fill in
 the niche of Miller's and others at all.
 My stuff is for people who really had never seen anything like this, which
 is practically everybody in brazil :)

 I try to put some stuff in miller's book more accessible, but most of it I
 dont even bother to attempt that at all! Just the basics...

 The stuff is kinda in between Floss Manuals and Miller's book. But I dont
 wish to inject the things I wrote about inside Floss Manuals at all. it
 would even be smart to repeat some stuff redundantly.

 But the theory in DSP we are discussing here is really minimum, and the
 math could not be any simpler, which is just the procedure of using a [+]
 object, as complex as adjusting the gain with [*].

 Since it is that basic, I dont find it intimidating at all.

 But I really hope we could all share our thoughts and ideas, and create
 different materials that complement each other, and that are also coherent
 with each other.

 So sorry if I looked too technical, but I still believe it could be simply
 presented, and that the material could benefit from it.

 You see, DC Offset is also important to create Synthesis Control, like in
 the Amplitude Modulation example. If you want to do an AM synth with [osc],
 you need to adjust DC. But the procedure is really really simple. I will
 work on the examples and send it to you as soon as i can.

 thanks
 alex


 On Mon, Mar 30, 2009 at 3:29 PM, Derek Holzer de...@umatic.nl wrote:

 I agree with the principles of this approach, but perhaps not the
 complexity. The FLOSS Manual doesn't exist as a way to teach DSP. That's
 what Miller's stuff is for. It exists as a way to get people who are put off
 by the existing documentation, which is very very heavy in math, DSP and
 computer science. These are the people I get in my workshops every time.
 They just want to get an idea of how to do things and not be intimidated.
 Thus the emphasis on simple solutions rather than correct ones.

 If people are ready for a deeper understanding of DSP, that's where
 Miller's book, and pd-tutorial.com and the Roads CMT book and all the
 rest come in. And perhaps your Portuguese one as well. I don't want this
 book to step into a niche which already has many options, I want it to fill
 a niche which is still wide open: Pd for absolute beginners, no
 prerequisites required.

 D.

 Alexandre Porres wrote:

 you know, yeah, but the thing is that phasor is not actually an oscilator
 at all !!!

 the name actually refers to phase, and not sawtooth.

 Apart from [osc~], oscilators in puredata are basically wavetable
 oscilators. You have objects such as [tabosc4~] and that is it.
 What [phasor~] was designed to do is to indicate the phase of the
 waveform on a table. So you have to adjust phsor to be compatible with the
 table size. You do that simply by multiplying phasor (wich ramps up to one)
 to the table size. So what it is meant to do is tell the position (or
 phase) in a table. That is why it goes from 0 to 1. If it did go from -1
 to 1, as an ocilator, then it wouldnt work that way.

 So there is a misconception of [phasor~] being a sawtooth wave generator
 that can be misleading. As an oscilator, [phasor~] has a DC Offset. In order
 to [phasor~] became an oscilator with no DC Offset, we have to correct it.

 Maybe it is nice to be explicit about it in Floss Manuals, and say that
 Pd mostly works out with Table lookup oscilators, and that [osc~] is a
 special and unique object that is meant to be a Cosine wave oscilator.

 Then, when explaining how to get other kinds of wavefroms on Pd, such as
 sawtooth, square, triangle, we could emphasize that we are creating them,
 and building them up with the objects we have. Thast also makes it implicit
 that there is more than one way to di it, and that there is no official or
 built in Square wave, for instance.

 I actually talk a lot about that on my book. And I present examples on
 how to get a triangle waveform on a table using the sinesum comand, that is,
 by summing up harmonics.

 Cheers
 Alex

 On Mon, Mar 30, 2009 at 3:02 PM, Derek Holzer de...@umatic.nl mailto:
 de...@umatic.nl wrote:

Is it really DC offset when the value goes from 0 to 1 instead of -1
to 1? I mean, that's the way [phasor~] comes right out of the box.

D.

Alexandre Porres wrote:


I tried again, and now it works much better than before... so I
guess there was something wrong before.

Well Claude, it seems it almost works as the [triangle~] object.

Do you guys know about this one? It comes in some external
 library.

Were you who did it anyway Claude? :)

[triangle~] works in a similar fashion, it goes smoothly from
inverse sawtooth to triangle and the sawtooth depending on the
   

Re: [PD] pd book sprint

2009-03-30 Thread Derek Holzer
Cool then, I'll hold off on further comments until I've seen your 
examples. Thanks for taking your time to explain all this. I think the 
more often it gets explained, the smoother the explanation becomes.


best,
D.

Alexandre Porres wrote:
well, I totally agree with you, and that is why my stuff does not fill 
in the niche of Miller's and others at all.


My stuff is for people who really had never seen anything like this, 
which is practically everybody in brazil :)


I try to put some stuff in miller's book more accessible, but most of it 
I dont even bother to attempt that at all! Just the basics...


The stuff is kinda in between Floss Manuals and Miller's book. But I 
dont wish to inject the things I wrote about inside Floss Manuals at 
all. it would even be smart to repeat some stuff redundantly.


But the theory in DSP we are discussing here is really minimum, and the 
math could not be any simpler, which is just the procedure of using a 
[+] object, as complex as adjusting the gain with [*].


Since it is that basic, I dont find it intimidating at all.

But I really hope we could all share our thoughts and ideas, and create 
different materials that complement each other, and that are also 
coherent with each other.


So sorry if I looked too technical, but I still believe it could be 
simply presented, and that the material could benefit from it.


You see, DC Offset is also important to create Synthesis Control, like 
in the Amplitude Modulation example. If you want to do an AM synth with 
[osc], you need to adjust DC. But the procedure is really really simple. 
I will work on the examples and send it to you as soon as i can.


thanks
alex


On Mon, Mar 30, 2009 at 3:29 PM, Derek Holzer de...@umatic.nl 
mailto:de...@umatic.nl wrote:


I agree with the principles of this approach, but perhaps not the
complexity. The FLOSS Manual doesn't exist as a way to teach DSP.
That's what Miller's stuff is for. It exists as a way to get people
who are put off by the existing documentation, which is very very
heavy in math, DSP and computer science. These are the people I get
in my workshops every time. They just want to get an idea of how to
do things and not be intimidated. Thus the emphasis on simple
solutions rather than correct ones.

If people are ready for a deeper understanding of DSP, that's where
Miller's book, and pd-tutorial.com http://pd-tutorial.com and the
Roads CMT book and all the rest come in. And perhaps your Portuguese
one as well. I don't want this book to step into a niche which
already has many options, I want it to fill a niche which is still
wide open: Pd for absolute beginners, no prerequisites required.

D.

Alexandre Porres wrote:

you know, yeah, but the thing is that phasor is not actually an
oscilator at all !!!

the name actually refers to phase, and not sawtooth.

Apart from [osc~], oscilators in puredata are basically
wavetable oscilators. You have objects such as [tabosc4~] and
that is it.
What [phasor~] was designed to do is to indicate the phase of
the waveform on a table. So you have to adjust phsor to be
compatible with the table size. You do that simply by
multiplying phasor (wich ramps up to one) to the table size. So
what it is meant to do is tell the position (or phase) in a
table. That is why it goes from 0 to 1. If it did go from -1 to
1, as an ocilator, then it wouldnt work that way.

So there is a misconception of [phasor~] being a sawtooth wave
generator that can be misleading. As an oscilator, [phasor~] has
a DC Offset. In order to [phasor~] became an oscilator with no
DC Offset, we have to correct it.

Maybe it is nice to be explicit about it in Floss Manuals, and
say that Pd mostly works out with Table lookup oscilators, and
that [osc~] is a special and unique object that is meant to be a
Cosine wave oscilator.

Then, when explaining how to get other kinds of wavefroms on Pd,
such as sawtooth, square, triangle, we could emphasize that we
are creating them, and building them up with the objects we
have. Thast also makes it implicit that there is more than one
way to di it, and that there is no official or built in Square
wave, for instance.

I actually talk a lot about that on my book. And I present
examples on how to get a triangle waveform on a table using the
sinesum comand, that is, by summing up harmonics.

Cheers
Alex

On Mon, Mar 30, 2009 at 3:02 PM, Derek Holzer de...@umatic.nl
mailto:de...@umatic.nl mailto:de...@umatic.nl
mailto:de...@umatic.nl wrote:

   Is it really DC offset when the value goes from 0 to 1
instead of -1
   to 1? I mean, that's the way [phasor~] comes right out of the
 

Re: [PD] building vanilla on os x (Was: Re: abs~ and exp~ fixes [was: rjdj])

2009-03-30 Thread Steffen Juul


On 30/03/2009, at 14.01, Luke Iannini wrote:


On Mon, Mar 30, 2009 at 3:52 AM, volker böhm vbo...@gmx.ch wrote:


On 30 Mar 2009, at 00:31, Hans-Christoph Steiner wrote:


On Mar 29, 2009, at 3:20 PM, Steffen Juul wrote:



On 29/03/2009, at 17.41, volker böhm wrote:


however i never succeeded in building pd vanilla on osx myself
(anyone?).


No, not with the makefile shipped with vanilla. It would be nice  
to know

who Miller actually builds it.

Hmm.. I build Pd on OS X all the time!  I don't think I've done
anything special but perhaps I did long ago.  Of course, I don't know
the process by which Miller assembles the Pd app bundle, but I simply
build the pd binary and drop it in to the latest Pd.app from Miller's
site.


Ah ok. Thanks for sharing that tip. Maybe Miller actually make  
the .app that way. That could explain why the CFBundleVersion tag in  
Info.plist still is set to 0.38. Side note: I think Marius found that  
to be the problem with newer versions not being the standard for  
opening Pd patches.



Where is it failing?


It didn't really fail. IT just doesn't assemble a .app - as Volker  
described.

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


Re: [PD] building vanilla on os x (Was: Re: abs~ and exp~ fixes [was: rjdj])

2009-03-30 Thread Steffen Juul


On 30/03/2009, at 16.31, volker böhm wrote:
i would be interested in knowing what's the startup sequence when  
double clicking on the app bundle.


I think Hans has documented exactly that. Maybe you can find the  
appropriate thread on the pd-dev list.
 
___

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


Re: [PD] Pure Data FLOSS Manual Book Sprint 4-6 April 2009 in NYC and Berlin

2009-03-30 Thread Max

hey marius, derek + list,

i've done some of that already. maybe you can recycle what i've done  
for some classes.

files are here:
http://damm-net.org/wiki/index.php?title=Bewegungsmelder
i'm glad if i can help, let me know.

m.

Am 30.03.2009 um 19:47 schrieb marius schebella:


Hi,

I'd like to participate remotely somehow. I understand that you also  
want to cover Gem(?), so I'd like to propose a chapter on video  
tracking. motion tracking, background subtraction, showing how to do  
alpha masking, color tracking, I also would like to include some  
documentation of pix_opencv, unless someone else is already doing  
that, for example face tracking, but also other possibilities of  
opencv (pattern recognition).
I also think the TUIO stuff should go there (with references to  
touchlib or touché), and multiblob.


AFAIK there is no gem section yet, so I don't know if it is possible  
to do just one chapter without a general introduction to gem??


Btw, there are tons of other topics to cover...

marius.




PGP.sig
Description: Signierter Teil der Nachricht
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] Pdpedia and random generation

2009-03-30 Thread Philip Potter
Hi all,

First post to the list, very new to pd, hello to all. I have a few questions:

1) Is pdpedia a serious project? It seems like there was a lot of
activity some time ago, but the people there got burned out and now is
a target for spammers (particularly the myobject and help patch
pages). I have done some updating of it but if noone else is doing
anything to it then maybe I should be looking for other pd resources.

2) I had a look at pd-tutorial.com and tried to do their exercise on
random number generation such that no two sequential numbers are
equal:
http://pd-tutorial.com/english/ch02s02.html#id411951
I came up with the attached file, which I feel is better than the
original solution. What do you think? Are there advantages to the
original which I haven't considered?

3) Someone mentioned on the list a [pack 0 0 0 0 0] idiom for building
large trees of maths in order to avoid weaving many [t b f] objects to
cold inlets. How does this idiom work?

TIA,

Philip


random-no-repeat.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-30 Thread marius schebella

Philip Potter wrote:

Hi all,

First post to the list, very new to pd, hello to all. I have a few questions:

1) Is pdpedia a serious project? It seems like there was a lot of
activity some time ago, but the people there got burned out and now is
a target for spammers (particularly the myobject and help patch
pages). I have done some updating of it but if noone else is doing
anything to it then maybe I should be looking for other pd resources.


hi philip,
afaik, pdpedia is poorly maintained at the moment. I think there will be 
a better solution in the future to get rid of spam and optimize 
searching and contributions. for now, your observation of burnout seems 
correct.

marius.

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


Re: [PD] Pdpedia and random generation

2009-03-30 Thread Mathieu Bouchard

On Mon, 30 Mar 2009, Philip Potter wrote:


3) Someone mentioned on the list a [pack 0 0 0 0 0] idiom for building
large trees of maths in order to avoid weaving many [t b f] objects to
cold inlets. How does this idiom work?


It doesn't eliminate the [t b f], it makes them more manageable.

it's just a bunch of [inlets] connected to a [pack 0 0 0 0 0] then to an 
[unpack 0 0 0 0 0]. This causes recomputation of the complete tree of 
maths every time something is sent to the hot inlet of the abstraction, 
but it doesn't fix anything arising from crossing wires in ways that would 
usually cause a delay: for example if you use [t f f] with crossed wires 
to an object, instead of using [swap], this causes a delay (intentional or 
not) due to order of operations.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] Re: DIY GSoC: getting those projects done

2009-03-30 Thread Mathieu Bouchard

On Mon, 30 Mar 2009, Claude Heiland-Allen wrote:

Not sure I like the idea of a run method, what if there's more than 
one reasonable run action?


When inlets are called hot and cold, it's always because there is only 
one thing you can call the run-action in an ordinary object: the thing 
that is done by sending a value in the first inlet, and the thing that is 
not done by the set method of the first inlet, nor by sending a value in 
any other inlet.


But if any other inlet could be hot, then there would be a need to have a 
set method anywhere. And then bang and set are considered as lists 
by [list].


I wonder whether anything can be done to improve Pd about it without 
opening a can of worms or two.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] Vertical text with GEM

2009-03-30 Thread Brendan

I want to render vertical text in GEM, i.e.
T
E
X
T

Any suggestions?  I haven't found an example and my effort to do it  
in PD is turning out ridiculously complex and difficult.  I'm OK with  
writing externals, but I haven't looked into how GEM works yet.


PDP is all right too, but preferably GEM.


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


Re: [PD] [OT] Re: DIY GSoC: getting those projects done

2009-03-30 Thread Mathieu Bouchard

On Sun, 29 Mar 2009, Hans-Christoph Steiner wrote:

On Mar 28, 2009, at 5:32 AM, Chris McCormick wrote:

I like the idea of this behaviour being defined by the class author, but
(re)configurable by the user.
Sounds like an interesting idea, its something more like how  works.  For 
me, I make sense of  by thinking of it as Pd with only tilde objects, no 
message objects.


He doesn't mean to have everything work like the DSP. In that case there 
wouldn't be hot inlets nor cold inlets and so you wouldn't need them to be 
reconfigurable. He's talking about making them configurable.


If you make everything work like the DSP (that is, one message per block, 
or one message per sample, whichever), then there are quite a few things 
you can't do anymore or have to do in different ways: can't avoid sending 
a message during a tick, and can't send more than one message during a 
tick, and can't recurse in any way, even to a cold inlet (you can't sum 
the values in a signal using just [+~] connected to itself...).


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pdpedia and random generation

2009-03-30 Thread Hans-Christoph Steiner


On Mar 30, 2009, at 5:46 PM, marius schebella wrote:


Philip Potter wrote:

Hi all,
First post to the list, very new to pd, hello to all. I have a few  
questions:

1) Is pdpedia a serious project? It seems like there was a lot of
activity some time ago, but the people there got burned out and now  
is

a target for spammers (particularly the myobject and help patch
pages). I have done some updating of it but if noone else is doing
anything to it then maybe I should be looking for other pd resources.


hi philip,
afaik, pdpedia is poorly maintained at the moment. I think there  
will be a better solution in the future to get rid of spam and  
optimize searching and contributions. for now, your observation of  
burnout seems correct.

marius.


I think pdpedia has a lot of potential, but it needs someone to take  
ownership of it.  Its really open to anyone who wants to take it on.   
It is useful now for searching based on keywords.  I use it to find  
objects based on key words.


.hc



If you are not part of the solution, you are part of the problem.



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


Re: [PD] GEM pix_write bugs (timelapse)

2009-03-30 Thread Max

here is the same thing with pix_multiimage instead.
it will crash pd a little bit later than the version with pix_image.




timelapse_multiimage.pd
Description: Binary data




Am 30.03.2009 um 18:50 schrieb mark edward grimm:



hey thats pretty nice!!

much nicer than my poor gem attempt last month...


and the patch:
put this to / because of the bug in pix_write to make it
work. put a folder called frames beside it.


yeah this is weird huh?




--- On Sat, 3/28/09, Max abonneme...@revolwear.com wrote:


From: Max abonneme...@revolwear.com
Subject: [PD] GEM pix_write bugs (timelapse)
To: pd-list@iem.at
Date: Saturday, March 28, 2009, 12:52 PM
hi list,

i've thrown together this tiny gem patch which makes a
timelapse slideshow.
i have encountered a few issues with it.

configuration:
Pd version 0.41.4-extended-20090223
GEM: ver: 0.91.3 'tigital'
GEM: compiled: Feb 23 2009
OS X 10.5.6

the issues:
1. pix_write doesn't interpret the file path correctly. it
seems it can't understand relative paths at all.

2. pix_write accepts a message [file file
[type](. it creates files with a .jpg ending if the
type is 0. But in reality it still is a TIFF. no matter
what value you write.

3. pix_write creates files with an acending number 0...
this conflicts with how other objects like pix_multiimage do
it (0...9)

just submitted that to the gem bugtracker.


and the patch:
put this to / because of the bug in pix_write to make it
work. put a folder called frames beside it.






beware: this patch will also eat up all the memory and will
crash pd. this isn't pix_writes problem though - i'll try to
find out why this is now.

max
-Inline Attachment Follows-

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





PGP.sig
Description: Signierter Teil der Nachricht
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list