Re: [PD] Compiling Externals using MinGW / MSYS on Windows

[fjkraan]

Hi Ricky,


Hi folks,

I’m attempting to compile on a Windows 7 machine running the most
recent version of MinGW. I’m using Katja's pd-lib-builder
(https://github.com/pure-data/pd-lib-builder). My MinGW installer
states that I have Make v. 3.81 installed (required to compile using
Katja’s project). However, when I check Make version on MSYS shell,
it states that the version is 3.7, thus not allowing me to compile. I
cannot find any documentation anywhere on how to upgrade Make. I
suspect something isn’t pointing where it should. Does anyone have
any ideas why MSYS shell would report an older version of Make despite
what my MinGW installer is telling me?


Probably because it is in the PATH earlier. What is the result of which 
make?


All the best,

Ricky


Greetings,

Fred Jan

P.S. MinGW comes with a nice GUI tool to view and select packages. If I 
remember correctly, the MSYS subsystem has its own build chain 
containing other (older) versions. It should be used only to build MSYS, 
so you should deinstall these.



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



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

Re: [PD] How's Pd limited?

[William Huston]

My answer is in the form of a Koan:


*If an oscillator's output is not connected to a DAC,*
*does it still make a sound? *

On Sun, Feb 21, 2016 at 8:49 PM, Matti Viljamaa  wrote:

> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Esteban Viveros]

I found that:
http://forum.pdpatchrepo.info/topic/9749/question-resize-canvas-realtime/4


Em ter, 23 de fev de 2016 às 03:22, Esteban Viveros 
escreveu:

> Em ter, 23 de fev de 2016 às 00:56, Matt Barber 
> escreveu:
>
>> Newest vanilla has basic object resize, which actually helps a lot with
>> some of the issues brought up here. It's also very helpful that comments
>> can be resized, so you can set the wrap point.
>>
>> Cool.. I'm using pd 0.46-7, what's that object? :)
>
>
>> On Mon, Feb 22, 2016 at 10:48 PM, Esteban Viveros 
>> wrote:
>>
>>> A feature I miss in vanilla and extended (pdl2ork solve that) is resize
>>> objects via one point click and drag. If it is hard to implement, a "apply"
>>> button on properties can help to design UI's in Vanilla.
>>>
>>> Max have features like auto-align horizontally/vertically and align and
>>> route patch cords which is very useful to organize patch cords and make the
>>> thinks more readable. I like them a lot.
>>>
>>> Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
>>> pd-list@lists.iem.at> escreveu:
>>>
 That's something i completly experiece diffrently!! Pd fucks up in
 practise and development quiet often (maybe i make it fuck up) but once it
 runs, it runs stable every time!!

 Love to pd,

 Johnny
 Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
 mino...@gmail.com>:

> Not tried different builds, please giide me.
> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <
> mino...@gmail.com>:
>
>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>> extended 0.43. I did a clean install a week ago and it worked fine for a
>> week until I installed live 9. It still worked until it suddenly hit some
>> kond of wall again.
>>
>> Mort
>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>
>>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>>> you've already tried using different builds. What OS are you on?
>>>
>>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>>> mino...@gmail.com> wrote:
>>>
 On my last two comouters PD wont open unless I start it with a
 standalone patch I made long ago. It works for a little while, then 
 crashes
 completely and for ever more...unless I use the stand alone. 
 Recently...5
 min before a gig the standalone wouldnt even start. The gig was fine 
 as Im
 nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
 someone could have helped me earlier with this. I have posted and 
 searched
 for answears, but didnt get nothing back. Aaaarrrhhh!!!

 I would mayyybe make a few more attempts if only someone serious
 would help me out with this and fix the problem, but thats yet to be 
 the
 case.

 Ok... sorry about the rant. Had to get it out and now Im moving on
 with Max.

 Yebo
 Morten
 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

> Perhaps a bit of broad question, but I find it interesting in
> order to speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>

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


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

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

Re: [PD] How's Pd limited?

[Esteban Viveros]

Em ter, 23 de fev de 2016 às 00:56, Matt Barber 
escreveu:

> Newest vanilla has basic object resize, which actually helps a lot with
> some of the issues brought up here. It's also very helpful that comments
> can be resized, so you can set the wrap point.
>
> Cool.. I'm using pd 0.46-7, what's that object? :)


> On Mon, Feb 22, 2016 at 10:48 PM, Esteban Viveros 
> wrote:
>
>> A feature I miss in vanilla and extended (pdl2ork solve that) is resize
>> objects via one point click and drag. If it is hard to implement, a "apply"
>> button on properties can help to design UI's in Vanilla.
>>
>> Max have features like auto-align horizontally/vertically and align and
>> route patch cords which is very useful to organize patch cords and make the
>> thinks more readable. I like them a lot.
>>
>> Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
>> pd-list@lists.iem.at> escreveu:
>>
>>> That's something i completly experiece diffrently!! Pd fucks up in
>>> practise and development quiet often (maybe i make it fuck up) but once it
>>> runs, it runs stable every time!!
>>>
>>> Love to pd,
>>>
>>> Johnny
>>> Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
>>> mino...@gmail.com>:
>>>
 Not tried different builds, please giide me.
 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <
 mino...@gmail.com>:

> Its been like this with Mavericks, Yosemite and El capitalist. Pd
> extended 0.43. I did a clean install a week ago and it worked fine for a
> week until I installed live 9. It still worked until it suddenly hit some
> kond of wall again.
>
> Mort
> 23. feb. 2016 02.15 skrev "AP Vague" :
>
>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>> you've already tried using different builds. What OS are you on?
>>
>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>> mino...@gmail.com> wrote:
>>
>>> On my last two comouters PD wont open unless I start it with a
>>> standalone patch I made long ago. It works for a little while, then 
>>> crashes
>>> completely and for ever more...unless I use the stand alone. 
>>> Recently...5
>>> min before a gig the standalone wouldnt even start. The gig was fine as 
>>> Im
>>> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
>>> someone could have helped me earlier with this. I have posted and 
>>> searched
>>> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>>>
>>> I would mayyybe make a few more attempts if only someone serious
>>> would help me out with this and fix the problem, but thats yet to be the
>>> case.
>>>
>>> Ok... sorry about the rant. Had to get it out and now Im moving on
>>> with Max.
>>>
>>> Yebo
>>> Morten
>>> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>>>
 Perhaps a bit of broad question, but I find it interesting in order
 to speculate about future additions.

 How do you think Pure Data is limited?
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management ->
 http://lists.puredata.info/listinfo/pd-list

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

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

Re: [PD] How's Pd limited?

[Esteban Viveros]

Like that:

Align: https://youtu.be/lCIeIelbw74
Route Patch Cords: https://youtu.be/2u_UJQ8OfvU



Em ter, 23 de fev de 2016 às 02:09, Jonathan Wilkes 
escreveu:

> > Here's a radical idea that I've sometimes pondered: what if we could
> create left-inlets and right-outlets as well as the standard top- and
> bottom- ones?
>
> If the object has more than one inlet or outlet you wouldn't be able to
> fit them on the side of the object box.
>
> Also, you run into a common UI problem: if you rotate a thing ninety
> degrees, do you rotate clockwise or counterclockwise?  If I push "up"
> on a DirectTv remote the channel guide on the screen scrolls down (and the
> numbers decrease!), but if I slide my fingers up a MacBook
> touchpad the browser window scrolls upward.  Similarly, vertically-placed
> outlets could fire top-down or bottom-up.  Maybe one is somehow
> more natural than the other, but off the top of my head I can't think
> which.  So I think you'd get more conceptual complexity in return for
> visual left-to-right flow.
>
> [expr] helps to fill the role you describe.  Unfortunately the
> Max-compatibility creates more complexity, making Pd's mantra of
> "everything is a float" turn into "everything is a float unless it follows
> the syntax of that other software which you may or may
> not have learned..."
>
> -Jonathan
>
>
>
> On Monday, February 22, 2016 11:40 PM, Jonathan Wilkes 
> wrote:
>
>
> > Max have features like auto-align horizontally/vertically
>
> Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little
> strange-- if you click it once it will sweep the selected objects into a
> "pile", and if you click again it will fan them out like a deck of cards.
> But it can work well for some situations.
>
> > and align and route patch cords which is very useful to organize patch
> cords and make the thinks more readable. I like them a lot.
>
> That's a side-effect of "Tidy Up" in a lot of cases, at least for the
> leftmost inlets and outlets.
>
> -Jonathan
>
>
>
> On Monday, February 22, 2016 10:49 PM, Esteban Viveros <
> emvive...@gmail.com> wrote:
>
>
> A feature I miss in vanilla and extended (pdl2ork solve that) is resize
> objects via one point click and drag. If it is hard to implement, a "apply"
> button on properties can help to design UI's in Vanilla.
>
> Max have features like auto-align horizontally/vertically and align and
> route patch cords which is very useful to organize patch cords and make the
> thinks more readable. I like them a lot.
>
> Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
> pd-list@lists.iem.at> escreveu:
>
> That's something i completly experiece diffrently!! Pd fucks up in
> practise and development quiet often (maybe i make it fuck up) but once it
> runs, it runs stable every time!!
> Love to pd,
> Johnny
> Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
> mino...@gmail.com>:
>
> Not tried different builds, please giide me.
> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen"  >:
>
> Its been like this with Mavericks, Yosemite and El capitalist. Pd extended
> 0.43. I did a clean install a week ago and it worked fine for a week until
> I installed live 9. It still worked until it suddenly hit some kond of wall
> again.
> Mort
> 23. feb. 2016 02.15 skrev "AP Vague" :
>
> Woah, that's definitely a problem I haven't heard of... I'm guessing
> you've already tried using different builds. What OS are you on?
>
> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
> mino...@gmail.com> wrote:
>
> On my last two comouters PD wont open unless I start it with a standalone
> patch I made long ago. It works for a little while, then crashes completely
> and for ever more...unless I use the stand alone. Recently...5 min before a
> gig the standalone wouldnt even start. The gig was fine as Im nott 100%
> relying on pd, but I have lost faith in PD EXTENDED and wish someone could
> have helped me earlier with this. I have posted and searched for answears,
> but didnt get nothing back. Aaaarrrhhh!!!
> I would mayyybe make a few more attempts if only someone serious would
> help me out with this and fix the problem, but thats yet to be the case.
> Ok... sorry about the rant. Had to get it out and now Im moving on with
> Max.
> Yebo
> Morten
> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>
> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> 

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> Here's a radical idea that I've sometimes pondered: what if we could create 
>left-inlets and right-outlets as well as the standard top- and bottom- ones? 
If the object has more than one inlet or outlet you wouldn't be able to fit 
them on the side of the object box.
Also, you run into a common UI problem: if you rotate a thing ninety degrees, 
do you rotate clockwise or counterclockwise?  If I push "up" on a DirectTv 
remote the channel guide on the screen scrolls down (and the numbers 
decrease!), but if I slide my fingers up a MacBook touchpad the browser window 
scrolls upward.  Similarly, vertically-placed outlets could fire top-down or 
bottom-up.  Maybe one is somehow more natural than the other, but off the top 
of my head I can't think which.  So I think you'd get more conceptual 
complexity in return for visual left-to-right flow.
[expr] helps to fill the role you describe.  Unfortunately the 
Max-compatibility creates more complexity, making Pd's mantra of "everything is 
a float" turn into "everything is a float unless it follows the syntax of that 
other software which you may or may not have learned..."
-Jonathan


