Pd-list December 2014

pd-list@lists.iem.at

66 participants
85 discussions

Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
by Dan Wilcox 23 Dec '14

23 Dec '14

Oi, no. That’s putting the cart before the horse. IMO It makes more sense to break up the externals in the svn to separate repos with working Makefiles. Once we know they’re all working and have an easy way to install binaries like Max, then we could go to the next level. Baby steps. If I wasn’t in the middle of my thesis writing right now, I would have done it as a test to Github already. Besides, requiring beginners to install Fink (Homebrew is much nicer than Fink or MacPorts anyway) is going in the opposite direction. If we really wanted to make that work, it would require distributing apt and it’s required libraries in binary from with Pd on OSX and Windows. Yeah, I don’t see that happening :P -------- Dan Wilcox @danomatika danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Dec 20, 2014, at 2:39 PM, pd-list-request(a)lists.iem.at wrote: > > From: Fred Jan Kraan <fjkraan(a)xs4all.nl <mailto:fjkraan@xs4all.nl>> > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Date: December 20, 2014 at 2:29:30 PM EST > Subject: Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list) > > > On 2014-12-20 19:09, IOhannes m zmölnig wrote: >> On 12/18/2014 10:13 PM, Jonathan Wilkes via Pd-list wrote: >>> 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 <fjkraan(a)xs4all.nl <mailto:fjkraan@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. >> >> >> so why not use apt? >> >> i mean, we could build on top of apt to do something "more" cross platform. >> Debian (and thus apt) already handles multiple architectures and >> "operating systems" (well: kernels), so we just need a few others archs: >> - w32-i386 >> - w32-amd64 >> - osx-i386 >> - osx-amd64 >> >> this would of course mean porting (parts of) apt to w32/osx (and i have >> no clue how much work *that* means) > > Porting apt would indeed solve the Pd-distribution problem, and maybe > for more cross-platform packages. > > For MacOSX, the Fink package is based on Debian tools > (http://www.finkproject.org/ <http://www.finkproject.org/>). So that leaves Windows. > >> From the distant past I remember Inno Setup is free and usable > (http://www.jrsoftware.org/isinfo.php <http://www.jrsoftware.org/isinfo.php>). As long as there is no native > apt for Windows that could do... > > Somehow, it looks a bit less abstract now :-). >> >> fgmrds >> IOhannes >> > Greetings, > > Fred Jan

6 12

udpreceive from iemnet not receiving when -nogui?
by Peter P. 22 Dec '14

22 Dec '14

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

1 1

xensynth 10.12 available
by Billy Stiltner 22 Dec '14

22 Dec '14

instructions at https://m.facebook.com/story.php?story_fbid=1603435663209583&id=15023864099…

1 0

Fwd: Mac Retina display - graphics glitching?
by Philip Stone 22 Dec '14

22 Dec '14

forgot to include the Pd-list on my reply: I’ve only seen it on my (very complex) performance setup, which I can’t very well use as a test case. I will try to find a simpler example, though it’s possible that my complex performance patches are stressing the graphics somehow. If I can do that with a (vanilla, I assume) simple patch, I’ll try your demo build. Thanks, Dan. Phil On Dec 17, 2014, at 6:34 AM, Dan Wilcox <danomatika(a)gmail.com<mailto:danomatika@gmail.com>> wrote: I haven’t seen this. Do you have an example that does it? Can you compare the same patch with my demo build of Pd 0.46 with retina screen support: Pd-0.46-0-64bit-retina.app.zip<http://docs.danomatika.com/Pd-0.46-0-64bit-retina.app.zip> -------- Dan Wilcox @danomatika danomatika.com<http://danomatika.com/> robotcowboy.com<http://robotcowboy.com/> On Dec 17, 2014, at 4:12 AM, pd-list-request(a)lists.iem.at<mailto:pd-list-request@lists.iem.at> wrote: From: Philip Stone <pkstone(a)ucdavis.edu<mailto:pkstone@ucdavis.edu>> To: PD list <pd-list(a)iem.at<mailto:pd-list@iem.at>> Date: December 16, 2014 at 6:20:19 PM EST Subject: [PD] Mac Retina display - graphics glitching? Upon getting a new 13” Retina Macbook, I have started to notice glitching in the PD UI. I thought this might signal a need to upgrade to Pd-extended 0.43.4, so I did, but this did not fix the glitching. Usually, the glitching manifests as a flickering GUI slider, but sometimes, a whole squarish section of the screen flickers briefly. It’s not disabling, but it’s very distracting to see the screen flashing out of the corner of my eye. Configuration: MacBook Pro (Retina, 13-inch, Mid 2014) Pd Version: 0.43.4-extended Tcl Version: 8.5.11 I haven’t searched the bugs list yet; I’m just wondering if anybody else has noticed this? Phil Stone UC Davis

1 0

Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
by Samuel Burt 21 Dec '14

21 Dec '14

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

8 18

Re: [PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
by Dan Wilcox 20 Dec '14

20 Dec '14

If we separate the externals into repos with a standardized Makefile, I imagine they should build fine for both vanilla and l2ork. I see overlap here that’s more advantageous then having all the former Pd-extended externals being maintained on Sourceforge and updated on Github for l2ork. Again, hate to sound like a broken record, but I’d spearhead this effort as soon as I get time again in a few weeks. -------- Dan Wilcox @danomatika danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Dec 20, 2014, at 5:17 PM, pd-list-request(a)lists.iem.at wrote: > > >> FWIW, a good chunk of this cleanup is currently taking place in pd-l2ork. Namely, we are looking for redundant objects which are then disabled and replaced by legacy abstractions where possible or linked to other objects with identical or near identical functionality (again, where possible); we are disabling problematic objects that have design issues (e.g. foxy and flatspace IIRC), as well as looking to replace those with new objects that provide said functionality the right way. Finally, we are looking to standardize documentation (e.g. pd-l2ork has documentation for the entire cyclone adapted to the pddp format). If anyone desires git access to assist with this, please let us know.

1 0

[env~] issues
by Raphaël Ilias 19 Dec '14

19 Dec '14

Hi dear pd freaks, I'm currently using [env~] for measurement purpose (room's sound monitoring and soundfiles analysis) and I have a few questions/remarks ...that unfortunately may have already been discussed here (I have been unsubscribed from the list since a couple of years). However : 1) Just noticed : the [env~] help patch (from PDDP) states that default analysis window is 1024 samples, while it links to Miller's example C07.envelope.follower.pd where you can read that the default window is 256 samples. 2) AFAIK there is no way to dynamically (message) change the analysis window's size, at least without dynamic patching.. what I "painfully" managed to do (see attached patch "ph_env~.pd"). Ah, I can see on sourceforge that it is a request open since 2012... http://sourceforge.net/p/pure-data/feature-requests/109/ 3) Last but not least, the question I can't answer myself ! When using multiple [env~] it isn't very clear for me which one will output first. So it confuses me when I try to do very simple things like comparing (difference) two signals' amplitude : doing a substraction requires to input the [- ] object in correct order (right inlet before left's). While doing it the wrong order may seem to work, I realized that in fact I was comparing two different windows. The actual order of output between different [env~] seems to be related to the objects' order of creation. I think that order of creation is a trouble since you cannot "read" it in the patch, so it isn't "the diagram is the program" anymore. Moreover, as far as i can deduce from what i experimented empirically (means : i'm not sure at all) the first to output is the last that was created. My experiments with order can be found in "order_env~.pd" attached file. Finally, maybe all this mess is just me not being very clear with how message/DSP are scheluded/interfaced... but I feel that [snapshot~] is way more easy to understand and control, since it outputs value "on demand" (bang) and order can be easily stated with [trigger]. I think i'd feel much more comfortable with a kind of [env~] object that computes the enveloppe of the last N audio blocks or last N samples, "on demand", when triggered by a bang. Maybe someone will answer me that I'm really confused and that my problems are false problems... In case, I'd be glad to be taught the right way ! Cheers, Raphaël

