date:20090330


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

[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


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

Re: [PD] Pdpedia and random generation


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] 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

[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] 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

Re: [PD] pd book sprint

yeah, well, as I say, care must be taken not to repeat or get redundant.
I hope we could gather the available publications somehow, and write notes
on the aims of each of them. This is certainly nice for those who want to
get started, they can know what there is around, and choose what to read,
and in what order...

I surely see pd-tutorial as a step further than Floss Manuals. And I am
working on something that is even further, and in between Miller's

that is cool right?

cheers

On Mon, Mar 30, 2009 at 5:01 PM, Steffen Juul  wrote:

>
> On 30/03/2009, at 20.29, Derek Holzer wrote:
>
>  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.
>>
>
>
> As i understood it, that is also the (at least intended) scope of
> 'Programming Electronic Music in Pd' aka pd-tutorial.com. - Not that you
> shouldn't carry on.
>

-- 
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 Steffen Juul



On 30/03/2009, at 20.29, Derek Holzer wrote:

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.



As i understood it, that is also the (at least intended) scope of  
'Programming Electronic Music in Pd' aka pd-tutorial.com. - Not that  
you shouldn't carry on.


___
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] 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  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] pd book sprint

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

Re: [PD] pd book sprint

errata"
 it wouldnt even be smart to repeat some stuff redundantly.


On Mon, Mar 30, 2009 at 3:41 PM, 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  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>> 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.
>>>
>>>

Re: [PD] pd book sprint

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  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>> 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 cor

Re: [PD] pd book sprint

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 > 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
mailto: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, 0  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 Tor

[PD] dc offset

> 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  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 > 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, 0>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

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  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 > 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, 0>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

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

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 
mailto: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, 0  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] Pure Data FLOSS Manual Book Sprint 4-6 April 2009 in NYC and Berlin

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/Introduction&skin=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 pat

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

2009-03-30 Thread marius schebella

Hi,

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/Introduction&skin=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] [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] pd book sprint

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] 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  wrote:

> From: Max 
> 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 
> [](. 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] 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/Introduction&skin=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

---Possible janitors: Derek Holzer, Adam Hyde

# PureGlossary

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

Re: [PD] pd book sprint

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, 0 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] pd book sprint

2009-03-30 Thread Claude Heiland-Allen


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, 0phasor, 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

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

[PD] triangle

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] 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 wrote:

> 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

Re: [PD] pd book sprint

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] pd book sprint

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



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 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 eithe

Re: [PD] pd book sprint

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

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

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] building vanilla on os x (Was: Re: abs~ and exp~ fixes [was: rjdj])



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

On Mon, Mar 30, 2009 at 3:52 AM, volker böhm  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] [OT] Re: DIY GSoC: getting those projects done


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] pd book sprint

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] 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


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

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 > wrote:


sure, I could do both.

But I think it would be inportant to start just after
 


* AUDIO TUTORIALS
* 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 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
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 ::: 
http://www.vimeo.com/macumbista :::

---Oblique

Re: [PD] pd book sprint

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
  


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

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  wrote:

> sure, I could do both.
> But I think it would be inportant to start just after
>
>
>- AUDIO TUTORIALS
>- 
> 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  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>> 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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd book sprint

sure, I could do both.
But I think it would be inportant to start just after


   - AUDIO TUTORIALS
   - 
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  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>> 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
___
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


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

Re: [PD] pd book sprint

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

[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] 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  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

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



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



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]

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] abs~ and exp~ fixes [was: rjdj]