On Monday, February 22, 2016 11:40 PM, Jonathan Wilkes  
wrote:
 

 > Max have features like auto-align horizontally/vertically
Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little strange-- 
if you click it once it will sweep the selected objects into a "pile", and if 
you click again it will fan them out like a deck of cards.  But it can work 
well for some situations.
> and align and route patch cords which is very useful to organize patch cords 
> and make the thinks more readable. I like them a lot.
That's a side-effect of "Tidy Up" in a lot of cases, at least for the leftmost 
inlets and outlets.
-Jonathan
 

On Monday, February 22, 2016 10:49 PM, Esteban Viveros 
 wrote:
 

 A feature I miss in vanilla and extended (pdl2ork solve that) is resize 
objects via one point click and drag. If it is hard to implement, a "apply" 
button on properties can help to design UI's in Vanilla.
Max have features like auto-align horizontally/vertically and align and route 
patch cords which is very useful to organize patch cords and make the thinks 
more readable. I like them a lot.
Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list 
 escreveu:

That's something i completly experiece diffrently!! Pd fucks up in practise and 
development quiet often (maybe i make it fuck up) but once it runs, it runs 
stable every time!!Love to pd, Johnny Am 23.02.2016 02:20 schrieb "Morten 
Minothi Kristiansen" :

Not tried different builds, please giide me.23. feb. 2016 02.20 skrev "Morten 
Minothi Kristiansen" :

Its been like this with Mavericks, Yosemite and El capitalist. Pd extended 
0.43. I did a clean install a week ago and it worked fine for a week until I 
installed live 9. It still worked until it suddenly hit some kond of wall 
again.Mort23. feb. 2016 02.15 skrev "AP Vague" :

Woah, that's definitely a problem I haven't heard of... I'm guessing you've 
already tried using different builds. What OS are you on?
On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen  
wrote:

On my last two comouters PD wont open unless I start it with a standalone patch 
I made long ago. It works for a little while, then crashes completely and for 
ever more...unless I use the stand alone. Recently...5 min before a gig the 
standalone wouldnt even start. The gig was fine as Im nott 100% relying on pd, 
but I have lost faith in PD EXTENDED and wish someone could have helped me 
earlier with this. I have posted and searched for answears, but didnt get 
nothing back. Aaaarrrhhh!!! I would mayyybe make a few more attempts if 
only someone serious would help me out with this and fix the problem, but thats 
yet to be the case. Ok... sorry about the rant. Had to get it out and now Im 
moving on with Max. Yebo
Morten 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

Perhaps a bit of broad question, but I find it interesting in order to 
speculate about future additions.

How do you think Pure Data is limited?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


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






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


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


___

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> Max have features like auto-align horizontally/vertically
Pd-l2ork has this, too-- "Tidy Up" in the Edit menu.  It's a little strange-- 
if you click it once it will sweep the selected objects into a "pile", and if 
you click again it will fan them out like a deck of cards.  But it can work 
well for some situations.
> and align and route patch cords which is very useful to organize patch cords 
> and make the thinks more readable. I like them a lot.
That's a side-effect of "Tidy Up" in a lot of cases, at least for the leftmost 
inlets and outlets.
-Jonathan
 

On Monday, February 22, 2016 10:49 PM, Esteban Viveros 
 wrote:
 

 A feature I miss in vanilla and extended (pdl2ork solve that) is resize 
objects via one point click and drag. If it is hard to implement, a "apply" 
button on properties can help to design UI's in Vanilla.
Max have features like auto-align horizontally/vertically and align and route 
patch cords which is very useful to organize patch cords and make the thinks 
more readable. I like them a lot.
Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list 
 escreveu:

That's something i completly experiece diffrently!! Pd fucks up in practise and 
development quiet often (maybe i make it fuck up) but once it runs, it runs 
stable every time!!Love to pd, Johnny Am 23.02.2016 02:20 schrieb "Morten 
Minothi Kristiansen" :

Not tried different builds, please giide me.23. feb. 2016 02.20 skrev "Morten 
Minothi Kristiansen" :

Its been like this with Mavericks, Yosemite and El capitalist. Pd extended 
0.43. I did a clean install a week ago and it worked fine for a week until I 
installed live 9. It still worked until it suddenly hit some kond of wall 
again.Mort23. feb. 2016 02.15 skrev "AP Vague" :

Woah, that's definitely a problem I haven't heard of... I'm guessing you've 
already tried using different builds. What OS are you on?
On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen  
wrote:

On my last two comouters PD wont open unless I start it with a standalone patch 
I made long ago. It works for a little while, then crashes completely and for 
ever more...unless I use the stand alone. Recently...5 min before a gig the 
standalone wouldnt even start. The gig was fine as Im nott 100% relying on pd, 
but I have lost faith in PD EXTENDED and wish someone could have helped me 
earlier with this. I have posted and searched for answears, but didnt get 
nothing back. Aaaarrrhhh!!! I would mayyybe make a few more attempts if 
only someone serious would help me out with this and fix the problem, but thats 
yet to be the case. Ok... sorry about the rant. Had to get it out and now Im 
moving on with Max. Yebo
Morten 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

Perhaps a bit of broad question, but I find it interesting in order to 
speculate about future additions.

How do you think Pure Data is limited?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


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






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


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


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


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

Re: [PD] How's Pd limited?

[Dan Wilcox]

> On Feb 22, 2016, at 8:54 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Esteban Viveros >
> Subject: Re: [PD] How's Pd limited?
> Date: February 22, 2016 at 8:48:16 PM MST
> To: Johnny Mauser  >, Morten Minothi Kristiansen 
> >
> Cc: pd-list@lists.iem.at 
> 
> 
> A feature I miss in vanilla and extended (pdl2ork solve that) is resize 
> objects via one point click and drag. If it is hard to implement, a "apply" 
> button on properties can help to design UI's in Vanilla.

I have updates in the works for the vanilla dialog boxes.

> Max have features like auto-align horizontally/vertically and align and route 
> patch cords which is very useful to organize patch cords and make the thinks 
> more readable. I like them a lot.

Object & canvas align could be made using a GUI plugin. Such a plugin might 
exist already, actually.


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

Re: [PD] How's Pd limited?

[Dan Wilcox]

If you’re on Mac OS X, you problem might be related to this: 
http://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7 



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Feb 22, 2016, at 6:20 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Morten Minothi Kristiansen  >
> Subject: Re: [PD] How's Pd limited?
> Date: February 22, 2016 at 6:07:16 PM MST
> To: Matti Viljamaa >
> Cc: Pd-List >
> 
> 
> On my last two comouters PD wont open unless I start it with a standalone 
> patch I made long ago. It works for a little while, then crashes completely 
> and for ever more...unless I use the stand alone. Recently...5 min before a 
> gig the standalone wouldnt even start. The gig was fine as Im nott 100% 
> relying on pd, but I have lost faith in PD EXTENDED and wish someone could 
> have helped me earlier with this. I have posted and searched for answears, 
> but didnt get nothing back. Aaaarrrhhh!!! 
> 
> I would mayyybe make a few more attempts if only someone serious would help 
> me out with this and fix the problem, but thats yet to be the case. 
> 
> Ok... sorry about the rant. Had to get it out and now Im moving on with Max. 
> 
> Yebo
> Morten
> 

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

Re: [PD] How's Pd limited?

[Matt Barber]

Newest vanilla has basic object resize, which actually helps a lot with
some of the issues brought up here. It's also very helpful that comments
can be resized, so you can set the wrap point.

On Mon, Feb 22, 2016 at 10:48 PM, Esteban Viveros 
wrote:

> A feature I miss in vanilla and extended (pdl2ork solve that) is resize
> objects via one point click and drag. If it is hard to implement, a "apply"
> button on properties can help to design UI's in Vanilla.
>
> Max have features like auto-align horizontally/vertically and align and
> route patch cords which is very useful to organize patch cords and make the
> thinks more readable. I like them a lot.
>
> Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
> pd-list@lists.iem.at> escreveu:
>
>> That's something i completly experiece diffrently!! Pd fucks up in
>> practise and development quiet often (maybe i make it fuck up) but once it
>> runs, it runs stable every time!!
>>
>> Love to pd,
>>
>> Johnny
>> Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
>> mino...@gmail.com>:
>>
>>> Not tried different builds, please giide me.
>>> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <
>>> mino...@gmail.com>:
>>>
 Its been like this with Mavericks, Yosemite and El capitalist. Pd
 extended 0.43. I did a clean install a week ago and it worked fine for a
 week until I installed live 9. It still worked until it suddenly hit some
 kond of wall again.

 Mort
 23. feb. 2016 02.15 skrev "AP Vague" :

> Woah, that's definitely a problem I haven't heard of... I'm guessing
> you've already tried using different builds. What OS are you on?
>
> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
> mino...@gmail.com> wrote:
>
>> On my last two comouters PD wont open unless I start it with a
>> standalone patch I made long ago. It works for a little while, then 
>> crashes
>> completely and for ever more...unless I use the stand alone. Recently...5
>> min before a gig the standalone wouldnt even start. The gig was fine as 
>> Im
>> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
>> someone could have helped me earlier with this. I have posted and 
>> searched
>> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>>
>> I would mayyybe make a few more attempts if only someone serious
>> would help me out with this and fix the problem, but thats yet to be the
>> case.
>>
>> Ok... sorry about the rant. Had to get it out and now Im moving on
>> with Max.
>>
>> Yebo
>> Morten
>> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>>
>>> Perhaps a bit of broad question, but I find it interesting in order
>>> to speculate about future additions.
>>>
>>> How do you think Pure Data is limited?
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Compiling Externals using MinGW / MSYS on Windows

