[PD] what's the flatspace deal?
howdy, some libraries have a flatspace designation for some objects, like zexy flatspace, cyclone flatspace, iemlib flatspace... I don't really get it. What's the deal with it? thanks ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches issue list)
Hello list, Here my two cents. From PD user POV, I can say that I LOVE pd-vanilla. Mainly beacuse I love almost every vanilla-thing. Just a matter of philosophy. You have the base system that you can extend following your needs. But, there are at least two things that makes pd-extended a desirable choice (at least for ME): 1. Intallation on a new machine is almost a matter of few clicks. Im my home PC, that's not a problem, but when you are in a tight scheduling, that can make the difference. 2. When I work on PD, after hours of patching, I find the pd-extended patch rendering UI less tiring than pd-vanilla's one. I'm not the eye-candy guy, but with the patch rendering of pd-vanilla, after a while, I've some difficulties in identify objects at first sight and stuff like that (I know, maybe it's just me :) ). Based on this two requisites and recalling other posts in this thread, _my_ ideal scenario is the following. 1. Pd-vanilla with the patch rendering of pd-extended (I have no idea of the amount of work needed to obtain this, maybe someone has the answer). 2. A BINARY repository, or whatever, that provides a simple way to select and install the externels that I need without go to each externals developer website, and download, compile, ... . The number (2) seems to be the most critical step. At this point, questions come: 1. Every external works as-is with pd-vanilla? 2. It's clear that the most efficient (?) externals repository must be platform-based. For example, the most intuitive way to install things for an Ubuntu user is to fire up apt/synaptic ad click on this and that and click install. But from a developer point of view that means you have to create a repository for Ubuntu users, a repo for Fedora, a repo for OSX, for WIN, and so on and so forth. I think this strategy can be very developer-hungry :) (i.e. one or more mainter for each repo?). Another ideal scenario is to have a pd internal packaging system (i.e. a pd menu item called extensions that pops up a window in which you can chose the extension to install for your PLATFORM). Hummm... it seems a LOT of work for this! :) A trade-off can be a web page, with binary download link. The page can be generated automatically, and the duty of the mainters is to compile the extensions for different platforms and put those on the website. I will be happy to work with anyone who wants to collaborate :) Ceers Alessio On 17/12/2014 17:08, Alexandre Torres Porres wrote: Hello, I'm opening a new thread about the new direction of discussion with a proper subject title. Perhaps this will call the attention of other readers. I particularly think this is of major interest to everyone. We're discussing new ways of using the libraries in Pd Extended into Pd Vanilla, and even a way to bring some of the Pd-extended UI changes into vanilla. Something Miller brought up in the thread was /Just FYI…. Joe Deken of newblankets.org http://newblankets.org/ is considering making a repository of external objects compatible with Pd vanilla. I think almost all the/ /objects in Pd extended will work with vanilla (and if I find out what specific changes vanilla would need to allow the others, I'd be happy to try to provide them). It seems like maintaining compiled versions of the //libs is an easier thing to do than maintaining all of Pd Extended/. So, anyone else care to share their two cents? cheers [CUT] -- a. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
Thank you Jonathan, this is very instructive ! 2014-12-17 22:53 GMT+01:00 Jonathan Wilkes jancs...@yahoo.com: Hi Raphaël, The problem is not very intuitive to solve. It's difficult enough to understand the flow in a patch that only uses signal objects. And it's more difficult to understand the flow in a patch that uses control objects. That's because you can no longer just assume that each object will compute its inputs before sending output-- you must instead read all the right-to-left triggering to know where the data will go. (Plus you must understanding what triggers the object chain traversal in the first place.) But it's even more difficult to understand a patch that mixes the two. And on top of _that_ you have a [delay] in the object chain, which has its own timing outside of the normal firing of control events. That normal firing of events in a chain of control objects happens in zero logical time. Oh, and the value you're providing for your delay time is zero. That isn't trivial to understand, much less come up with as a solution in the situation of [env~]. One way to approach this is to think what happens to the following patch if you turned on audio for a single block and then turn it off again: [env~] | [bang] | [delay 1000] | [print delayed] [env~] | [bang] | [print normal] The [print normal] object will obviously print before the delayed one, right? It does, but let's look at a part of how Pd schedules this stuff. It's something like this: * fire the messages from each [env~], based on the order in which were created. Let's assume the first one you created is the one connected to the [delay 1000]. Here's what happens: 1) message goes from [env~] to [bang] to [delay 1000]. The [delay 1000] schedules a bang to output 1000ms later. This next part is the key: Pd will _not_ check to see whether 1000ms has passed until it has processed step #2 below. Also important is that Pd will _immediately_ proceed to step #2 below-- it doesn't wait 1000ms before doing so. You probably already knew that part, but many programming languages do in fact have mechanisms which let you just sit there waiting before computing the next logical part of the program. 2) message goes from [env~] to [bang] to [print normal]. We get an immediate printout to the console. 3) 1000ms passes, and [delay 1000] finally sends to [print delay]. We get the second printout to the console. Now here's the (lack of) magic: if you edit your patch and replace [delay 1000] with [delay 0], the same exact process happens in the same exact order. The only difference is that Pd waits 0ms before doing step #3 instead of 1000ms. But you're still guaranteeing the same order, and the program is still following all the same steps. (In other words, [del 0] doesn't trigger any special code that I know of-- it really does schedule a delay, which just happens to be 0ms.) Finally, notice that the console printout stays the same even if you switch steps #1 and #2. In other words, the [delay] ensures that you get the printout order you want, _regardless_ of the order in which you created the [env~] objects. Also, notice that this trick doesn't scale very well. If you had a patch full of [del 0] to force ordering in the way you do above, you're almost guaranteeing that there will be bugs. Anyway, I hope everything I wrote above is correct! These things are definitely difficult to explain and understand. -Jonathan On Wednesday, December 17, 2014 2:10 PM, Raphaël Ilias phae.il...@gmail.com wrote: oh, but that is just trivial: messages and signals are always calculated one after each other (first all messages; once they are done, signals are processed). so an even easier way would be to use a latch ([f]) and [bang~]+[del 0] to do the calculation in msg-domain. [bang~] will output a bang before each signal block (or after; it really will trigger a bang before the *next* signal block). unfortunately, this bang can happen before or after the events sent out by [env~], so we need to make sure to get an event *after* all [env~]s have triggered. the simplest way to achieve this is by using an additional [delay 0], which will schedule an event at the same logical time NOW but after all events already scheduled for NOW (e.g. those from [env~]). see attached patch. (in the attached patch i wasn't able to trigger an undesired behaviour without the [delay 0]; however i haven't tried hard and i'm pretty sure that you *can*; thus you should use [del 0]) thanks ! yes, with [delay 0] it ensures to get the good result (same block)... (also tried to get an undesired behaviour without [del 0], but didn't succeed !) i already used [delay 0] sometimes, but i don't see where it's role is documented i already knew [bang~] but with this object my doubt was always : i know that it will happen *every* block during message-domain computation, but
[PD] [moonlib/mknob] cursor display reset
Hi list, I love [mknob] because it's a compact GUI... However when it has to be re-drawn the cursor resets to the vertical position (12 o'clock). This happen when minimizing the patch's window, or when [mknob] is put inside a graph-on-parent subpatch and you open or move this subpatch (or abstraction) : the knob cursor is reset to 12 o'clock. Is it just me ? I'm on Window$ Vista with pd-extended 0.43.4 Or, has this inconvenient always existed ? Thanks, Raphaël ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches issue list)
I'm with you, Alessio. As another user of Pd who has sometimes been paid in the past to make drop-and-go patches for others, if this community were to develop a repository-style way to load libraries into vanilla, I'd like to see it work like Java. 1. Opening a patch with [import cyclone] would automatically download the cyclone library from Pd vanilla's extended library database if it wasn't already installed. 2. Pd would first check inside the folder where the patch is saved before fetching cyclone from the repository. (This might help with legacy versions of libraries?) 3. There could be an option when saving a patch to save referenced libraries in the patch folder so novices don't have to go sorting through library files to find the cyclone file to copy to their folder. I know 1 is significantly different behavior than how [import] currently works. I just believe that Pd should be simple for a non-Pd programmer to download and run a patch. This would assist greatly with that. Sam ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches issue list)
On 12/18/2014 08:16 PM, Samuel Burt wrote: 1. Opening a patch with [import cyclone] would automatically download the i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data. mgfdsr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches issue list)
Well, for starters, there could just be a repository with externals and libraries :) I'm willing to help somehow. I'm not a programmer only, but I can help organising it and stuff. Testing libraries, listing it, etc. Cheers 2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig zmoel...@iem.at: On 12/18/2014 08:16 PM, Samuel Burt wrote: 1. Opening a patch with [import cyclone] would automatically download the i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data. mgfdsr IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches issue list)
On 2014-12-18 20:34, IOhannes m zmölnig wrote: On 12/18/2014 08:16 PM, Samuel Burt wrote: 1. Opening a patch with [import cyclone] would automatically download the i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data. And the Pd-community currently does not have the resources to build something that is similar or more advanced than the Debian distribution system and preferably be cross platform. mgfdsr IOhannes Greetings, Fred Jan ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches issue list)
I'll second that strong opposition. If someone wants to shoot themselves in the foot, here is a loader that automatically fetches binaries from the net and loads them:http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/loaders/urloader/ -Jonathan On Thursday, December 18, 2014 2:34 PM, IOhannes m zmölnig zmoel...@iem.at wrote: On 12/18/2014 08:16 PM, Samuel Burt wrote: 1. Opening a patch with [import cyclone] would automatically download the i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data. mgfdsr IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches issue list)
If there is a cross-platform repository system out there that is well-tested and built to be _more_ secure than apt (i.e., defense against replay attacks in the original design), perhaps it could be leveraged. Unfortunately I don't know anything about binary repo systems, other than Debian's. -Jonathan On Thursday, December 18, 2014 3:04 PM, Fred Jan Kraan fjkr...@xs4all.nl wrote: On 2014-12-18 20:34, IOhannes m zmölnig wrote: On 12/18/2014 08:16 PM, Samuel Burt wrote: 1. Opening a patch with [import cyclone] would automatically download the i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data. And the Pd-community currently does not have the resources to build something that is similar or more advanced than the Debian distribution system and preferably be cross platform. mgfdsr IOhannes Greetings, Fred Jan ___ 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] udpreceive from iemnet not receiving when -nogui?
Hi list, I have discovered a strange thing about udpreceive from iemnet. It seems to not work when Pd is started with -nogui. I have tested it on different computers and the behavior is coherent. Could this be a bug? best, Peter ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches issue list)
On 18/12/2014 20:34, IOhannes m zmölnig wrote: On 12/18/2014 08:16 PM, Samuel Burt wrote: 1. Opening a patch with [import cyclone] would automatically download the i *strongly* oppose to anything that automatically connects to the internet and fetches or submits data. I totally agree with you! But an auto-download can be achieved by different means. For example by calling your default package manager. Or maybe in a semi-automatic way like pointing to a web page reposotory and then the user can download the external and put it in to a default folder (as suggested by Dan). Just an idea... But I think that the main concern is about compiling/maintaining all the (cross platform) externals and organize them in a clean manner. After that, the installation task can be simplified in several ways... Cheers Alessio mgfdsr IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- a. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
you can never really get the real response of a room because the temperature an air currents are always changeing., you can however get a very close approximation maybe. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [env~] issues
I'm surprised about this double bang, but I suppose this means do compute one audio block and only one (here 1024 samples). actually, i have NO idea why i needed to do the double bang. For some weird reason, a single bang was triggering the [switch~], but then the next bang did nothing. Only every second bang was triggering. So, i used [t b b] just to send 2 bangs and trigger every time. if you remove one cable from one outlet of the [t b b], you will see what i mean. not sure if there's a bug in the implementation, or what, but yeah...seems weird. I wonder if switching the DSP off does mess up with overlapping (as i understand overlapping with previous audio block). sorry, i don't actually know how the overlap is implemented, but I did some trial and error tests, sending various signals through the switched off subpatch, and through a subpatch with no [switch~] object. The outputs of each [env~] in the different subpatches seems to be the same. On Fri, Dec 19, 2014 at 12:37 PM, Billy Stiltner billy.stilt...@gmail.com wrote: you can never really get the real response of a room because the temperature an air currents are always changeing., you can however get a very close approximation maybe. ___ 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