7 18

env~ with heisenberg principal builtin
by Billy Stiltner 19 Dec '14

19 Dec '14

who in their right mind creates such an object? haha, just kidding. just finished watching Miller's pd lectures 19 and 20, the online videos. they are amazing. the filter section of 19 blew my mind.

1 0

Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
by Dan Wilcox 18 Dec '14

18 Dec '14

I also agree. Security issues aside, An (auto) downloader would be a *nice to have* and not a *requirement*. I see an option like that *only* after the requisite base of external builds, repositories, external listing info/site are in place. After that we could maybe think about a package management deal, but that’s *non trivial* to say the least. Sure it works in large projects like Debian but only after years of work an maintenance by a large number of people. People have managed to download and install Max externals for years now. The best/easiest solution is a default folder search path like Pd-extended’s "pd-externals” folder in the user home directory. Then you just tell people to drop the externals in there and have an optional setting to automatically add all subfolders to the search path. This is what I do in PdParty so it’s pretty easy to add stuff. It could work imilar to how libdir does in extended. Power users could turn off the auto search path adding and stick with loading by name, etc. -------- Dan Wilcox @danomatika danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Dec 18, 2014, at 3:37 PM, pd-list-request(a)lists.iem.at wrote: > > From: Fred Jan Kraan <fjkraan(a)xs4all.nl <mailto:fjkraan@xs4all.nl>> > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Date: December 18, 2014 at 3:02:36 PM EST > Subject: 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