[Ricky Graham]

Hi folks,

I’m attempting to compile on a Windows 7 machine running the most recent 
version of MinGW. I’m using Katja's pd-lib-builder 
(https://github.com/pure-data/pd-lib-builder 
). My MinGW installer states that 
I have Make v. 3.81 installed (required to compile using Katja’s project). 
However, when I check Make version on MSYS shell, it states that the version is 
3.7, thus not allowing me to compile. I cannot find any documentation anywhere 
on how to upgrade Make. I suspect something isn’t pointing where it should. 
Does anyone have any ideas why MSYS shell would report an older version of Make 
despite what my MinGW installer is telling me?

All the best,

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

Re: [PD] How's Pd limited?

[Esteban Viveros]

A feature I miss in vanilla and extended (pdl2ork solve that) is resize
objects via one point click and drag. If it is hard to implement, a "apply"
button on properties can help to design UI's in Vanilla.

Max have features like auto-align horizontally/vertically and align and
route patch cords which is very useful to organize patch cords and make the
thinks more readable. I like them a lot.

Em seg, 22 de fev de 2016 às 23:49, Johnny Mauser via Pd-list <
pd-list@lists.iem.at> escreveu:

> That's something i completly experiece diffrently!! Pd fucks up in
> practise and development quiet often (maybe i make it fuck up) but once it
> runs, it runs stable every time!!
>
> Love to pd,
>
> Johnny
> Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" <
> mino...@gmail.com>:
>
>> Not tried different builds, please giide me.
>> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" > >:
>>
>>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>>> extended 0.43. I did a clean install a week ago and it worked fine for a
>>> week until I installed live 9. It still worked until it suddenly hit some
>>> kond of wall again.
>>>
>>> Mort
>>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>>
 Woah, that's definitely a problem I haven't heard of... I'm guessing
 you've already tried using different builds. What OS are you on?

 On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
 mino...@gmail.com> wrote:

> On my last two comouters PD wont open unless I start it with a
> standalone patch I made long ago. It works for a little while, then 
> crashes
> completely and for ever more...unless I use the stand alone. Recently...5
> min before a gig the standalone wouldnt even start. The gig was fine as Im
> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
> someone could have helped me earlier with this. I have posted and searched
> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>
> I would mayyybe make a few more attempts if only someone serious would
> help me out with this and fix the problem, but thats yet to be the case.
>
> Ok... sorry about the rant. Had to get it out and now Im moving on
> with Max.
>
> Yebo
> Morten
> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>
>> Perhaps a bit of broad question, but I find it interesting in order
>> to speculate about future additions.
>>
>> How do you think Pure Data is limited?
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>

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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

for extended, I recommend 0.42-5, but ideal is to try vanilla and use the
extended libraries you actually need

2016-02-23 0:45 GMT-03:00 Alexandre Torres Porres :

> forget about pd extended 0.43, I never recommend it !!!
>
> 2016-02-22 22:20 GMT-03:00 Morten Minothi Kristiansen :
>
>> Not tried different builds, please giide me.
>> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" > >:
>>
>>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>>> extended 0.43. I did a clean install a week ago and it worked fine for a
>>> week until I installed live 9. It still worked until it suddenly hit some
>>> kond of wall again.
>>>
>>> Mort
>>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>>
 Woah, that's definitely a problem I haven't heard of... I'm guessing
 you've already tried using different builds. What OS are you on?

 On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
 mino...@gmail.com> wrote:

> On my last two comouters PD wont open unless I start it with a
> standalone patch I made long ago. It works for a little while, then 
> crashes
> completely and for ever more...unless I use the stand alone. Recently...5
> min before a gig the standalone wouldnt even start. The gig was fine as Im
> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
> someone could have helped me earlier with this. I have posted and searched
> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>
> I would mayyybe make a few more attempts if only someone serious would
> help me out with this and fix the problem, but thats yet to be the case.
>
> Ok... sorry about the rant. Had to get it out and now Im moving on
> with Max.
>
> Yebo
> Morten
> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>
>> Perhaps a bit of broad question, but I find it interesting in order
>> to speculate about future additions.
>>
>> How do you think Pure Data is limited?
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>

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

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

forget about pd extended 0.43, I never recommend it !!!

2016-02-22 22:20 GMT-03:00 Morten Minothi Kristiansen :

> Not tried different builds, please giide me.
> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen"  >:
>
>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>> extended 0.43. I did a clean install a week ago and it worked fine for a
>> week until I installed live 9. It still worked until it suddenly hit some
>> kond of wall again.
>>
>> Mort
>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>
>>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>>> you've already tried using different builds. What OS are you on?
>>>
>>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>>> mino...@gmail.com> wrote:
>>>
 On my last two comouters PD wont open unless I start it with a
 standalone patch I made long ago. It works for a little while, then crashes
 completely and for ever more...unless I use the stand alone. Recently...5
 min before a gig the standalone wouldnt even start. The gig was fine as Im
 nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
 someone could have helped me earlier with this. I have posted and searched
 for answears, but didnt get nothing back. Aaaarrrhhh!!!

 I would mayyybe make a few more attempts if only someone serious would
 help me out with this and fix the problem, but thats yet to be the case.

 Ok... sorry about the rant. Had to get it out and now Im moving on with
 Max.

 Yebo
 Morten
 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>

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


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

Re: [PD] How's Pd limited?

[Johnny Mauser via Pd-list]

That's something i completly experiece diffrently!! Pd fucks up in practise
and development quiet often (maybe i make it fuck up) but once it runs, it
runs stable every time!!

Love to pd,

Johnny
Am 23.02.2016 02:20 schrieb "Morten Minothi Kristiansen" :

> Not tried different builds, please giide me.
> 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen"  >:
>
>> Its been like this with Mavericks, Yosemite and El capitalist. Pd
>> extended 0.43. I did a clean install a week ago and it worked fine for a
>> week until I installed live 9. It still worked until it suddenly hit some
>> kond of wall again.
>>
>> Mort
>> 23. feb. 2016 02.15 skrev "AP Vague" :
>>
>>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>>> you've already tried using different builds. What OS are you on?
>>>
>>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>>> mino...@gmail.com> wrote:
>>>
 On my last two comouters PD wont open unless I start it with a
 standalone patch I made long ago. It works for a little while, then crashes
 completely and for ever more...unless I use the stand alone. Recently...5
 min before a gig the standalone wouldnt even start. The gig was fine as Im
 nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
 someone could have helped me earlier with this. I have posted and searched
 for answears, but didnt get nothing back. Aaaarrrhhh!!!

 I would mayyybe make a few more attempts if only someone serious would
 help me out with this and fix the problem, but thats yet to be the case.

 Ok... sorry about the rant. Had to get it out and now Im moving on with
 Max.

 Yebo
 Morten
 22. feb. 2016 02.52 skrev "Matti Viljamaa" :

> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>

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


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

Re: [PD] How does n-Track Studio manage to get past the "single instance" problem of Pure Data?

[Matti Viljamaa]

http://forum.pdpatchrepo.info/topic/9664/pure-data-vst3-in-n-track-studio-beta-8-based-on-libpd/2
 


Here it’s claimed to involve n-Track Bridge?

Any guesses what’s it about?

> On 23 Feb 2016, at 03:28, Matti Viljamaa  wrote:
> 
> So I found out today that n-Track has a working PdVST implementation that 
> handles multiple instances as well as generates very nice GUIs.
> 
> How do they manage the multiple instance, if it’s a limitation in Pure Data? 
> Any ideas?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

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

[PD] How does N-track manage to get past the "single instance" problem of Pure Data?

[Matti Viljamaa]

So I found out today that N-track has a working PdVST implementation that 
handles multiple instances as well as generates very nice GUIs.

How do they manage the multiple instance, if it’s a limitation in Pure Data? 
Any ideas?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Morten Minothi Kristiansen]

Not tried different builds, please giide me.
23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" :

> Its been like this with Mavericks, Yosemite and El capitalist. Pd extended
> 0.43. I did a clean install a week ago and it worked fine for a week until
> I installed live 9. It still worked until it suddenly hit some kond of wall
> again.
>
> Mort
> 23. feb. 2016 02.15 skrev "AP Vague" :
>
>> Woah, that's definitely a problem I haven't heard of... I'm guessing
>> you've already tried using different builds. What OS are you on?
>>
>> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
>> mino...@gmail.com> wrote:
>>
>>> On my last two comouters PD wont open unless I start it with a
>>> standalone patch I made long ago. It works for a little while, then crashes
>>> completely and for ever more...unless I use the stand alone. Recently...5
>>> min before a gig the standalone wouldnt even start. The gig was fine as Im
>>> nott 100% relying on pd, but I have lost faith in PD EXTENDED and wish
>>> someone could have helped me earlier with this. I have posted and searched
>>> for answears, but didnt get nothing back. Aaaarrrhhh!!!
>>>
>>> I would mayyybe make a few more attempts if only someone serious would
>>> help me out with this and fix the problem, but thats yet to be the case.
>>>
>>> Ok... sorry about the rant. Had to get it out and now Im moving on with
>>> Max.
>>>
>>> Yebo
>>> Morten
>>> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>>>
 Perhaps a bit of broad question, but I find it interesting in order to
 speculate about future additions.

 How do you think Pure Data is limited?
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management ->
 http://lists.puredata.info/listinfo/pd-list

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

Re: [PD] How's Pd limited?

[Morten Minothi Kristiansen]

Its been like this with Mavericks, Yosemite and El capitalist. Pd extended
0.43. I did a clean install a week ago and it worked fine for a week until
I installed live 9. It still worked until it suddenly hit some kond of wall
again.

Mort
23. feb. 2016 02.15 skrev "AP Vague" :

