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?
Hmm, i always thought that the dynamic creation and destruction of sound sources (oscillators etc.) pretty inconvenient in PD, compared to a source-code based approach.
Maybe i missed some developments here, but the last time i checked (a year ago maybe), this was clearly quite a hassle, even though i know it's possible.
On Mon, Feb 22, 2016 at 03:49:43AM +0200, 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
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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
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
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 < minothi@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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
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
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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
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
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" minothi@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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
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
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" <minothi@gmail.com
:
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <minothi@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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
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
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" < minothi@gmail.com>:
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <minothi@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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
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
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 emviveros@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" < minothi@gmail.com>:
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" < minothi@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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
> 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
Em ter, 23 de fev de 2016 às 00:56, Matt Barber brbrofsvl@gmail.com 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 emviveros@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" < minothi@gmail.com>:
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" < minothi@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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!! > > 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" mviljamaa@kapsi.fi: > >> 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
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 emviveros@gmail.com escreveu:
Em ter, 23 de fev de 2016 às 00:56, Matt Barber brbrofsvl@gmail.com 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 emviveros@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" < minothi@gmail.com>:
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" < minothi@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" apvague@gmail.com:
> 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 < > minothi@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. Aaaarrrgggghhh!!! >> >> 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" mviljamaa@kapsi.fi: >> >>> 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
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 <emviveros@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" minothi@gmail.com:
Not tried different builds, please giide me.23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" minothi@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.Mort23. feb. 2016 02.15 skrev "AP Vague" apvague@gmail.com:
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 minothi@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. Aaaarrrgggghhh!!! 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" mviljamaa@kapsi.fi:
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
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 <jancsika@yahoo.com> 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 <emviveros@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" minothi@gmail.com:
Not tried different builds, please giide me.23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" minothi@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.Mort23. feb. 2016 02.15 skrev "AP Vague" apvague@gmail.com:
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 minothi@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. Aaaarrrgggghhh!!! 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" mviljamaa@kapsi.fi:
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
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 jancsika@yahoo.com 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 jancsika@yahoo.com 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 < emviveros@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" < minothi@gmail.com>:
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <minothi@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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!! 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" mviljamaa@kapsi.fi:
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
Align: https://youtu.be/lCIeIelbw74
Looks like there's a whole collection of tools to do that, including a transient bbox with drag hooks.
Route Patch Cords: https://youtu.be/2u_UJQ8OfvUI%27m pretty sure Pd-l2ork can do the first part of that video. But it can also do a many-to-one auto-connection which is
more ergonomic.
On Tuesday, February 23, 2016 1:13 AM, Esteban Viveros <emviveros@gmail.com> wrote:
Like that: Align: https://youtu.be/lCIeIelbw74Route Patch Cords: https://youtu.be/2u_UJQ8OfvU
Em ter, 23 de fev de 2016 às 02:09, Jonathan Wilkes jancsika@yahoo.com 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 <jancsika@yahoo.com> 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 <emviveros@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" minothi@gmail.com:
Not tried different builds, please giide me.23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" minothi@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.Mort23. feb. 2016 02.15 skrev "AP Vague" apvague@gmail.com:
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 minothi@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. Aaaarrrgggghhh!!! 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" mviljamaa@kapsi.fi:
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
On 2/22/2016 11:40 PM, Jonathan Wilkes via Pd-list 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.
This is because in pd-l2ork first press on tidy up aligns objects to the closest axis. This can sometimes make objects overlap, even though they are aligned across a desired axis (e.g. if you duplicate an object a couple times and then try to align it with duplicated objects). That is why there is the second press which spaces out objects according to the shortest space between them unless the shortest space is an actual overlap in which case it respaces it by a default spacing value that is applied to the right side of the object to the left. Now, if you can understand what I wrote in one read, go get yourself (if age < 21 && location == USA; then popsicle; else beer;)
forget about pd extended 0.43, I never recommend it !!!
2016-02-22 22:20 GMT-03:00 Morten Minothi Kristiansen minothi@gmail.com:
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <minothi@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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
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
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 porres@gmail.com:
forget about pd extended 0.43, I never recommend it !!!
2016-02-22 22:20 GMT-03:00 Morten Minothi Kristiansen minothi@gmail.com:
Not tried different builds, please giide me. 23. feb. 2016 02.20 skrev "Morten Minothi Kristiansen" <minothi@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" apvague@gmail.com:
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 < minothi@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. Aaaarrrgggghhh!!!
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" mviljamaa@kapsi.fi:
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
On 2016-02-23 02:20, Morten Minothi Kristiansen wrote:
Pd extended 0.43.
as you are undoubtedly aware (it has been stated so many times on ths list), Pd-extended is unmaintained for a couple of years and for all practical issues to be considered dead.
please use Pd-vanilla.
fgmasdr IOhannes
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 mviljamaa@kapsi.fi 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
If an oscillator's output is not connected to a DAC, does it still make a sound?
If you're standing atop the CPU, maybe. Even if the oscillator isn't hooked up to DAC its "perform" routine will run every block, causing the CPU to do work at regularly-recurring intervals. So the ground might get warm, maybe causing some wind around your ears... :)
On Tuesday, February 23, 2016 1:47 AM, William Huston <williamahuston@gmail.com> wrote:
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 mviljamaa@kapsi.fi 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
On 22/02/16 02:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1...
what i tried but couldn't (yet): build a decent piano-roll editor (vanilla).
and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores...
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem.
On 2/23/2016 12:25 PM, martin brinkmann wrote:
On 22/02/16 02:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1...
what i tried but couldn't (yet): build a decent piano-roll editor (vanilla).
and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear, though it's already relaxed a bit with netsend/receive. What are the main differences between running an instance of Pd as a [pd~] slave to another instance, and running two instances that communicate via netsend/receive and jack?
On Tue, Feb 23, 2016 at 5:45 PM, David Medine dmedine@ucsd.edu wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem.
On 2/23/2016 12:25 PM, martin brinkmann wrote:
On 22/02/16 02:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1...
what i tried but couldn't (yet): build a decent piano-roll editor (vanilla).
and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores...
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
Hello,
Le 24/02/2016 00:19, Matt Barber a écrit :
Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear, though it's already relaxed a bit with netsend/receive. What are the main differences between running an instance of Pd as a [pd~] slave to another instance, and running two instances that communicate via netsend/receive and jack?
I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous
So (if i am right), if something is heavy to compute (more than 100% of your CPU) in your subprocess with [pd~], your parent have to wait the end of this computation. This is not the case with [netsend]/[netreceive]. ++
Jack
On Tue, Feb 23, 2016 at 5:45 PM, David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu> wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem. On 2/23/2016 12:25 PM, martin brinkmann wrote: On 22/02/16 02:49, Matti Viljamaa wrote: How do you think Pure Data is limited? for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1... what i tried but couldn't (yet): build a decent piano-roll editor (vanilla). and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores... _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
Another possibility for at least some degree of parallel audio processing, I guess, is to use streaming objects + several instances of Pd. I tried out [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and they seem to work reliably. Of course there is some latency envolved and it's no practical solution for our future 100 core machines :-p.
What are in your experience the best methods for sharing audio via different Pd instances? And does anyone know the current status of "Audio over OSC"? I found this paper from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf
Christof
Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr Von: Jack jack@rybn.org An: pd-list@lists.iem.at Betreff: Re: [PD] How's Pd limited?
Hello,
Le 24/02/2016 00:19, Matt Barber a écrit :
Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear, though it's already relaxed a bit with netsend/receive. What are the main differences between running an instance of Pd as a [pd~] slave to another instance, and running two instances that communicate via netsend/receive and jack?
I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous
So (if i am right), if something is heavy to compute (more than 100% of your CPU) in your subprocess with [pd~], your parent have to wait the end of this computation. This is not the case with [netsend]/[netreceive]. ++
Jack
On Tue, Feb 23, 2016 at 5:45 PM, David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu> wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem. On 2/23/2016 12:25 PM, martin brinkmann wrote: On 22/02/16 02:49, Matti Viljamaa wrote: How do you think Pure Data is limited? for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1... what i tried but couldn't (yet): build a decent piano-roll editor (vanilla). and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores... _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
Reading a full inbox in a non-parallelized fashion leads to cross posting. Sorry for the repost, but this belongs on this thread.
Yeah, but the problem here (automatic compute resource distribution) isn't just with the actual distribution. Control timing is a huge issue too. If you have multiple voices of the same synth on different threads, good luck playing a chord. It will frequently be an arpeggio. If there are very strict, predictable rules about the order of when each voice computes and when it sleeps in order to wait for new samples and control signals, this problem vanishes, but then you are no longer computing in parallel, and you might as well have everything on one thread anyway.
This is a /really/ interesting problem. If someone can solve it, she deserves the nobel prize in computer music.
On 2/24/16 5:59 AM, Christof Ressi wrote:
Another possibility for at least some degree of parallel audio processing, I guess, is to use streaming objects + several instances of Pd. I tried out [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and they seem to work reliably. Of course there is some latency envolved and it's no practical solution for our future 100 core machines :-p.
What are in your experience the best methods for sharing audio via different Pd instances? And does anyone know the current status of "Audio over OSC"? I found this paper from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf
Christof
Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr Von: Jack jack@rybn.org An: pd-list@lists.iem.at Betreff: Re: [PD] How's Pd limited?
Hello,
Le 24/02/2016 00:19, Matt Barber a écrit :
Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear, though it's already relaxed a bit with netsend/receive. What are the main differences between running an instance of Pd as a [pd~] slave to another instance, and running two instances that communicate via netsend/receive and jack?
I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous
So (if i am right), if something is heavy to compute (more than 100% of your CPU) in your subprocess with [pd~], your parent have to wait the end of this computation. This is not the case with [netsend]/[netreceive]. ++
Jack
On Tue, Feb 23, 2016 at 5:45 PM, David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu> wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem. On 2/23/2016 12:25 PM, martin brinkmann wrote: On 22/02/16 02:49, Matti Viljamaa wrote: How do you think Pure Data is limited? for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1... what i tried but couldn't (yet): build a decent piano-roll editor (vanilla). and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores... _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
I'd say a solution would deserve the nobel prize in computers. :)
-Jonathan
On Wednesday, February 24, 2016 11:40 AM, david medine <dmedine@ucsd.edu> wrote:
Reading a full inbox in a non-parallelized fashion leads to cross posting. Sorry for the repost, but this belongs on this thread.
Yeah, but the problem here (automatic compute resource distribution) isn't just with the actual distribution. Control timing is a huge issue too. If you have multiple voices of the same synth on different threads, good luck playing a chord. It will frequently be an arpeggio. If there are very strict, predictable rules about the order of when each voice computes and when it sleeps in order to wait for new samples and control signals, this problem vanishes, but then you are no longer computing in parallel, and you might as well have everything on one thread anyway.
This is a really interesting problem. If someone can solve it, she deserves the nobel prize in computer music.
On 2/24/16 5:59 AM, Christof Ressi wrote:
Another possibility for at least some degree of parallel audio processing, I guess, is to use streaming objects + several instances of Pd. I tried out [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and they seem to work reliably. Of course there is some latency envolved and it's no practical solution for our future 100 core machines :-p.
What are in your experience the best methods for sharing audio via different Pd instances? And does anyone know the current status of "Audio over OSC"? I found this paper from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf
Christof
Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr Von: Jack jack@rybn.org An: pd-list@lists.iem.at Betreff: Re: [PD] How's Pd limited?
Hello,
Le 24/02/2016 00:19, Matt Barber a écrit :
Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear, though it's already relaxed a bit with netsend/receive. What are the main differences between running an instance of Pd as a [pd~] slave to another instance, and running two instances that communicate via netsend/receive and jack?
I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous
So (if i am right), if something is heavy to compute (more than 100% of your CPU) in your subprocess with [pd~], your parent have to wait the end of this computation. This is not the case with [netsend]/[netreceive]. ++
Jack
On Tue, Feb 23, 2016 at 5:45 PM, David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu> wrote:
I think we all need to learn more about multi-threading if we want
to run real-time, modular, digital signal processing algorithms on
multi-core machines. I, for one, can not think of any general,
robust way to do this. In that sense, Pd's adherence to single
threading is actually a very elegant solution to the problem.
On 2/23/2016 12:25 PM, martin brinkmann wrote:
On 22/02/16 02:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
for me the only real and important (i can think of at the
moment) limitation is the block-based audio processing.
to me this seems quite unnatural and inconvenient when dealing with
digital audio. it kept me for a couple of years from using pd,
though it
is only a 'showstopper' in rather few cases, i found out.
feedback in large/complex patches for example, since it
is not very practical (or possible at all) to re-block
everything to 1...
what i tried but couldn't (yet): build a decent piano-roll
editor (vanilla).
and i believe too, pd has to 'learn' better multithreading to run
adequately on our future machines with hundreds or even thousands of
arm-cores...
_______________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at <mailto: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
That is definitely true. Of course, we musicians need it more than most computer users out there...
On 2/24/2016 11:57 AM, Jonathan Wilkes wrote:
I'd say a solution would deserve the nobel prize in computers. :)
-Jonathan
On Wednesday, February 24, 2016 11:40 AM, david medine dmedine@ucsd.edu wrote:
Reading a full inbox in a non-parallelized fashion leads to cross posting. Sorry for the repost, but this belongs on this thread.
Yeah, but the problem here (automatic compute resource distribution) isn't just with the actual distribution. Control timing is a huge issue too. If you have multiple voices of the same synth on different threads, good luck playing a chord. It will frequently be an arpeggio. If there are very strict, predictable rules about the order of when each voice computes and when it sleeps in order to wait for new samples and control signals, this problem vanishes, but then you are no longer computing in parallel, and you might as well have everything on one thread anyway.
This is a /really/ interesting problem. If someone can solve it, she deserves the nobel prize in computer music.
On 2/24/16 5:59 AM, Christof Ressi wrote:
Another possibility for at least some degree of parallel audio processing, I guess, is to use streaming objects + several instances of Pd. I tried out [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and they seem to work reliably. Of course there is some latency envolved and it's no practical solution for our future 100 core machines :-p.
What are in your experience the best methods for sharing audio via different Pd instances? And does anyone know the current status of "Audio over OSC"? I found this paper from 2010http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf
Christof
Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr Von: Jackjack@rybn.org mailto:jack@rybn.org An:pd-list@lists.iem.at mailto:pd-list@lists.iem.at Betreff: Re: [PD] How's Pd limited?
Hello,
Le 24/02/2016 00:19, Matt Barber a écrit :
Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear, though it's already relaxed a bit with netsend/receive. What are the main differences between running an instance of Pd as a [pd~] slave to another instance, and running two instances that communicate via netsend/receive and jack?
I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous
So (if i am right), if something is heavy to compute (more than 100% of your CPU) in your subprocess with [pd~], your parent have to wait the end of this computation. This is not the case with [netsend]/[netreceive]. ++
Jack
On Tue, Feb 23, 2016 at 5:45 PM, David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu mailto:dmedine@ucsd.edu mailto:dmedine@ucsd.edu> wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem. On 2/23/2016 12:25 PM, martin brinkmann wrote: On 22/02/16 02:49, Matti Viljamaa wrote: How do you think Pure Data is limited? for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1... what i tried but couldn't (yet): build a decent piano-roll editor (vanilla). and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores... _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
a possible source of inspiration: "supernova a scalable parallel audio synthesis server for SuperCollider". It works great. http://tim.klingt.org/publications/icmc2011_supernova.pdf
On Wed, Feb 24, 2016 at 2:58 PM, David Medine dmedine@ucsd.edu wrote:
That is definitely true. Of course, we musicians need it more than most computer users out there...
On 2/24/2016 11:57 AM, Jonathan Wilkes wrote:
I'd say a solution would deserve the nobel prize in computers. :)
-Jonathan
On Wednesday, February 24, 2016 11:40 AM, david medine dmedine@ucsd.edu dmedine@ucsd.edu wrote:
Reading a full inbox in a non-parallelized fashion leads to cross posting. Sorry for the repost, but this belongs on this thread.
Yeah, but the problem here (automatic compute resource distribution) isn't just with the actual distribution. Control timing is a huge issue too. If you have multiple voices of the same synth on different threads, good luck playing a chord. It will frequently be an arpeggio. If there are very strict, predictable rules about the order of when each voice computes and when it sleeps in order to wait for new samples and control signals, this problem vanishes, but then you are no longer computing in parallel, and you might as well have everything on one thread anyway.
This is a *really* interesting problem. If someone can solve it, she deserves the nobel prize in computer music.
On 2/24/16 5:59 AM, Christof Ressi wrote:
Another possibility for at least some degree of parallel audio processing, I guess, is to use streaming objects + several instances of Pd. I tried out [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and they seem to work reliably. Of course there is some latency envolved and it's no practical solution for our future 100 core machines :-p.
What are in your experience the best methods for sharing audio via different Pd instances? And does anyone know the current status of "Audio over OSC"? I found this paper from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf
Christof
Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr Von: Jack jack@rybn.org jack@rybn.org An: pd-list@lists.iem.at Betreff: Re: [PD] How's Pd limited?
Hello,
Le 24/02/2016 00:19, Matt Barber a écrit :
Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear, though it's already relaxed a bit with netsend/receive. What are the main differences between running an instance of Pd as a [pd~] slave to another instance, and running two instances that communicate via netsend/receive and jack?
I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous
So (if i am right), if something is heavy to compute (more than 100% of your CPU) in your subprocess with [pd~], your parent have to wait the end of this computation. This is not the case with [netsend]/[netreceive]. ++
Jack
On Tue, Feb 23, 2016 at 5:45 PM, David Medine <dmedine@ucsd.edumailto:dmedine@ucsd.edu dmedine@ucsd.edu> wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem. On 2/23/2016 12:25 PM, martin brinkmann wrote: On 22/02/16 02:49, Matti Viljamaa wrote: How do you think Pure Data is limited? for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1... what i tried but couldn't (yet): build a decent piano-roll editor (vanilla). and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores... _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <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 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
a possible source of inspiration: "supernova a scalable parallel audio synthesis server for SuperCollider". It works great.
He actually started with a Pd-like system called "Nova", and commented on the bug tracker awhile back about making Pd thread-safe. He also worked on a development branch of Pd-extended, but I don't see much documentation about how that ended up.
-Jonathan
On Wednesday, February 24, 2016 3:06 PM, nicolas bouillot <nicolas.bouillot@gmail.com> wrote:
a possible source of inspiration: "supernova a scalable parallel audio synthesis server for SuperCollider". It works great. http://tim.klingt.org/publications/icmc2011_supernova.pdf On Wed, Feb 24, 2016 at 2:58 PM, David Medine dmedine@ucsd.edu wrote:
That is definitely true. Of course, we musicians need it more than most computer users out there...
On 2/24/2016 11:57 AM, Jonathan Wilkes wrote:
I'd say a solution would deserve the nobel prize in computers. :)
-Jonathan
On Wednesday, February 24, 2016 11:40 AM, david medine <dmedine@ucsd.edu> wrote:
Reading a full inbox in a non-parallelized fashion leads to cross posting. Sorry for the repost, but this belongs on this thread.
Yeah, but the problem here (automatic compute resource distribution) isn't just with the actual distribution. Control timing is a huge issue too. If you have multiple voices of the same synth on different threads, good luck playing a chord. It will frequently be an arpeggio. If there are very strict, predictable rules about the order of when each voice computes and when it sleeps in order to wait for new samples and control signals, this problem vanishes, but then you are no longer computing in parallel, and you might as well have everything on one thread anyway.
This is a really interesting problem. If someone can solve it, she deserves the nobel prize in computer music.
On 2/24/16 5:59 AM, Christof Ressi wrote:
Another possibility for at least some degree of parallel audio processing, I guess, is to use streaming objects + several instances of Pd. I tried out [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and they seem to work reliably. Of course there is some latency envolved and it's no practical solution for our future 100 core machines :-p.
What are in your experience the best methods for sharing audio via different Pd instances? And does anyone know the current status of "Audio over OSC"? I found this paper from 2010 http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf
Christof
Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr Von: Jack jack@rybn.org An: pd-list@lists.iem.at Betreff: Re: [PD] How's Pd limited?
Hello,
Le 24/02/2016 00:19, Matt Barber a écrit :
Can anyone explain more why [pd~] doesn't fulfill the desire for parallel processing, and maybe provide an example of something outside of Pd that does? I don't feel like I have a great handle on the design. As Jonathan said, it seems like Pd's determinism constraint is a big hurdle to clear, though it's already relaxed a bit with netsend/receive. What are the main differences between running an instance of Pd as a [pd~] slave to another instance, and running two instances that communicate via netsend/receive and jack?
I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous
So (if i am right), if something is heavy to compute (more than 100% of your CPU) in your subprocess with [pd~], your parent have to wait the end of this computation. This is not the case with [netsend]/[netreceive]. ++
Jack
On Tue, Feb 23, 2016 at 5:45 PM, David Medine <dmedine@ucsd.edu mailto:dmedine@ucsd.edu> wrote:
I think we all need to learn more about multi-threading if we want
to run real-time, modular, digital signal processing algorithms on
multi-core machines. I, for one, can not think of any general,
robust way to do this. In that sense, Pd's adherence to single
threading is actually a very elegant solution to the problem.
On 2/23/2016 12:25 PM, martin brinkmann wrote:
On 22/02/16 02:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
for me the only real and important (i can think of at the
moment) limitation is the block-based audio processing.
to me this seems quite unnatural and inconvenient when dealing with
digital audio. it kept me for a couple of years from using pd,
though it
is only a 'showstopper' in rather few cases, i found out.
feedback in large/complex patches for example, since it
is not very practical (or possible at all) to re-block
everything to 1...
what i tried but couldn't (yet): build a decent piano-roll
editor (vanilla).
and i believe too, pd has to 'learn' better multithreading to run
adequately on our future machines with hundreds or even thousands of
arm-cores...
_______________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at <mailto: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
maybe this is also a matter of convenience: i'd rather have the dsp-framework automagically divide and distribute my program to the available resources than to care for it myself. while it is for example ok to put each complex voice of a synth in an extra pd~ to make optimum use of the few cores, i'd rather not want to spend much time thinking about grouping functinality into (lots of) pd~ objects for a huge amount of cores.
one possibility would be to generally encapsulate any small part of a patch into its own pd~ object and let the os do the work. but i think this is not very convenient and would create a massive and unnecessary overhead.
i don't know of any (audio-)examples where this problem is handled in an elegant way though: afaik max has the same problem, reaktor is single-threaded too, and most daws do something like "use one thread per track"...
On 23/02/16 23:45, David Medine wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem.
On 2/23/2016 12:25 PM, martin brinkmann wrote:
On 22/02/16 02:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1...
what i tried but couldn't (yet): build a decent piano-roll editor (vanilla).
and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores...
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
Yeah, but the problem here (automatic compute resource distribution) isn't just with the actual distribution. Control timing is a huge issue too. If you have multiple voices of the same synth on different threads, good luck playing a chord. It will frequently be an arpeggio. If there are very strict, predictable rules about the order of when each voice computes and when it sleeps in order to wait for new samples and control signals, this problem vanishes, but then you are no longer computing in parallel, and you might as well have everything on one thread anyway.
This is a /really/ interesting problem. If someone can solve it, she deserves the nobel prize in computer music.
On 2/24/16 5:11 AM, martin brinkmann wrote:
maybe this is also a matter of convenience: i'd rather have the dsp-framework automagically divide and distribute my program to the available resources than to care for it myself. while it is for example ok to put each complex voice of a synth in an extra pd~ to make optimum use of the few cores, i'd rather not want to spend much time thinking about grouping functinality into (lots of) pd~ objects for a huge amount of cores.
one possibility would be to generally encapsulate any small part of a patch into its own pd~ object and let the os do the work. but i think this is not very convenient and would create a massive and unnecessary overhead.
i don't know of any (audio-)examples where this problem is handled in an elegant way though: afaik max has the same problem, reaktor is single-threaded too, and most daws do something like "use one thread per track"...
On 23/02/16 23:45, David Medine wrote:
I think we all need to learn more about multi-threading if we want to run real-time, modular, digital signal processing algorithms on multi-core machines. I, for one, can not think of any general, robust way to do this. In that sense, Pd's adherence to single threading is actually a very elegant solution to the problem.
On 2/23/2016 12:25 PM, martin brinkmann wrote:
On 22/02/16 02:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
for me the only real and important (i can think of at the moment) limitation is the block-based audio processing. to me this seems quite unnatural and inconvenient when dealing with digital audio. it kept me for a couple of years from using pd, though it is only a 'showstopper' in rather few cases, i found out. feedback in large/complex patches for example, since it is not very practical (or possible at all) to re-block everything to 1...
what i tried but couldn't (yet): build a decent piano-roll editor (vanilla).
and i believe too, pd has to 'learn' better multithreading to run adequately on our future machines with hundreds or even thousands of arm-cores...
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
On 22/02/16 09:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
expr~ tanh($v1)
I would apologise for being a smart-ass but I don't feel sorry.
Cheers,
Chris.
On Wed, Feb 24, 2016 at 3:48 AM, Chris McCormick chris@mccormick.cx wrote:
On 22/02/16 09:49, Matti Viljamaa wrote:
How do you think Pure Data is limited?
expr~ tanh($v1)
If you copy the [tanh] abstraction from purepd and make it a signal one, doesn't that work? Then it's vanilla.
Hello,
On 24/02/16 17:23, Alexandros Drymonitis wrote:
If you copy the [tanh] abstraction from purepd and make it a signal one, doesn't that work? Then it's vanilla.
expr~ is available in all versions of Pd and has the same license.
It is probably slower than making a table, so doing what you said is a good idea for optimisation. Here is an abstraction that does what you describe:
https://github.com/chr15m/blockhead/blob/master/e_tanh.pd
Cheers,
Chris.
Hey Chris,
Here's a vanilla tanh~ version that doesn't involve a table lookup
https://github.com/enzienaudio/heavylib/blob/master/hv_tanh.pd
Cheers, Joe
On 25 February 2016 at 04:03, Chris McCormick chris@mccormick.cx wrote:
Hello,
On 24/02/16 17:23, Alexandros Drymonitis wrote:
If you copy the [tanh] abstraction from purepd and make it a signal one, doesn't that work? Then it's vanilla.
expr~ is available in all versions of Pd and has the same license.
It is probably slower than making a table, so doing what you said is a good idea for optimisation. Here is an abstraction that does what you describe:
https://github.com/chr15m/blockhead/blob/master/e_tanh.pd
Cheers,
Chris.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Alexandros Drymonitis -
AP Vague -
Chris McCormick -
Christof Ressi -
David Medine -
david medine
-
Esteban Viveros -
IOhannes m zmoelnig -
Ivica Ico Bukvic -
Jack -
Joe White -
Johnny Mauser -
Jonathan Wilkes -
martin brinkmann -
Matt Barber -
Matti Viljamaa -
Morten Minothi Kristiansen -
nicolas bouillot -
Niklas Reppel -
William Huston