1 0

Extending Vanilla (was Cyclone help patches & issue list)
by Alexandre Torres Porres 18 Dec '14

18 Dec '14

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 2014-12-17 1:05 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list(a)lists.iem.at> : > > Well, you can peruse the tracker's open patches to get a sense of whether > you can (or if it's worth your time to try). Keep in mind the Pd-l2ork gui > prefs code started out as a patch specifically written as a clean, small > patch to get into Vanilla/Extended. > > -Jonathan > > > On Tuesday, December 16, 2014 6:04 PM, Dan Wilcox <danomatika(a)gmail.com> > wrote: > > > Sorry, I didn;t mean to sound like I'm griping. The nature of the question > was more "if we apply clean, small patches to vanilla, could we get some of > Han's updates in so they aren't lost to non Pd-l2ork users". I'm in the > middle of writing my thesis right now, but getting into real Pd development > again is on my list when I'm finally done with it. > > On Tue, Dec 16, 2014 at 5:59 PM, Jonathan Wilkes <jancsika(a)yahoo.com> > wrote: > > On 12/16/2014 03:12 PM, Dan Wilcox wrote: > > I like how I explicitly asked to not hear that "Pd-l2ork has that" and > yet that's the response I got. I already knew this anyway from the sample > screenshots you were posting when you were implementing it. (Looks great > BTW) > > > Yeah, I know, it was 100% willful snark on my part. It's kind of like you > were asking, "Is there a way to do X, while satisfying my irrational desire > to ignore a working solution by someone who likely already did X?" > > Anyway, did you look at the code? It's done in tcl/tk, and it does not > depend on tkpath. So if you don't want to duplicate all the work I already > did, you can fairly easily port that back to Pd Vanilla. There might be a > few API differences in accessing the audio backend, but there are small and > I don't mind helping make those changes. > > Also, I specifically did everything in tcl/tk so that the patch would be > as simple as possible. It shouldn't even require a recompile. Now, I > haven't looked at Ivica's changes that added persistence. But all versions > of Pd have the same prefs-saving code so that shouldn't be difficult, > either. > > > Also, if you didn't know, why respond? :P > > > Because the answer to your question ultimately depends on whether what you > come up with fits the unspoken yet stringent HIG standards imposed by > Miller's Pd. > > But that doesn't mean that code which does _exactly_ what you're asking > about isn't relevant to your question. > > -Jonathan > > > On 12/15/2014 06:21 PM, Dan Wilcox wrote: > > If that does become a real scenario, I hope we can find a way to bring > some of the Pd-extended UI changes into vanilla, such as the pixel perfect > sizing across platforms, an option for the extended coloring (graytones) > etc. Before anyone says “Pd-Lork has that”, I’m just wondering if it’s > feasible to bring in some of the work Hans did after the gui cleanup which > is already in vanilla. > > > In answer to your question: I don't know. > > Having answered that... > > Pd-l2ork has gui theme presets for Vanilla, Inverted Vanilla, Pd-extended, > Commodore 64, Strongbad's Compy, and a few others. There's also an > interface to make a custom theme-- I didn't make it persistent but I think > Ivica added that ability. > > -Jonathan > > > -- > Dan Wilcox > danomatika.com > robotcowboy.com > > > > > -- > Dan Wilcox > danomatika.com > robotcowboy.com > > > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >

5 10

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list December 2014