> Woah, that's definitely a problem I haven't heard of... I'm guessing
> you've already tried using different builds. What OS are you on?
>
> On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
> mino...@gmail.com> wrote:
>
>> On my last two comouters PD wont open unless I start it with a standalone
>> patch I made long ago. It works for a little while, then crashes completely
>> and for ever more...unless I use the stand alone. Recently...5 min before a
>> gig the standalone wouldnt even start. The gig was fine as Im nott 100%
>> relying on pd, but I have lost faith in PD EXTENDED and wish someone could
>> have helped me earlier with this. I have posted and searched for answears,
>> but didnt get nothing back. Aaaarrrhhh!!!
>>
>> I would mayyybe make a few more attempts if only someone serious would
>> help me out with this and fix the problem, but thats yet to be the case.
>>
>> Ok... sorry about the rant. Had to get it out and now Im moving on with
>> Max.
>>
>> Yebo
>> Morten
>> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>>
>>> Perhaps a bit of broad question, but I find it interesting in order to
>>> speculate about future additions.
>>>
>>> How do you think Pure Data is limited?
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[AP Vague]

Woah, that's definitely a problem I haven't heard of... I'm guessing you've
already tried using different builds. What OS are you on?

On Mon, Feb 22, 2016 at 7:07 PM, Morten Minothi Kristiansen <
mino...@gmail.com> wrote:

> On my last two comouters PD wont open unless I start it with a standalone
> patch I made long ago. It works for a little while, then crashes completely
> and for ever more...unless I use the stand alone. Recently...5 min before a
> gig the standalone wouldnt even start. The gig was fine as Im nott 100%
> relying on pd, but I have lost faith in PD EXTENDED and wish someone could
> have helped me earlier with this. I have posted and searched for answears,
> but didnt get nothing back. Aaaarrrhhh!!!
>
> I would mayyybe make a few more attempts if only someone serious would
> help me out with this and fix the problem, but thats yet to be the case.
>
> Ok... sorry about the rant. Had to get it out and now Im moving on with
> Max.
>
> Yebo
> Morten
> 22. feb. 2016 02.52 skrev "Matti Viljamaa" :
>
>> Perhaps a bit of broad question, but I find it interesting in order to
>> speculate about future additions.
>>
>> How do you think Pure Data is limited?
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Morten Minothi Kristiansen]

On my last two comouters PD wont open unless I start it with a standalone
patch I made long ago. It works for a little while, then crashes completely
and for ever more...unless I use the stand alone. Recently...5 min before a
gig the standalone wouldnt even start. The gig was fine as Im nott 100%
relying on pd, but I have lost faith in PD EXTENDED and wish someone could
have helped me earlier with this. I have posted and searched for answears,
but didnt get nothing back. Aaaarrrhhh!!!

I would mayyybe make a few more attempts if only someone serious would help
me out with this and fix the problem, but thats yet to be the case.

Ok... sorry about the rant. Had to get it out and now Im moving on with
Max.

Yebo
Morten
22. feb. 2016 02.52 skrev "Matti Viljamaa" :

> Perhaps a bit of broad question, but I find it interesting in order to
> speculate about future additions.
>
> How do you think Pure Data is limited?
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

> It's just that the presence of those features makes it much easier not to 
> care, and many users just don't care, and it makes things worse for those of 
> us who have to use that patch elsewhere.
Short story: I'm not going to write the code to implement segmented cords, and 
I don't think anyone else is, either.  But if someone wants to I'll certainly 
have 
a look.
 
Long story:
Non-segmented patch cords suggest a flow chart.  Segmented patch cords-- 
when used sensibly-- suggest a circuit board.  The difference IMO is nobody in 
their right mind would suggest circuit boards are an especially readable and 
friendly way to elucidate a program's logic to human beings.  That's the 
starting 
premise of every "flow based" language, though, and I've never seen much 
evidence to back it up.

All those awful-looking yet functional Pd and Max patches get that way 
because of the strength of the approach, IMO-- that is, a physical motion with 
visual animated feedback creates the flow of data.  It's the drawing of the 
patch matters, not the engraving.
For example, imagine that Pd tracked Dan's eye movement on the first 
version of his patch.  Those objects and wires that he hasn't looked at for 
awhile fade more and more into the background, unless he tries to focus 
on one of them and then they return.  I think that's a pretty decent 
description 
of how we actually create those write-only patches.  Throw in whatever the 
opposite of MVC is (e.g., where a toggle can appear smack dab in the model), 
and you have an environment that's well suited to quick prototyping.
Of course that mental model has a short shelf-life, so there's the separate 
issue of how to turn that into a readable patch.  There are certainly patterns 
to follow there, and ways to minimize the spaghetti in the first place.  But I 
think that potential to draw big ugly lines across the whole damn thing is what 
drives the speed and elegance of developing in the language.  If it weren't 
then Pd 
would be like brainfuck, and none of those spaghetti patches would be able to 
deliver any functionality to speak of.
 
 So for those users who don't care about taking their patches (or, hopefully, 
small abstractions or subpatches) from 
"draw-time ugly-mode" to "presentable-to-other-humans mode", I don't think 
segmented cords matter much.  For the ones who do, I guess I'd rather look at 
a flow chart than a circuit board.  But given the choice I'd rather watch 
little 
gremlins carry buckets of water up a hill, or robots shooting lasers at drones. 
 
Or at least see the data "pumping" through all those boring control wires that 
seem to always obscure the text I'm trying to read...
-Jonathan



   

 On Monday, February 22, 2016 5:20 PM, Matt Barber  wrote:
 

 Hi all,
