Re: [PD] smooth random numbers
Hi, Pagano, Patrick wrote: i have asked this is a few different ways and experimented but i am wondering, how does one create smooth random numbers that flow between each number instead of hoping from number to number? Maybe you can also use Perlin noise to get deviation rather than pure random ? There's been a thread about that a few months ago on the list. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
On Sat, Feb 22, 2014 at 10:54 PM, Pagano, Patrick p...@digitalworlds.ufl.edu wrote: Hello i have asked this is a few different ways and experimented but i am wondering, how does one create smooth random numbers that flow between each number instead of hoping from number to number? When trying to translate the settings of a 10 band graphic equalizer to a smooth spectrum I had a similar issue for which I used cubic interpolation in three steps. The first two steps involves factor 2 'upsampling' each, which renders a 40 point (+interpolation points) curve smooth enough for interpolation to 1024 points in one last step. Attached patch cubic_upsampling.pd shows the interpolation steps done on a sequence of random numbers. Katja #N canvas 143 79 708 617 10; #N canvas 328 438 667 277 stretch 0; #X obj 17 178 tabread4 \$0-ampsettings; #X obj 17 205 tabwrite \$0-stretched-settings; #X obj 228 97 t f f; #X obj 228 125 / 2; #X obj 228 178 tabread4 \$0-stretched-settings; #X obj 228 205 tabwrite \$0-stretched-settings2; #X obj 433 100 t f f; #X obj 433 74 for++ 0 1024; #X obj 433 180 tabread4 \$0-stretched-settings2; #X obj 433 206 tabwrite \$0-stretched-settings3; #X obj 433 127 / 25.6; #X obj 433 153 + 2; #X obj 17 78 t f f; #X obj 17 138 / 2; #X obj 228 57 for++ 0 43; #X obj 17 14 inlet; #X text 305 11 Intermediate tables \$0-stretched-settings and \$0-stretched-settings2 each have 3 points extra for cubic interpolation.; #X obj 17 40 for++ 0 23; #X connect 0 0 1 0; #X connect 2 0 3 0; #X connect 2 1 5 1; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 6 0 10 0; #X connect 6 1 9 1; #X connect 7 0 6 0; #X connect 8 0 9 0; #X connect 10 0 11 0; #X connect 11 0 8 0; #X connect 12 0 13 0; #X connect 12 1 1 1; #X connect 13 0 0 0; #X connect 14 0 2 0; #X connect 14 1 7 0; #X connect 15 0 17 0; #X connect 17 0 12 0; #X connect 17 1 14 0; #X restore 60 338 pd stretch; #N canvas 485 132 310 415 write-settings 0; #X msg 165 345 arrayviewlistnew; #X obj 165 374 s \$0-ampsettings; #N canvas 1 79 450 300 (subpatch) 0; #X array \$0-ampsettings 13 float 2; #X coords 0 1 13 0 200 100 1 0 0; #X restore 69 225 graph; #X obj 56 23 inlet; #X obj 56 49 unpack; #X obj 70 178 tabwrite \$0-ampsettings; #X obj 70 148 max 0; #X obj 31 375 outlet; #X text 80 375 done; #X obj 89 95 + 1; #X obj 31 94 t b f f; #N canvas 358 356 357 340 copy 0; #X obj 35 13 inlet; #X obj 35 240 tabread \$0-ampsettings; #X obj 35 269 tabwrite \$0-ampsettings; #X obj 88 13 inlet; #X obj 35 62 f; #X obj 35 90 sel 1 10; #X obj 35 210 unpack; #X msg 35 184 1 0; #X obj 91 173 tabread \$0-ampsettings; #X obj 91 202 tabwrite \$0-ampsettings; #X obj 91 143 unpack; #X text 146 103 copy from index 10 to 11 and 12; #X text 182 238 copy from index 1 to 0; #X text 33 300 copy values so [tabread4] can interpolate later; #X msg 91 107 10 11 \, 10 12; #X obj 35 39 bang; #X connect 0 0 15 0; #X connect 1 0 2 0; #X connect 3 0 4 1; #X connect 4 0 5 0; #X connect 5 0 7 0; #X connect 5 1 14 0; #X connect 6 0 1 0; #X connect 6 1 2 1; #X connect 7 0 6 0; #X connect 8 0 9 0; #X connect 10 0 8 0; #X connect 10 1 9 1; #X connect 14 0 10 0; #X connect 15 0 4 0; #X restore 50 121 pd copy; #X text 101 120 copy if index 1 or 10; #X text 114 94 shift index number; #X text 97 23 list: RMS value + slider index; #X connect 0 0 1 0; #X connect 3 0 4 0; #X connect 4 0 10 0; #X connect 4 1 9 0; #X connect 6 0 5 0; #X connect 9 0 5 1; #X connect 9 0 11 1; #X connect 10 0 7 0; #X connect 10 1 11 0; #X connect 10 2 6 0; #X restore 60 313 pd write-settings; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-randomnumbers 10 float 2; #X coords 0 1 10 0 200 100 1 0 0; #X restore 457 24 graph; #X obj 26 182 random 100; #X obj 26 210 / 100; #X obj 26 94 until; #X obj 26 123 f; #X obj 26 40 t b b; #X obj 26 153 t b f; #X msg 26 66 10; #X msg 65 94 0; #X obj 26 15 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 26 240 tabwrite \$0-randomnumbers; #X obj 59 123 + 1; #X obj 60 289 pack; #N canvas 1 73 450 300 (subpatch) 0; #X array \$0-stretched-settings 23 float 2; #X coords 0 1 23 0 200 100 1 0 0; #X restore 457 160 graph; #N canvas 1 73 450 300 (subpatch) 0; #X array \$0-stretched-settings2 43 float 2; #X coords 0 1 43 0 200 100 1 0 0; #X restore 458 318 graph; #N canvas 1 79 450 300 (subpatch) 0; #X array \$0-stretched-settings3 1024 float 2; #X coords 0 1 1024 0 200 100 1 0 0; #X restore 459 474 graph; #X text 53 14 generate random numbers; #X text 465 261 upsampled 2 times; #X text 475 419 upsampled 4 times; #X text 472 574 upsampled 102.4 times; #X text 21 461 Katja Vetter Feb. 2014; #X text 20 384 Smooth 'upsampling' of a random number series by cubic interpolation. The first two stages must be factor 2 upsampling each. After that \, the curve is smooth enough for arbitrary upsampling factors. ; #X connect 1 0 0 0; #X connect 3 0 4 0; #X connect 4 0 12 0; #X connect 4 0 14 0; #X connect 5 0 6 0; #X connect 6 0 8 0; #X connect 6 0 13 0; #X connect 7 0 9 0; #X connect 7 1 10 0;
Re: [PD] libpd separating gui from core
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Also, to be honest, at this point if Cycling 74 came out with Max runtimes for iOS and Linux, I would probably switch. I don't say that because I don't like PD, but more from a pragmatic point of view where I consider which project is currently progressing in the long term. For instance, on PD-dev, we're talking about updating GEM so it will work with the new Apple APIS aka in 64bit on any Mac OSX 10.7+. The writing has been on the wall for that transition FOR YEARS but there has been no work on that front. I must admit that I'm volunteering to make this update not because I use GEM, but because I fear PD losing out to Max when GEM doesn't work in computer labs running new Macs. Again, this is from personal experience at a major teaching institution where I was trying to push teaching PD but, frankly, it just wouldn't cut it for course requirements and taste of the professors involved. And I take that as a personal failure. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com On Feb 23, 2014, at 7:37 AM, Dan Wilcox danomat...@gmail.com wrote: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] armonic properties of another sound
Hey Flad,another possible way is a vocoder of sorts. You extract the fundamental frequency f of the harmonic sound via sigmund~, and assign the series based on f as values to a set of filters (f, 2f, 3f nf) through which you play the non-harmonic signal. Good luck,Eran Date: Thu, 20 Feb 2014 09:36:58 -0800 From: flad.ches...@gmail.com To: pd-list@iem.at Subject: [PD] armonic properties of another sound Hi, how can i give the armonic properties from one sound to another sound? I need to apply the armonic properties from a sound to another percusive sound that doesnt has a defined frequency ( noise) . Which is the best way of achieving this in pd? cheers F. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ok, Dan, i can feel you there. but let's not mix up the GUI-core separation with the GEM on OS X question. As much as their consequences are similar, they are fundamentally different in their implementation, no? Questions that comes to my mind when I see the GUI-core separation discussion is this: Let's assume - totally hypothetically spoken - there is a company or individual who would sponsor this effort. 1. Is there someone capable of completing the task? 2. Would the result of this work be accepted by Miller and become vanilla? 3. How long would that take? m. Am 2014년 02월 23일 21:37, schrieb Dan Wilcox: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMKLGwACgkQ3EB7kzgMM6Ij6QCeLvTudFFoBWIAryx6DvaFTI6D KH4An0zgJwCtqm1a9evrikGWWX48xyZ4 =oJnl -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Game Audio abstractions- how to publish?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2014? 02? 20? 00:00, schrieb Filippo Beck Peccoz: I'll make help patches for all of the abstractions. As far as I know, it suffices to name the patch /name/-help.pd, and put it in the same folder, right? That's right! Also, where can I edit the metadata and what can you edit in there exactly? I don't think there is a web resource explaining the format, but there is this excellent patch you may look at: all_about_help_patches.pd which on my computer is to be found at /usr/lib/pd-extended/doc/5.reference/ there is the standard anatomy of a help patch demonstrated including the [pd META] subpatch containing the meta data. m. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMKNhwACgkQ3EB7kzgMM6INXQCdGpxkpuj4rRxG7xUX9yzRzWAY U2MAn19At9UB7NhUUh+0bA/o5UqDZIz+ =fk+d -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Feb 23, 2014, at 12:14 PM, Max abonneme...@revolwear.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ok, Dan, i can feel you there. but let's not mix up the GUI-core separation with the GEM on OS X question. As much as their consequences are similar, they are fundamentally different in their implementation, no? Max, Forgive me as I'm not going to answer specifically regarding GEM :D That was just a recently re-opened wound so it made a pointed example. I think what bothers me is that this comes up again and again and still the main response is: what we have now is fine. That, after plenty of effort and previous code implementations that died on the vine and it feels already like trying to push libpd in that direction will yield the same result. I'm not trying to single out specific people, but just my general feeling in the project. Maybe I'm off base, but I feel that pd needs real modernization or it will get less and less adoption. Sure it will be around, but you wont see as many beginners starting with it. At this point a continued debate over whether the gui should be multithreaded or not seems moot to me. That comes in contrast to my involvement with the OpenFrameworks community which is growing via leaps and bounds. Sure, it's a younger project, but we've already had a number of developer conferences, developed a concerted development roadmap, delegated community leaders, etc. We work together. There have been a number of residencies sponsoring further development. I would really like to see that with this community as I really love working with PD but, again, why bother trying to push forward such an agenda on my own? I could probably rebuild my entire setup using Super Collider but I simply like patching audio better. I'm not trying to weigh blame on anyone, just explain the situation as I see it. I suppose from a different perspective, I'm an outsider coming in and trying to needlessly shake up things that are already working, proposing premature optimizations, etc. Questions that comes to my mind when I see the GUI-core separation discussion is this: Let's assume - totally hypothetically spoken - there is a company or individual who would sponsor this effort. 1. Is there someone capable of completing the task? I can probably do it if I wrap my head around the pd core. Peter Brinkmann and Jonathan W are probably better suited with their core familiarity and, obviously, Miller knows it through and through. The problem, of course, is that I or whoever would do this would need to be able to sit down, focus, and crank it out. I can't answer who could help sponsor that. My initial idea would have been STEIM, but do to NL budget cuts, they now have to rent the studios so the previous no stings attached residencies I had before are sadly no longer available. Another answer would Universities, but so far, I haven't seen much movement on this from previous discussions. The last option would be how I've funded my most recent project: freelance work and dedicating time off to work on my own projects. I could probably manage that, if needed, but I would *really really really* hate to spend a month on something that may not be adopted o go anywhere. I'd like to have the decisions made before I go out on a limb on my own dime. Open source is all about sharing, but that doesn't mean we write code for everyone else for free. 2. Would the result of this work be accepted by Miller and become vanilla? As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion. 3. How long would that take? Dunno. A few full time weeks for one person, probably (at least from my estimate). I imagine that could be shorter if there is a core developer meeting and overall architectural decisions could be hashed out and a roadmap developed. Sadly, this would be perfect for Google Summer of Code. m. Am 2014년 02월 23일 21:37, schrieb Dan Wilcox: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc
Re: [PD] libpd separating gui from core
Hi all - just a short note since this discussion is much too wode-ranging to address in full... 2. Would the result of this work be accepted by Miller and become vanilla? As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion. I think the main stakeholders are Pd users :) Anyhow, there's a useful discussion thread about pdlib instancing here: http://lists.puredata.info/pipermail/pd-dev/2013-12/019693.html and there's a wonderful series of talks underway at IRCAM about the problems of real-time media computing in general: http://repmus.ircam.fr/mutant/rtmseminars cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Well, then I'm simply out of the loop and mostly-off base. Woops, sorry. I'll go there and see if we can keep it going. Looks like we're talking about both multi-threading and multi-instances which would be a big move towards solving some fundamental problems. Also, it's not really a discussion any more, I turned it into a rant. :P In any case, I'd rather let my frustration be known and apologize later than sit by and *hope* for updates. In any case, if I can be helpful I'm more than willing to pitch in and get things done. On Feb 23, 2014, at 2:33 PM, Miller Puckette m...@ucsd.edu wrote: Hi all - just a short note since this discussion is much too wode-ranging to address in full... 2. Would the result of this work be accepted by Miller and become vanilla? As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion. I think the main stakeholders are Pd users :) Anyhow, there's a useful discussion thread about pdlib instancing here: http://lists.puredata.info/pipermail/pd-dev/2013-12/019693.html and there's a wonderful series of talks underway at IRCAM about the problems of real-time media computing in general: http://repmus.ircam.fr/mutant/rtmseminars cheers Miller Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Game Audio abstractions- how to publish?
Hi Max, found the help patch with the meta information it and will be studying it tonight :) Thanks, Filippo On Feb 23, 2014, at 6:55 PM, Max abonneme...@revolwear.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2014? 02? 20? 00:00, schrieb Filippo Beck Peccoz: I'll make help patches for all of the abstractions. As far as I know, it suffices to name the patch /name/-help.pd, and put it in the same folder, right? That's right! Also, where can I edit the metadata and what can you edit in there exactly? I don't think there is a web resource explaining the format, but there is this excellent patch you may look at: all_about_help_patches.pd which on my computer is to be found at /usr/lib/pd-extended/doc/5.reference/ there is the standard anatomy of a help patch demonstrated including the [pd META] subpatch containing the meta data. m. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMKNhwACgkQ3EB7kzgMM6INXQCdGpxkpuj4rRxG7xUX9yzRzWAY U2MAn19At9UB7NhUUh+0bA/o5UqDZIz+ =fk+d -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On 02/23/2014 07:37 AM, Dan Wilcox wrote: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. This is probably naive, but wouldn't it suffice to have an object that does automatically what the user is forced to do manually atm? Manual -- user opens a Pd instance for GEM and a separate Pd instance for audio Auto -- user creates an object [foo-audio-magic somepatch.pd] which automatically fires up a separate instance-- _not_ a child of the first-- for the audio. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. How do you know that's due to Pd's single-threadedness, and not some CPU-hogging object, or a poorly optimized object chain, or Pd doing GUI calculations in the core thread as well as tk's thread? Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc That particular problem is due directly to *_getrect calls in a patch with lots of objects (and possibly a bunch of *_click calls if hovering over an object that does a lot of computation in such a function). It's not super easy to solve, but it's approachable because the Pd-GUI already exists. But that's a completely separate issue from getting something like GEM to run in its own thread. Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication. At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket. Anyway if you're interested in coding anything up related to this thread, I know Ivica is interested in solving the GEM issue you mentioned. -Jonathan Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI. enohp ym morf tnes -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On 23 Feb 2014, at 20:29, Jonathan Wilkes jancs...@yahoo.com wrote: Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication. Indeed. This reminds of discussions on the pd dev list, some 7 years ago (!), which ultimately resulted in the Vibrez project a closed fork of Pd-devel, which added (among other things) basic multi-threading and a revamped GUI. http://g.org/research/software/vibrez/ http://g.org/pub/grill-2007-pdcon-vibrez.pdf IMHO, the introduction to that paper makes for sobering reading for anyone considering spending any significant effort on core Pd development. Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 02/23/2014 07:37 AM, Dan Wilcox wrote: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. This is probably naive, but wouldn't it suffice to have an object that does automatically what the user is forced to do manually atm? I'm not saying there should be some mechanism to separate this object from that ... only that the gui should be on it's own thread, audio in the audio callback thread, and something like GEM running opengl in it's own thread. This is how modern applications work and also how using libpd inside OpenFrameworks works, same for iOS. Manual -- user opens a Pd instance for GEM and a separate Pd instance for audio Auto -- user creates an object [foo-audio-magic somepatch.pd] which automatically fires up a separate instance-- _not_ a child of the first-- for the audio. Or it *just works*, like Jitter in Max. Whether we split hairs about *how* it should work, the fact remains that to most people I introduce to Pd to, Max is more attractive as things like audio video *just work* together. If the stakeholders of Pd are truly the users of Pd, then the complaints and requests for solving these kinds of issues should be obvious from the last 5-7 years ... Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. How do you know that's due to Pd's single-threadedness, and not some CPU-hogging object, or a poorly optimized object chain, or Pd doing GUI calculations in the core thread as well as tk's thread? It can happen when opening patches in libpd, including those without CPU-hogging objects. This is obviously *without* the gui. Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc That particular problem is due directly to *_getrect calls in a patch with lots of objects (and possibly a bunch of *_click calls if hovering over an object that does a lot of computation in such a function). It's not super easy to solve, but it's approachable because the Pd-GUI already exists. But that's a completely separate issue from getting something like GEM to run in its own thread. Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD. Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication. This is what I'm worried about and if that's truly the case, why bother really? At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket. True, but will that be integrated back into vanilla? It's the same problem again ... Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] suggestion for onset detector - timbreId?
Hi all, I wanted to ask if anyone has been working with onset detectors recently, and has any suggestions for patches. I already know T Vets' http://www.timvets.net/software/pd_autocutup.php?page=software, which goes through the file in realtime using bonk~. But is there anything more recent, e.g. using timbreId, that analyses an array in logical time? My goal was to generate a table with attack points and duration of events for a given sound, which I would then use on another patch. Thanks as usual, jmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Myo armband and Pd?
Ha! Excellent point, I guess it's the pirate me interested in their tech but refusing to accept their terms. The original Kinect was packaged similarly and cracked within what weeks if not days? Although granted that was I think unique technology at the time. On Sun, Feb 23, 2014 at 4:05 PM, Simon Wise simonzw...@gmail.com wrote: On 23/02/14 10:47, Richie Cyngler wrote: https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than a set of predetermined gestures. Anyone else curious or have more info about this device? if they are saying go away! that loudly why would you be interested? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- Richie www.glitchpop.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox danomat...@gmail.com wrote: On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com wrote: Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD. If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire. Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication. This is what I'm worried about and if that's truly the case, why bother really? Because you said it earlier--you feel like you failed convincing your colleagues pd is a viable option and that implies that you care and would like to move the project forward. I would say it is not your fault because you're not the only one who experienced that. The vanilla implementation has an incredible backwards compatibility that unfortunately hampers its progress. I truly admire Miller's pioneering work as well as his ongoing efforts on maintaining pd. But let us not also forget that he also has an incredible vision to allow forks like pd-extended, pd-l2ork, libpd, eapd, now defunct dd, and many other (yes, I call them forks even though some try to closely adhere to the core compatibility). I myself adhere to the idea that I promote backwards compatibility as long as it does not prevent progress. More so, I see backwards compatibility being way overstated, particularly when it comes to source code as each release includes version-specific compiled externals, making this a moot point. Sure, there are behavioral corrections one needs to make to their patch ecosystem but I guess that is the price of progress. Think about the leap Apple did with OS9-OSX transition, and then later with G5-Intel, etc. The downside is a lot of stuff broke. The upside? They are now one of the largest company in the world that emerged from the ashes of a bankruptcy bailout. I do understand I am here correlating pd to a corporation--arguably a dubious endeavor, but only so if one fails to realize the core question: What is more important to you: keeping backwards compatibility or moving the project forward? A question that applies to both regardless of their ostensibly orthogonal roots. Apparently, for Miller it is former (which is something I greatly respect him for), and for me it is latter. At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket. True, but will that be integrated back into vanilla? It's the same problem again ... Knowing the pd dev cycle, it is unlikely. In my last conversation with Miller, he did mention interest in porting my infinite undo and preserving stacking order (undo depends on it), so that may happen at some point. As for the rest--unlikely. And I am perfectly fine with that. Because, ultimately it is all about the productivity--if infinite undo truly makes that much of a difference, installing pd-l2ork is as easy as it gets, and the price you pay to stay within that ecosystem is potentially losing some of the backwards compatibility. Ask yourself if the shortcomings outweigh benefits and you'll have your answer. Then again, you can always use pd-vanilla/extended for your older projects as the source
Re: [PD] libpd separating gui from core
Hey lets keep on topic here. :) I'd say separating the gui and core is much less work than trying to revamp pd's threading model. Just *enabling* thirdparty GUI's that can talk to pd core as an audio and computation engine, should be possible without breaking backwards compatibility. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Fwd: libpd separating gui from core
Not likely. For example, look at the coordinate system for iemgui objects and you will find out that they are offset arbitrarily by a few pixels (in other words, their xy coordinates do not reflect their top left corner but some other arbitrary location). This is particularly apparent when trying to autopatch things. In pd-l2ork I first started working with ugly workarounds and soon found that I had to keep adding exceptions (e.g. in undo/redo actions that pertained to autopatching and similar situations) all over the place until I decided the best thing is to simply redo the iemgui implementation the right way by positioning them accurately according to their xy position. Now, fast-forward x years where we have a shiny new gui and are facing the question that pd-l2ork is already trying to address, which is do we keep backwards compatible yet dubious behavior of the original gui or do we correct this and then expect everyone to correct their endless library of GOP abstractions that put iemgui objects on the edge of the gop rectangle and as a result many of which become invisible because now they technically do not fit the GOP rectangle any more? On Sun, Feb 23, 2014 at 8:26 PM, Rich E reakina...@gmail.com wrote: Hey lets keep on topic here. :) I'd say separating the gui and core is much less work than trying to revamp pd's threading model. Just *enabling* thirdparty GUI's that can talk to pd core as an audio and computation engine, should be possible without breaking backwards compatibility. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On 02/23/2014 08:15 PM, Ivica Bukvic wrote: On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com wrote: On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD. If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire. Additionally, DesireData never had any stable releases as far as I remember. matju may have used it for some of his projects, but when I played around with it there were major chunks of functionality missing, and easy crashes. If someone wanted to port over DD's keyboard-only patching feature to Pd-l2ork, for example, you'd very quickly see the difference between the two. Because once it makes it into a release you'd be using the feature in a piece of stable software. That's an enormous difference. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Coming back on topic: On Feb 23, 2014, at 8:15 PM, Ivica Bukvic i...@vt.edu wrote: If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire. Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI. My take on the future (and I believe Hans has brought this up as well): If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core. We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible. My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from the prime mover you (and we all) are so indebted too. I guess what I'm saying in a nutshell is: I see libpd as the middle ground so Miller can focus on the pd core without the community and its forks having to muck up Pd-vanilla. It should be possible, I think we really just need to get all of the Pd devs in one room and hash out what that middle ground could be. Then we have a combined roadmap instead of hacking away in isolation. Does that make sense at all? It seems so obvious to me and is one of the reasons why I'm working on libpd. For me, it's a sustainable future. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
libpd requires a lot of what pd-l2ork offers in order to be able to move forward (obeying stacking order for instance, that are a prerequisite for global system-wide presets as well as editing tools like undo/redo and tofront/back). pd-l2ork also improves on pack, route, select, and trigger to make things easier for newcomers to understand and for professionals to get to their results faster. None of these are a part of the core and yet they very much belong to libpd... I simply don't see fragmentation as a bad thing. Look at Linux--fragmentation galore. And yet we all get along just fine (well for the most part ;-) If it will make it any easier for you, refer to pd-l2ork as anchovies and forget for a moment that it has any compatibility with pd whatsoever. This could ostensibly become a reality in not so distant future from now (well the compatibility part, not so sure about the name). That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. On Sun, Feb 23, 2014 at 9:40 PM, Dan Wilcox danomat...@gmail.com wrote: Coming back on topic: On Feb 23, 2014, at 8:15 PM, Ivica Bukvic i...@vt.edu wrote: If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire. Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI. My take on the future (and I believe Hans has brought this up as well): If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core. We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible. My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from the prime mover you (and we all) are so indebted too. I guess what I'm saying in a nutshell is: I see libpd as the middle ground so Miller can focus on the pd core without the community and its forks having to muck up Pd-vanilla. It should be possible, I think we really just need to get all of the Pd devs in one room and hash out what that middle ground could be. Then we have a combined roadmap instead of hacking away in isolation. Does that make sense at all? It seems so obvious to me and is one of the reasons why I'm working on libpd. For me, it's a sustainable future. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Feb 23, 2014, at 10:46 PM, Ivica Bukvic i...@vt.edu wrote: libpd requires a lot of what pd-l2ork offers in order to be able to move forward (obeying stacking order for instance, that are a prerequisite for global system-wide presets as well as editing tools like undo/redo and tofront/back). Those sound like things that should/could be in the core. pd-l2ork also improves on pack, route, select, and trigger to make things easier for newcomers to understand and for professionals to get to their results faster. None of these are a part of the core and yet they very much belong to libpd... Those are objects and they can simply alias the existing objects on load, that or add an option to the core to not load existing objects / allow conditional calls the the object setup functions. I simply don't see fragmentation as a bad thing. Look at Linux--fragmentation galore. And yet we all get along just fine (well for the most part ;-) The kernel is fragmented? Your talking distros and I see things going more Linux BSD. If it will make it any easier for you, refer to pd-l2ork as anchovies and forget for a moment that it has any compatibility with pd whatsoever. This could ostensibly become a reality in not so distant future from now (well the compatibility part, not so sure about the name). I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... If the reality is as you say, then I'm not really interested in spending my time hacking on our little island. On Sun, Feb 23, 2014 at 9:40 PM, Dan Wilcox danomat...@gmail.com wrote: Coming back on topic: On Feb 23, 2014, at 8:15 PM, Ivica Bukvic i...@vt.edu wrote: If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire. Except I see there being a third middle, ground via libpd. IMO Miller is best at the core and the community is the best at adding functionality around it and creating a modern GUI. My take on the future (and I believe Hans has brought this up as well): If we could find a way to abstract the gui interface as libpd already does for midi and messaging, I see Pd-vanilla keeping the existing gui and using a single threaded libpd as the core. Then the forks utilize libpd for the core and wrap it with their newer, updated whizz-bang accelerated guis using perhaps a multithreaded libpd as their core. We know the issues, if we can work out a way to solve what's needed for the gui abstraction and hopefully multi-threaded/multi-instance support added to the core then there's a way to have the best of both worlds. For instance, multi-threading support can and should be a compile time flag and it can simply be turned off in Pd-vanilla. It may involve some work and some pain, but I really think it must be possible. My fear is that, in the long run, the forks may diverge too much from the more slowly evolving vanilla and eventually lose integration with it completely. That splits the community for real, one that is perhaps already too splintered. Pd-L20rk is really exciting, but it would be sad if it eventually might split off from the
Re: [PD] libpd separating gui from core
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. If the reality is as you say, then I'm not really interested in spending my time hacking on our little island. And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