Forcing good practice is not something I'm interested in. Every programming 
language can be abused horribly (they even have a prize for best/worst abuse of 
C -- look through some of these http://www.ioccc.org/years.html ).
My point was not that avoiding segmented and hideable patch cords fixes these 
problems. It's just that the presence of those features makes it much easier 
not to care, and many users just don't care, and it makes things worse for 
those of us who have to use that patch elsewhere.
We did have a long list discussion about best practices, actually, collected 
here:
https://puredata.info/docs/style-guide/PrimordialStyleGuide/

There are other style guides too.
On Mon, Feb 22, 2016 at 4:29 PM, Dan Wilcox  wrote:



2016-02-22 17:25 GMT-03:00 Matt Barber :

I've said this before, but I think there are very good reasons not to ever 
include segmented patch cords (although hideable patch cords would be even 
worse). These two features are responsible for some of the very worst patching 
habits in Max/MSP. Have you ever been called on to run someone's patch, and you 
need to tweak something for your specific audio setup or fix a bug or whatever, 
and when you open it you get something that looks like this (one of the first 
"max patch" results on google image search):
http://www.letatoubleu.com/OLcomposer_files/image001.jpg


I agree, and I laugh when people say, this is hard to understand in Max, 
because of all the cords, I can't imagine how ugly it'd be in Pd.


The solution is the same in both environments: good use of encapsulation via 
subpatches & judicious use of send/recvs when necessary.
Example from robotcowboy:
* one of my first performance patches: 
https://www.flickr.com/photos/danomatika/25082084442/in/datetaken-public/* and 
the second version using subpatches & send/recvs: 
https://www.flickr.com/photos/danomatika/24573539133/in/datetaken-public/
This approach led to using GOP and modularizing things between separate patches 
& a main control patch: 
https://www.flickr.com/photos/danomatika/25107115651/in/datetaken-public/
To segment or not to segment is moot, you can create both well 

Re: [PD] How's Pd limited?

[Peter Nyboer]

I also dislike Send and Receive, but end up using them in pd. I don’t like that 
they are hard to keep track of (I see the receive, where’s the send?). I guess 
$0 does clear up the global issues, but it feels hacky. I managed to get rid of 
them in Max by relying on the pattr and pattrstorage objects to send messages 
around. Probably a bit slower, but it ended up being much cleaner.



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

Re: [PD] How's Pd limited?

[Dan Wilcox]

> On Feb 22, 2016, at 2:09 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Eugene Lazarchik  >
> 
> I consider sends and receives evil. They're similar to global variables or 
> goto statements in general purpose programming languages.

However they are extremely useful when used well, especially in conjunction 
with $0. I don’t quite get the goto comparison here. Goto is a low level 
execution construct while send/receives is a higher level abstraction. I tech 
them as “named, invisible patch cords”.

> When you see a receive object, it's not obvious where all corresponding sends 
> may be. As opposed to simply following where the cords go.

The find menu is your friend here but of course one shouldn’t use send/receives 
for *everything*. I prefer to use patch chords as much as possible but their 
are times, especially when using GOP where send/receives make things not only 
more readable but *easier* to understand IMO. This, of course, is a style 
preference.

Also, libpd and both PdParty & PdDroidParty *rely* on send/receives for both 
inter app communication as well as  their UI implementations.

> Also, consider a subpatch (or abstraction), with certain cords connected to 
> it. In a way the inlets and outlets describe how this object can be used: it 
> can receive certain messages through inlets and then send output to the 
> outlets. But if there's sends and receives inside, it becomes much harder to 
> track what the object may do.

That’s a patching design issue and not a problem in the language/environment. 
If sends & receives are not used willy nilly, including ridiculous fanouts, 
there’s generally not too much of a problem, especially if a patch is 
documented.

> In regards to the screenshot: it could be simplified by putting stuff into 
> subpatches. However, even when there's only a couple of objects on a 
> subpatch, the cords can still cross the objects if there's no way to segment 
> them. Typical reasons include long objects ([pd 
> $0-descriptive-name-of-the-subpatch], or [t a a a a a a a a] or [route this 
> and that], etc.). Also it's hard to avoid a mess without segmenting if 
> there's a lot of feedback connections (when A's output is connected to B but 
> also B's output is connected to A).

This is usually fixed by arranging things in a good order underneath the [t a a 
a a a a a a] and subpatching and/or fanning things out. Not impossible to make 
things easy to understand without overlapping lines.

I’ve picked up quite a few tricks by looking at patches made by a number of 
people on this list. Maybe what we need is a wiki pages with examples of good 
patching practice?

Also, simple segmenting can be accomplished via using [t a] objects when 
desired. 

> Also, moving functionality in a subpatch usually should only be done when 
> there's something common between the objects inside and they implement a 
> relatively siloed functionality. Otherwise it may be hard to understand what 
> the subpatch is doing and the reader will have to constantly switch between 
> the parent and the subpatch to understand how they work together.

Again, this is a patching design issue. I agree that subpatches should only 
encapsulate common actions but not implementing things this way is a fault of 
the person who made the patch.

I have been using the method of adding descriptions to my subpatch as well as 
inlet/outlet objects as they aren’t used by help in documenting what’s going on:

[pd bass synth]

[inlet midi note vel pair]

[outlet~ pitched down audio]

etc


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

Re: [PD] How's Pd limited?

[Dan Wilcox]

> 2016-02-22 17:25 GMT-03:00 Matt Barber  >:
> I've said this before, but I think there are very good reasons not to ever 
> include segmented patch cords (although hideable patch cords would be even 
> worse). These two features are responsible for some of the very worst 
> patching habits in Max/MSP. Have you ever been called on to run someone's 
> patch, and you need to tweak something for your specific audio setup or fix a 
> bug or whatever, and when you open it you get something that looks like this 
> (one of the first "max patch" results on google image search):
> 
> http://www.letatoubleu.com/OLcomposer_files/image001.jpg 
> 
> 
> 
> I agree, and I laugh when people say, this is hard to understand in Max, 
> because of all the cords, I can't imagine how ugly it'd be in Pd.



The solution is the same in both environments: good use of encapsulation via 
subpatches & judicious use of send/recvs when necessary.

Example from robotcowboy:

* one of my first performance patches: 
https://www.flickr.com/photos/danomatika/25082084442/in/datetaken-public/ 

* and the second version using subpatches & send/recvs: 
https://www.flickr.com/photos/danomatika/24573539133/in/datetaken-public/ 


This approach led to using GOP and modularizing things between separate patches 
& a main control patch: 
https://www.flickr.com/photos/danomatika/25107115651/in/datetaken-public/ 


To segment or not to segment is moot, you can create both well designed as well 
as spaghetti patches in either environment just as you can create well-written 
or spaghetti code in any textual language. I agree that the environments are 
not at fault here.


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

Re: [PD] How's Pd limited?

[Niklas Reppel]

Hmm i'd say there's no way to force people to employ transparent, modular 
software 
design as long as you want to keep the language (whether it's patcher- or 
code-based)
somewhat flexible and powerful ... 

On Mon, Feb 22, 2016 at 09:03:16PM +, Jonathan Wilkes via Pd-list wrote:
> There are plenty of Pd patches just as unreadable.
> 
> When a large number of users are getting value out of code that unreadable, we
> need to ask more fundamental questions than
> whether the visual noise includes more or fewer right angles.
> 
> -Jonathan
> 
> 
> 
> On Monday, February 22, 2016 3:25 PM, Matt Barber  wrote:
> 
> 
> I've said this before, but I think there are very good reasons not to ever
> include segmented patch cords (although hideable patch cords would be even
> worse). These two features are responsible for some of the very worst patching
> habits in Max/MSP. Have you ever been called on to run someone's patch, and 
> you
> need to tweak something for your specific audio setup or fix a bug or 
> whatever,
> and when you open it you get something that looks like this (one of the first
> "max patch" results on google image search):
> 
> http://www.letatoubleu.com/OLcomposer_files/image001.jpg
> 
> If you can't bend the cords there's much less of a temptation to make these
> kinds of can-of-worms patches, and more of an incentive to use send/receive
> when you need to get a value into an inconvenient place. There's also an
> incentive to make things more modular, which is usually far easier to debug
> than a huge sprawling patch. So while I can see where they'd be very useful if
> used judiciously, as someone who often has to operate someone else's patches,
> I'm very hesitant.
> 
> 
> On Mon, Feb 22, 2016 at 3:05 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
> 
> Hi Eugene,
> Great post!
> 
> I help develop pd-l2ork, and it addresses some of the points below.  I
> recently got it building on OSX with most of the pd-extended libraries.
> 
> I'll reply to each point below...
> 
> > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik <
> evgenius.lazarc...@gmail.com> wrote:
> 
> 
> > Where do I start?
> 
> > * Dynamic patching is officially not supported and bug/feature requests
> get ignored. I had to jump through a lot of hoops to use dynamic patching
> with GOP but I discovered a bunch of weird issues with subpatches not
> getting redrawn and connectors left hanging after object deletion. Had to
> build ugly hacks/workarounds since nobody's gonna fix the issues in PD.
> Sending loadbangs to dynamically created objects is a pain, as well as
> trying to dynamically connect them to something (most examples of using 
> the
> "connect" message use hardcoded object ID's).
> 
> GOP with dynamic patching is certainly tricky-- I find it way too
> complicated to be generally useful.  However, Pd-l2ork should work without
> bugs with
> GOPs.  Things get fixed there, and bug reports don't sit around for ten
> years.
> 
> As far as connect messages-- I have exposed the canvas "find" method 
> inside
> an object called [canvasinfo] in pd-l2ork.  It would be possible to write
> a set of abstractions to faciliate connections using object/abstraction
> names instead of indices.  But like GOP, dynamic patching is at its core
> pretty
> clunky so it would still be difficult to dynamically patch things
> (especially doing it live).
> 
> > * Support for lists is quite limited. Wanna create a multidimentional
> array? Build your own. Want a hash map? Build your own. Luckily there's
> list-abs but it's weird that such basic functionality (that's present in
> most programming languages) is not a core language feature.
> 
> Data structures have support for multi-dimensional arrays.  In Pd-l2ork 
> you
> can create a scalar in an object box which makes it slightly easier to
> use them.  But it's definitely more complex than using list-abs or the
> newer array objects for single-dimensional arrays.
> 
> > * Sends and receives are global which creates a potential for conflicts.
> $0 can be used to avoid that but it looks ugly and many libraries, 
> patches,
> and I think even help files, don't use it.
> 
> I agree that $0 is ugly.  I've got some locality using data structures 
> with
> a "canvas" field in upcoming Pd-l2ork release, but it's still very
> experimental.
> 
> Pd-l2ork has [preset_hub] and [preset_node] which handle locality without
> $0.  It works quite well, but it would be an _enormous_ undertaking to
> use that-- or any other design-- as a general replacement for wireless
> 
> > * Help files are *.pd which sounds neat at first, until you realize that
> they're not easily searchable and can't be viewed online.
> 
> They are searchable in Pd-l2ork, as well as the last version of 
> 

Re: [PD] How's Pd limited?

[Eugene Lazarchik]

I consider sends and receives evil. They're similar to global variables or
goto statements in general purpose programming languages.

When you see a receive object, it's not obvious where all corresponding
sends may be. As opposed to simply following where the cords go.

Also, consider a subpatch (or abstraction), with certain cords connected to
it. In a way the inlets and outlets describe how this object can be used:
it can receive certain messages through inlets and then send output to the
outlets. But if there's sends and receives inside, it becomes much harder
to track what the object may do.

In regards to the screenshot: it could be simplified by putting stuff into
subpatches. However, even when there's only a couple of objects on a
subpatch, the cords can still cross the objects if there's no way to
segment them. Typical reasons include long objects ([pd
$0-descriptive-name-of-the-subpatch], or [t a a a a a a a a] or [route this
and that], etc.). Also it's hard to avoid a mess without segmenting if
there's a lot of feedback connections (when A's output is connected to B
but also B's output is connected to A).

Also, moving functionality in a subpatch usually should only be done when
there's something common between the objects inside and they implement a
relatively siloed functionality. Otherwise it may be hard to understand
what the subpatch is doing and the reader will have to constantly switch
between the parent and the subpatch to understand how they work together.

On Mon, Feb 22, 2016 at 12:25 PM, Matt Barber  wrote:

> I've said this before, but I think there are very good reasons not to ever
> include segmented patch cords (although hideable patch cords would be even
> worse). These two features are responsible for some of the very worst
> patching habits in Max/MSP. Have you ever been called on to run someone's
> patch, and you need to tweak something for your specific audio setup or fix
> a bug or whatever, and when you open it you get something that looks like
> this (one of the first "max patch" results on google image search):
>
> http://www.letatoubleu.com/OLcomposer_files/image001.jpg
>
> If you can't bend the cords there's much less of a temptation to make
> these kinds of can-of-worms patches, and more of an incentive to use
> send/receive when you need to get a value into an inconvenient place.
> There's also an incentive to make things more modular, which is usually far
> easier to debug than a huge sprawling patch. So while I can see where
> they'd be very useful if used judiciously, as someone who often has to
> operate someone else's patches, I'm very hesitant.
>
>
> On Mon, Feb 22, 2016 at 3:05 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
>
>> Hi Eugene,
>> Great post!
>>
>> I help develop pd-l2ork, and it addresses some of the points below.  I
>> recently got it building on OSX with most of the pd-extended libraries.
>>
>> I'll reply to each point below...
>>
>> > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik <
>> evgenius.lazarc...@gmail.com> wrote:
>>
>>
>> > Where do I start?
>>
>> > * Dynamic patching is officially not supported and bug/feature requests
>> get ignored. I had to jump through a lot of hoops to use dynamic patching
>> with GOP but I discovered a bunch of weird issues with subpatches not
>> getting redrawn and connectors left hanging after object deletion. Had to
>> build ugly hacks/workarounds since nobody's gonna fix the issues in PD.
>> Sending loadbangs to dynamically created objects is a pain, as well as
>> trying to dynamically connect them to something (most examples of using the
>> "connect" message use hardcoded object ID's).
>>
>> GOP with dynamic patching is certainly tricky-- I find it way too
>> complicated to be generally useful.  However, Pd-l2ork should work without
>> bugs with
>> GOPs.  Things get fixed there, and bug reports don't sit around for ten
>> years.
>>
>> As far as connect messages-- I have exposed the canvas "find" method
>> inside an object called [canvasinfo] in pd-l2ork.  It would be possible to
>> write
>> a set of abstractions to faciliate connections using object/abstraction
>> names instead of indices.  But like GOP, dynamic patching is at its core
>> pretty
>> clunky so it would still be difficult to dynamically patch things
>> (especially doing it live).
>>
>> > * Support for lists is quite limited. Wanna create a multidimentional
>> array? Build your own. Want a hash map? Build your own. Luckily there's
>> list-abs but it's weird that such basic functionality (that's present in
>> most programming languages) is not a core language feature.
>>
>> Data structures have support for multi-dimensional arrays.  In Pd-l2ork
>> you can create a scalar in an object box which makes it slightly easier to
>> use them.  But it's definitely more complex than using list-abs or the
>> newer array objects for single-dimensional arrays.
>>
>> > * Sends and receives are global which 

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

There are plenty of Pd patches just as unreadable.
When a large number of users are getting value out of code that unreadable, we 
need to ask more fundamental questions than 
whether the visual noise includes more or fewer right angles.
-Jonathan



On Monday, February 22, 2016 3:25 PM, Matt Barber  
wrote:
 

 I've said this before, but I think there are very good reasons not to ever 
include segmented patch cords (although hideable patch cords would be even 
worse). These two features are responsible for some of the very worst patching 
habits in Max/MSP. Have you ever been called on to run someone's patch, and you 
need to tweak something for your specific audio setup or fix a bug or whatever, 
and when you open it you get something that looks like this (one of the first 
"max patch" results on google image search):
http://www.letatoubleu.com/OLcomposer_files/image001.jpg
If you can't bend the cords there's much less of a temptation to make these 
kinds of can-of-worms patches, and more of an incentive to use send/receive 
when you need to get a value into an inconvenient place. There's also an 
incentive to make things more modular, which is usually far easier to debug 
than a huge sprawling patch. So while I can see where they'd be very useful if 
used judiciously, as someone who often has to operate someone else's patches, 
I'm very hesitant.

On Mon, Feb 22, 2016 at 3:05 PM, Jonathan Wilkes via Pd-list 
 wrote:

Hi Eugene,Great post!
I help develop pd-l2ork, and it addresses some of the points below.  I recently 
got it building on OSX with most of the pd-extended libraries.

I'll reply to each point below...
   
 > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik 
 >  wrote:
 

 > Where do I start?

> * Dynamic patching is officially not supported and bug/feature requests get 
> ignored. I had to jump through a lot of hoops to use dynamic patching with 
> GOP but I discovered a bunch of weird issues with subpatches not getting 
> redrawn and connectors left hanging after object deletion. Had to build ugly 
> hacks/workarounds since nobody's gonna fix the issues in PD. Sending 
> loadbangs to dynamically created objects is a pain, as well as trying to 
> dynamically connect them to something (most examples of using the "connect" 
> message use hardcoded object ID's).
GOP with dynamic patching is certainly tricky-- I find it way too complicated 
to be generally useful.  However, Pd-l2ork should work without bugs with 
GOPs.  Things get fixed there, and bug reports don't sit around for ten years.
As far as connect messages-- I have exposed the canvas "find" method inside an 
object called [canvasinfo] in pd-l2ork.  It would be possible to write 
a set of abstractions to faciliate connections using object/abstraction names 
instead of indices.  But like GOP, dynamic patching is at its core pretty 
clunky so it would still be difficult to dynamically patch things (especially 
doing it live).

> * Support for lists is quite limited. Wanna create a multidimentional array? 
> Build your own. Want a hash map? Build your own. Luckily there's list-abs but 
> it's weird that such basic functionality (that's present in most programming 
> languages) is not a core language feature.
Data structures have support for multi-dimensional arrays.  In Pd-l2ork you can 
create a scalar in an object box which makes it slightly easier to 
use them.  But it's definitely more complex than using list-abs or the newer 
array objects for single-dimensional arrays.

> * Sends and receives are global which creates a potential for conflicts. $0 
> can be used to avoid that but it looks ugly and many libraries, patches, and 
> I think even help files, don't use it.
I agree that $0 is ugly.  I've got some locality using data structures with a 
"canvas" field in upcoming Pd-l2ork release, but it's still very experimental.
Pd-l2ork has [preset_hub] and [preset_node] which handle locality without $0.  
It works quite well, but it would be an _enormous_ undertaking to 
use that-- or any other design-- as a general replacement for wireless

> * Help files are *.pd which sounds neat at first, until you realize that 
> they're not easily searchable and can't be viewed online.
They are searchable in Pd-l2ork, as well as the last version of Pd-extended (I 
think).  In the upcoming version of Pd-l2ork the help browser indexes the 
doc folder in less than a second.  I'm just indexing the keywords in [pd 
META]-- it could index full text too but that turns out not to improve the 
results
very much.  But it's possible to do serious tweaks, save/load/ship an index, 
etc. if someone wants to take it on.

> * Bugs and weird behavior when handling special characters. There's no 
> consistent way of escaping them. Sometimes characters disappear when saving 
> and loading a patch.
I gutted all the tcl commands from the GUI calls for Pd-l2ork, so theoretically 
it 

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

2016-02-22 17:25 GMT-03:00 Matt Barber :

> I've said this before, but I think there are very good reasons not to ever
> include segmented patch cords (although hideable patch cords would be even
> worse). These two features are responsible for some of the very worst
> patching habits in Max/MSP. Have you ever been called on to run someone's
> patch, and you need to tweak something for your specific audio setup or fix
> a bug or whatever, and when you open it you get something that looks like
> this (one of the first "max patch" results on google image search):
>
> http://www.letatoubleu.com/OLcomposer_files/image001.jpg
>
>
I agree, and I laugh when people say, this is hard to understand in Max,
because of all the cords, I can't imagine how ugly it'd be in Pd.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] How's Pd (is not) limited?

[jamal crawford]

hi list

>* Support for lists is quite limited. Wanna create a multidimentional
>  array? Build your own. Want a hash map? Build your own.

"its not a bug, its a feature" :P

> * Standard GUI objects are ugly 

thats a matter of taste matey. i think osx and dem abbles are *really*
ugly products

>* PD community uses mailing lists for communications, haha. In order to
>  find useful information I have to view one message per page, with
>  tons of distracting quotes from previous messages.

... and thats the beauty of it, the more you dive, the more you learn...

oi



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

Re: [PD] How's Pd limited?

[Jonathan Wilkes via Pd-list]

Hi Eugene,Great post!
I help develop pd-l2ork, and it addresses some of the points below.  I recently 
got it building on OSX with most of the pd-extended libraries.

I'll reply to each point below...
   
 > On Monday, February 22, 2016 4:21 AM, Eugene Lazarchik 
 >  wrote:
 

 > Where do I start?

> * Dynamic patching is officially not supported and bug/feature requests get 
> ignored. I had to jump through a lot of hoops to use dynamic patching with 
> GOP but I discovered a bunch of weird issues with subpatches not getting 
> redrawn and connectors left hanging after object deletion. Had to build ugly 
> hacks/workarounds since nobody's gonna fix the issues in PD. Sending 
> loadbangs to dynamically created objects is a pain, as well as trying to 
> dynamically connect them to something (most examples of using the "connect" 
> message use hardcoded object ID's).
GOP with dynamic patching is certainly tricky-- I find it way too complicated 
to be generally useful.  However, Pd-l2ork should work without bugs with 
GOPs.  Things get fixed there, and bug reports don't sit around for ten years.
As far as connect messages-- I have exposed the canvas "find" method inside an 
object called [canvasinfo] in pd-l2ork.  It would be possible to write 
a set of abstractions to faciliate connections using object/abstraction names 
instead of indices.  But like GOP, dynamic patching is at its core pretty 
clunky so it would still be difficult to dynamically patch things (especially 
doing it live).

> * Support for lists is quite limited. Wanna create a multidimentional array? 
> Build your own. Want a hash map? Build your own. Luckily there's list-abs but 
> it's weird that such basic functionality (that's present in most programming 
> languages) is not a core language feature.
Data structures have support for multi-dimensional arrays.  In Pd-l2ork you can 
create a scalar in an object box which makes it slightly easier to 
use them.  But it's definitely more complex than using list-abs or the newer 
array objects for single-dimensional arrays.

> * Sends and receives are global which creates a potential for conflicts. $0 
> can be used to avoid that but it looks ugly and many libraries, patches, and 
> I think even help files, don't use it.
I agree that $0 is ugly.  I've got some locality using data structures with a 
"canvas" field in upcoming Pd-l2ork release, but it's still very experimental.
Pd-l2ork has [preset_hub] and [preset_node] which handle locality without $0.  
It works quite well, but it would be an _enormous_ undertaking to 
use that-- or any other design-- as a general replacement for wireless

> * Help files are *.pd which sounds neat at first, until you realize that 
> they're not easily searchable and can't be viewed online.
They are searchable in Pd-l2ork, as well as the last version of Pd-extended (I 
think).  In the upcoming version of Pd-l2ork the help browser indexes the 
doc folder in less than a second.  I'm just indexing the keywords in [pd 
META]-- it could index full text too but that turns out not to improve the 
results
very much.  But it's possible to do serious tweaks, save/load/ship an index, 
etc. if someone wants to take it on.

> * Bugs and weird behavior when handling special characters. There's no 
> consistent way of escaping them. Sometimes characters disappear when saving 
> and loading a patch.
I gutted all the tcl commands from the GUI calls for Pd-l2ork, so theoretically 
it should be way easier to handle special characters now.  But I have to 
admit I'm using some low value ASCII code to delimit messages to the GUI.  It's 
just way easier to split on a single byte as opposed to, say, the 
semicolons that aren't preceded by a slash.
Still, there is a lot of work to make sure special characters and spaces get 
saved correctly within Pd.  It needs a lot of testing by a developer who 
knows all the ins and outs of how to read/write/revise a parser, plus knowing 
exactly how those changes will affect past and future Pd patches (both 
in terms of the running instance and saving/loading patches).

> * Limited support for comments. Special characters are not allowed (really? 
> these are comments!). Automatic line wrapping doesn't work well since after 
> saving/loading a patch often changes how text is broken into lines. So I have 
> to put each line as a separate comment.
I think Ivica added support for saving newlines inside comments (as above, it 
uses a hack to deal with special characters).  But they still get parsed-- 
that's bad, although Pd isn't the only language that does that.

> * Dependence on font sizes. By default object boxes scale automatically 
> depending on the text inside. When you add more text, all inlets/outlets 
> move. I installed a different version of PD and font size is slightly 
> different and all objects are of a different size now.
This is a hard problem. The only solution I know of is to draw an extra border 
in 

Re: [PD] Cyclone future

[Dan Wilcox]

> On Feb 22, 2016, at 10:33 AM, Alexandre Torres Porres  
> wrote:
> 
> That's what's happening! It's from 0.2beta1 and on, not 0.1-Alpha56, I was 
> just trying to be accurate in the genealogy of repositories. Fred did a great 
> amount of work departing from 0.1-Alpha56 - available in Extended and in this 
> original repository 
> https://git.puredata.info/cgit/svn2git/libraries/miXed.git/ 
>  - he forked it 
> to https://github.com/electrickery/pd-cyclone 
>  and started working on it. A 
> 0.1-Alpha57 is also available and was provided by him, but this is marked as 
> "unreleased" in the puredata.info  website and only 
> the 0.2beta1 (current state of his repo) is now available via deken.

Ah ok. Just checking :) I saw the “pd-extended” part and it seemed like you 
were starting from that version.

> By the way, I also think there are lessons to be learned, and I have to admit 
> I'm not used to dealing and negotiating in a collaboration of free software 
> like this. I'm really unaware of the common practice regarding ethics, 
> politics, etiquete and all. I hope to learn from this episode and you all, 
> and I also hope you can cope with me eventually not knowing better, any 
> constructive criticism of  any of my actions are hihgly welcome. thanks…


We all appreciate your enthusiasm, don’t get me wrong. Collaborating on open 
source, in some ways, requires collaborating more with the people and their 
interests/schedules themselves than on company projects where the hierarchy and 
management is strictly enforced. Not everyone is supported by an institution in 
this work and most contribute when they can in their “free” time. For better or 
worse, work tends toward areas of personal interest and direct collaborations 
occur at overlaps. People will volunteer to take up work on something but they 
are of course free to drop it at any time.

It’s more of an anarchistic collaboration where, when we have enough people and 
enough energy to overlap the areas that need work, we can get a lot done. 
Problems arise when there isn’t enough time/energy/people to cover everything 
and things narrow down to individuals suddenly feeling inundated with bugs & 
feature requests. In this case, it’s best to pitch in by asking questions as to 
“where and how can I help”, then providing ideas, examples, & code.

I immediately think of deken. There were many *long* discussions about the 
future of pd and pd-extended that essentially boiled down to: "we need to do 
something" & "nobody will probably work on extended". The first conclusion was 
obvious & the second conclusion came from essentially everyone waiting for 
everyone else to start “working on pd-extended”. That didn’t happen, so more 
*long* discussions ensued that reiterated the first conclusion.

In the mean time, a set of developers started working on some example tools, 
taking into account their views towards the discussion of “we need to do 
something.” This work resulted in pd-lib-builder (make externals easy to build 
outside of pd-extended) and deken (make externals easy to install on pd 
vanilla). Once both projects were released for testing, the discussion changed 
from theory to practice and many improvements have taken place since. We now 
have a direction forward. (Giant thanks to everyone involved!)

I’m not saying discussion itself is unwanted, just the kind that starts getting 
cyclical and draining. Sometimes, you’ve got to put the code up to prove/test a 
point that others can join in on. Convince via example as opposed to convince 
via debate. A great example of this is the frequent patch trading that happens 
after someone asks “what’s the best way to XYZ in pd?” In some ways, working on 
externals and pd itself happens in the same manner, it’s just a little more 
difficult to write & share the TCL/TK & C code.

In any case, we’re all here because we believe in open source and pure data. We 
don’t agree on everything, but we work to find areas of agreement and move 
forward.


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

Re: [PD] Cyclone future

[Alexandre Torres Porres]

>
> On Feb 21, 2016, at 10:14 PM, pd-list-requ...@lists.iem.at wrote:
>
> The repo is a fork from the last update in previous maintenance (cyclone
> version 0.2beta1), which was on its own a fork from cyclone's repo for
> version 0.1-Alpha56 (available in Pd Extended).
>
>
> Fred did a large amount of work in bring cyclone forward, build-wise and
> bug wise. Why wouldn’t you start with his work? Seems like a step backwards
> after all of this...
>

That's what's happening! It's from 0.2beta1 and on, not 0.1-Alpha56, I was
just trying to be accurate in the genealogy of repositories. Fred did a
great amount of work departing from 0.1-Alpha56 - available in Extended and
in this original repository
https://git.puredata.info/cgit/svn2git/libraries/miXed.git/ - he forked it
to https://github.com/electrickery/pd-cyclone and started working on
it. A 0.1-Alpha57
is also available and was provided by him, but this is marked as
"unreleased" in the puredata.info website and only the 0.2beta1 (current
state of his repo) is now available via deken.

By the way, I also think there are lessons to be learned, and I have to
admit I'm not used to dealing and negotiating in a collaboration of free
software like this. I'm really unaware of the common practice regarding
ethics, politics, etiquete and all. I hope to learn from this episode and
you all, and I also hope you can cope with me eventually not knowing
better, any constructive criticism of  any of my actions are hihgly
welcome. thanks...

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

Re: [PD] Cyclone future

[Dan Wilcox]

> On 02/21/2016 08:35 PM, Fred Jan Kraan wrote:
>> This mail is the last I will write about cyclone in the foreseeable
>> future.
> 
> this is about the worst possible outcome of the entire discussion.

Exactly.

Discussions are great and all but discussions also involve listening to both 
sides. At some point, things seemed to go one sided. Developer burnout is a 
*huge* problem in open source so Fred’s concern about maintainability vs. 
extensibility is valid. Maybe that concern wasn’t quite coming through over 
email. I can personally say, OS developers tend to start getting into a 
situation were they work on things not because they are interested anymore but 
because they feel like they *have* to support the needs of others … for free. 
That’s where things get toxic and it’s sometimes hard to find a balance between 
the two.

I’m not trying to figure blame, etc, I’m trying to see what we can all learn 
from this unfortunate outcome.

Instead of consistently asking for Fred to integrate and increase his workload, 
the better course of action might have been to make a companion library that 
utilizes cyclone and begins adding functionality. Maybe start with abstractions 
and go from there? Putting up code and workable ideas always influences things 
more than "here’s a huge bug/feature list for one person to implement.” 
Oftentimes, if the work is good and the developer can see things are coming 
together nicely, talk begins about a possible integration with the base code 
base and direct collaboration. This has been the case in the OpenFramework 
community where a few addon libraries have been vetted and proven outside of 
the core code, then integrated later on.

That being said, the huge compatibility list a *great* resource and basis for 
organizing work for a number of people. Sometimes, QA is great help in defining 
what makes sense beyond the developer perspective. Throw that up on a wiki with 
checkboxes and bring your students in on a “make an external/abstraction 
party”. :)

> On Feb 21, 2016, at 10:14 PM, pd-list-requ...@lists.iem.at wrote:
> 
> The repo is a fork from the last update in previous maintenance (cyclone 
> version 0.2beta1), which was on its own a fork from cyclone's repo for 
> version 0.1-Alpha56 (available in Pd Extended).

Fred did a large amount of work in bring cyclone forward, build-wise and bug 
wise. Why wouldn’t you start with his work? Seems like a step backwards after 
all of this...


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 


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

Re: [PD] How's Pd limited?

[Niklas Reppel]

Well yeah lots of people jabber about how Max/MSP is an "industry 
standard" and how badly documented Pd is (which might have been true 10 
years ago,
but not today), and generally seem to be afraid of free software ... 
incidentially, most of those use a Mac ;)


About the comparison to SC, well, different tools for different jobs, i 
guess ?




On 22.02.2016 16:01, Alexandre Torres Porres wrote:

Or SC :)

2016-02-22 11:12 GMT-03:00 Matt Barber >:


Over the years, the most common complaint I've heard about Pd's
limitations is that it's not identical to Max/MSP.

On Mon, Feb 22, 2016 at 4:19 AM, Eugene Lazarchik
> wrote:

Where do I start?

* Dynamic patching is officially not supported and bug/feature
requests get ignored. I had to jump through a lot of hoops to
use dynamic patching with GOP but I discovered a bunch of
weird issues with subpatches not getting redrawn and
connectors left hanging after object deletion. Had to build
ugly hacks/workarounds since nobody's gonna fix the issues in
PD. Sending loadbangs to dynamically created objects is a
pain, as well as trying to dynamically connect them to
something (most examples of using the "connect" message use
hardcoded object ID's).
* Support for lists is quite limited. Wanna create a
multidimentional array? Build your own. Want a hash map? Build
your own. Luckily there's list-abs but it's weird that such
basic functionality (that's present in most programming
languages) is not a core language feature.
* Sends and receives are global which creates a potential for
conflicts. $0 can be used to avoid that but it looks ugly and
many libraries, patches, and I think even help files, don't
use it.
* Help files are *.pd which sounds neat at first, until you
realize that they're not easily searchable and can't be viewed
online.
* Bugs and weird behavior when handling special characters.
There's no consistent way of escaping them. Sometimes
characters disappear when saving and loading a patch.
* Limited support for comments. Special characters are not
allowed (really? these are comments!). Automatic line wrapping
doesn't work well since after saving/loading a patch often
changes how text is broken into lines. So I have to put each
line as a separate comment.
* Dependence on font sizes. By default object boxes scale
automatically depending on the text inside. When you add more
text, all inlets/outlets move. I installed a different version
of PD and font size is slightly different and all objects are
of a different size now.* Want to add an outlet to the
beginning of a trigger object? Enjoy disconnecting and
connecting all other outlets since there's no way of
automatically move them.
* Want to print all messages flowing through a connection for
debugging purposes? Remove the connection, then create a [t a
a] object, then create a [print] object, then connect [print]
to the second outlet, then connect [t a a] to the previous and
next object (If you don't use the [trigger], messages will
only be printed after they flow through the whole system).
After you're done, delete the objects and re-create the
connection. Not very convenient for quick debugging.
* Vanilla provides only minimal functionality while most of
the convenient objects are supposed to come from external
libraries. There's multiple issues with that. First one is
that libraries are less standardized and consistent. They have
different approaches, sometimes duplicate each other, use
different conventions for naming, inlets/outlets, etc. Second
issue is that libraries often become dead/unmaintained.
* Big patches/abstractions become unreadable really fast.
Connectors are always straight lines and there's no support
for dummy intermediate "points" for connecting stuff. I use [t
a] and [+~] for these purposes but it'd be nice to have native
support for this.
* Standard GUI objects are ugly and have limited functionality.
* There's no good support for the concept of
functions/procedures. Let's say we need to take some input, do
some transformations and produce output, and we need to do
that in multiple places in our patch. We can copy the objects
but that will make the patch use more memory and there will be
no code reuse. Another way is to make that an abstraction, but
it's silly to make abstractions for every little thing that we
need 

Re: [PD] How's Pd limited?

[Alexandre Torres Porres]

Or SC :)

2016-02-22 11:12 GMT-03:00 Matt Barber :

> Over the years, the most common complaint I've heard about Pd's
> limitations is that it's not identical to Max/MSP.
>
> On Mon, Feb 22, 2016 at 4:19 AM, Eugene Lazarchik <
> evgenius.lazarc...@gmail.com> wrote:
>
>> Where do I start?
>>
>> * Dynamic patching is officially not supported and bug/feature requests
>> get ignored. I had to jump through a lot of hoops to use dynamic patching
>> with GOP but I discovered a bunch of weird issues with subpatches not
>> getting redrawn and connectors left hanging after object deletion. Had to
>> build ugly hacks/workarounds since nobody's gonna fix the issues in PD.
>> Sending loadbangs to dynamically created objects is a pain, as well as
>> trying to dynamically connect them to something (most examples of using the
>> "connect" message use hardcoded object ID's).
>> * Support for lists is quite limited. Wanna create a multidimentional
>> array? Build your own. Want a hash map? Build your own. Luckily there's
>> list-abs but it's weird that such basic functionality (that's present in
>> most programming languages) is not a core language feature.
>> * Sends and receives are global which creates a potential for conflicts.
>> $0 can be used to avoid that but it looks ugly and many libraries, patches,
>> and I think even help files, don't use it.
>> * Help files are *.pd which sounds neat at first, until you realize that
>> they're not easily searchable and can't be viewed online.
>> * Bugs and weird behavior when handling special characters. There's no
>> consistent way of escaping them. Sometimes characters disappear when saving
>> and loading a patch.
>> * Limited support for comments. Special characters are not allowed
>> (really? these are comments!). Automatic line wrapping doesn't work well
>> since after saving/loading a patch often changes how text is broken into
>> lines. So I have to put each line as a separate comment.
>> * Dependence on font sizes. By default object boxes scale automatically
>> depending on the text inside. When you add more text, all inlets/outlets
>> move. I installed a different version of PD and font size is slightly
>> different and all objects are of a different size now.* Want to add an
>> outlet to the beginning of a trigger object? Enjoy disconnecting and
>> connecting all other outlets since there's no way of automatically move
>> them.
>> * Want to print all messages flowing through a connection for debugging
>> purposes? Remove the connection, then create a [t a a] object, then create
>> a [print] object, then connect [print] to the second outlet, then connect
>> [t a a] to the previous and next object (If you don't use the [trigger],
>> messages will only be printed after they flow through the whole system).
>> After you're done, delete the objects and re-create the connection. Not
>> very convenient for quick debugging.
>> * Vanilla provides only minimal functionality while most of the
>> convenient objects are supposed to come from external libraries. There's
>> multiple issues with that. First one is that libraries are less
>> standardized and consistent. They have different approaches, sometimes
>> duplicate each other, use different conventions for naming, inlets/outlets,
>> etc. Second issue is that libraries often become dead/unmaintained.
>> * Big patches/abstractions become unreadable really fast. Connectors are
>> always straight lines and there's no support for dummy intermediate
>> "points" for connecting stuff. I use [t a] and [+~] for these purposes but
>> it'd be nice to have native support for this.
>> * Standard GUI objects are ugly and have limited functionality.
>> * There's no good support for the concept of functions/procedures. Let's
>> say we need to take some input, do some transformations and produce output,
>> and we need to do that in multiple places in our patch. We can copy the
>> objects but that will make the patch use more memory and there will be no
>> code reuse. Another way is to make that an abstraction, but it's silly to
>> make abstractions for every little thing that we need in 2 places. Also,
>> instantiating 2 abstractions still uses more memory. We can try reusing the
>> same code but we'll have to make multiple output connections so we'll need
>> proper routing in order to figure out where to send the result. I made an
>> abstraction to simplify that but this should be a standard feature of PD.
>> * *.pd format is not very friendly to Git. Try viewing diffs and
>> resolving merge conflicts. Moving a subpatch on the screen causes different
>> coordinates to be saved in the file, often resulting in conflicts. Cutting
>> and pasting renumbers all objects and connections. This makes using
>> branches and working on the same files impractical.
>> * PD seems to be maintained by only a handful of people and new
>> features/bug fixes are rarely released. I used to code in C and was
>> thinking of contributing but I 

Re: [PD] How's Pd limited?

[Matt Barber]

Over the years, the most common complaint I've heard about Pd's limitations
is that it's not identical to Max/MSP.

On Mon, Feb 22, 2016 at 4:19 AM, Eugene Lazarchik <
evgenius.lazarc...@gmail.com> wrote:

> Where do I start?
>
> * Dynamic patching is officially not supported and bug/feature requests
> get ignored. I had to jump through a lot of hoops to use dynamic patching
> with GOP but I discovered a bunch of weird issues with subpatches not
> getting redrawn and connectors left hanging after object deletion. Had to
> build ugly hacks/workarounds since nobody's gonna fix the issues in PD.
> Sending loadbangs to dynamically created objects is a pain, as well as
> trying to dynamically connect them to something (most examples of using the
> "connect" message use hardcoded object ID's).
> * Support for lists is quite limited. Wanna create a multidimentional
> array? Build your own. Want a hash map? Build your own. Luckily there's
> list-abs but it's weird that such basic functionality (that's present in
> most programming languages) is not a core language feature.
> * Sends and receives are global which creates a potential for conflicts.
> $0 can be used to avoid that but it looks ugly and many libraries, patches,
> and I think even help files, don't use it.
> * Help files are *.pd which sounds neat at first, until you realize that
> they're not easily searchable and can't be viewed online.
> * Bugs and weird behavior when handling special characters. There's no
> consistent way of escaping them. Sometimes characters disappear when saving
> and loading a patch.
> * Limited support for comments. Special characters are not allowed
> (really? these are comments!). Automatic line wrapping doesn't work well
> since after saving/loading a patch often changes how text is broken into
> lines. So I have to put each line as a separate comment.
> * Dependence on font sizes. By default object boxes scale automatically
> depending on the text inside. When you add more text, all inlets/outlets
> move. I installed a different version of PD and font size is slightly
> different and all objects are of a different size now.* Want to add an
> outlet to the beginning of a trigger object? Enjoy disconnecting and
> connecting all other outlets since there's no way of automatically move
> them.
> * Want to print all messages flowing through a connection for debugging
> purposes? Remove the connection, then create a [t a a] object, then create
> a [print] object, then connect [print] to the second outlet, then connect
> [t a a] to the previous and next object (If you don't use the [trigger],
> messages will only be printed after they flow through the whole system).
> After you're done, delete the objects and re-create the connection. Not
> very convenient for quick debugging.
> * Vanilla provides only minimal functionality while most of the convenient
> objects are supposed to come from external libraries. There's multiple
> issues with that. First one is that libraries are less standardized and
> consistent. They have different approaches, sometimes duplicate each other,
> use different conventions for naming, inlets/outlets, etc. Second issue is
> that libraries often become dead/unmaintained.
> * Big patches/abstractions become unreadable really fast. Connectors are
> always straight lines and there's no support for dummy intermediate
> "points" for connecting stuff. I use [t a] and [+~] for these purposes but
> it'd be nice to have native support for this.
> * Standard GUI objects are ugly and have limited functionality.
> * There's no good support for the concept of functions/procedures. Let's
> say we need to take some input, do some transformations and produce output,
> and we need to do that in multiple places in our patch. We can copy the
> objects but that will make the patch use more memory and there will be no
> code reuse. Another way is to make that an abstraction, but it's silly to
> make abstractions for every little thing that we need in 2 places. Also,
> instantiating 2 abstractions still uses more memory. We can try reusing the
> same code but we'll have to make multiple output connections so we'll need
> proper routing in order to figure out where to send the result. I made an
> abstraction to simplify that but this should be a standard feature of PD.
> * *.pd format is not very friendly to Git. Try viewing diffs and resolving
> merge conflicts. Moving a subpatch on the screen causes different
> coordinates to be saved in the file, often resulting in conflicts. Cutting
> and pasting renumbers all objects and connections. This makes using
> branches and working on the same files impractical.
> * PD seems to be maintained by only a handful of people and new
> features/bug fixes are rarely released. I used to code in C and was
> thinking of contributing but I found no good guide for new contributors. I
> wasn't even able to compile PD on my Mac (there's multiple build scripts in
> the sources but none of them 

Re: [PD] one more filter

[patrice colet]

It's astounishing, this filter doesn't only sound like the SSM2040 chip, 
this patch also look like it's circuit implementation.

http://www.schmitzbits.de/rs2040.html

Le 22/02/2016 10:39, cyrille henry a écrit :

yes, thanks.
corrected on the svn.
cheers
c


Le 22/02/2016 08:06, i go bananas a écrit :
you need $0 prefacing the delwrite~_delread~ names, or otherwise you 
can't load multiple instances.


On Mon, Feb 22, 2016 at 3:55 PM, i go bananas > wrote:


oops, ignore that comment about the lowpass and bandpass modes 
not working.  It was my patching mistake.  sorry!





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



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

Re: [PD] [pix_image] available image format on linux?

[Jonghyun Kim]

On Mon, Feb 22, 2016 at 3:20 AM, IOhannes m zmölnig  wrote:

> $ sudo apt-get build-dep gem
>

Thanks a lot, IOhannes! I didn't know that. It's very important information
for me. For compiling puredata(vanilla and extended) is also:

$ sudo apt-get build-dep puredata
$ sudo apt-get build-dep pd-extended

Right?

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

Re: [PD] one more filter

[cyrille henry]

yes, thanks.
corrected on the svn.
cheers
c


Le 22/02/2016 08:06, i go bananas a écrit :

you need $0 prefacing the delwrite~_delread~ names, or otherwise you can't load 
multiple instances.

On Mon, Feb 22, 2016 at 3:55 PM, i go bananas > wrote:

oops, ignore that comment about the lowpass and bandpass modes not working. 
 It was my patching mistake.  sorry!




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

Re: [PD] one more filter

[cyrille henry]

Le 22/02/2016 06:31, i go bananas a écrit :

looks great!  thanks.

just noticed that the highpass output is too hot.  instead of multiplying the 
distortion outputs by [1, -2, 1, 0, 0 ] , you need to multiply by [0.5, -1, 
0.5, 0, 0], then you get the same amplitude for the highpass as the other modes.



If you put the filter on high pass and use a low cuttoff so that everything is 
passing throw the filter, then the original coefficient result in 0db gain 
between the input and the output of the filter.
So, they look ok to me.
 


I'm gonna see what it sounds like to morph between filter modes with a line~ 
sweep.  Hopefully it will work somewhat.

yes, it should.

cheers
c



Matt

On Sat, Feb 20, 2016 at 5:12 AM, Simon Iten > wrote:

sounds great!!!

thanks for sharing.

 > On 19 Feb 2016, at 20:06, cyrille henry > wrote:
 >
 > 


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




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