Pd-list February 2016

pd-list@lists.iem.at

91 participants
131 discussions

Re: [PD] How's Pd limited?
by jamal crawford 23 Feb '16

23 Feb '16

hi list >Max have features like auto-align horizontally/vertically and align and >route patch cords which is very useful to >organize patch cords and >make the thinks more readable. I like them a lot. this is so old. this comparing .... so old. if you like your fancy gui's, use them! have you heard of OSC? just dump whatever you want thru it and run a headless instance of pd, where you recieve it. nobody will even notice. are you a nerd or just pretending :P sorry no offence .) peace ~/.jc

5 5

did cyclone had any new object?
by Alexandre Torres Porres 23 Feb '16

23 Feb '16

1 1

Re: [PD] How's Pd limited?
by Peter Nyboer 23 Feb '16

23 Feb '16

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

2 1

Re: [PD] How's Pd limited?
by Dan Wilcox 23 Feb '16

23 Feb '16

> 2016-02-22 17:25 GMT-03:00 Matt Barber <brbrofsvl(a)gmail.com <mailto:brbrofsvl@gmail.com>>: > I've said this before, but I think there are very good reasons not to ever include segmented patch cords (although hideable patch cords would be even worse). These two features are responsible for some of the very worst patching habits in Max/MSP. Have you ever been called on to run someone's patch, and you need to tweak something for your specific audio setup or fix a bug or whatever, and when you open it you get something that looks like this (one of the first "max patch" results on google image search): > > http://www.letatoubleu.com/OLcomposer_files/image001.jpg <http://www.letatoubleu.com/OLcomposer_files/image001.jpg> > > > I agree, and I laugh when people say, this is hard to understand in Max, because of all the cords, I can't imagine how ugly it'd be in Pd. The solution is the same in both environments: good use of encapsulation via subpatches & judicious use of send/recvs when necessary. Example from robotcowboy: * one of my first performance patches: https://www.flickr.com/photos/danomatika/25082084442/in/datetaken-public/ <https://www.flickr.com/photos/danomatika/25082084442/in/datetaken-public/> * and the second version using subpatches & send/recvs: https://www.flickr.com/photos/danomatika/24573539133/in/datetaken-public/ <https://www.flickr.com/photos/danomatika/24573539133/in/datetaken-public/> This approach led to using GOP and modularizing things between separate patches & a main control patch: https://www.flickr.com/photos/danomatika/25107115651/in/datetaken-public/ <https://www.flickr.com/photos/danomatika/25107115651/in/datetaken-public/> To segment or not to segment is moot, you can create both well designed as well as spaghetti patches in either environment just as you can create well-written or spaghetti code in any textual language. I agree that the environments are not at fault here. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

6 6

Re: [PD] How's Pd limited?
by Dan Wilcox 23 Feb '16

23 Feb '16

> On Feb 22, 2016, at 8:54 PM, pd-list-request(a)lists.iem.at wrote: > > From: Esteban Viveros <emviveros(a)gmail.com <mailto:emviveros@gmail.com>> > Subject: Re: [PD] How's Pd limited? > Date: February 22, 2016 at 8:48:16 PM MST > To: Johnny Mauser <joson.android(a)googlemail.com <mailto:joson.android@googlemail.com>>, Morten Minothi Kristiansen <minothi(a)gmail.com <mailto:minothi@gmail.com>> > Cc: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > > > A feature I miss in vanilla and extended (pdl2ork solve that) is resize objects via one point click and drag. If it is hard to implement, a "apply" button on properties can help to design UI's in Vanilla. I have updates in the works for the vanilla dialog boxes. > Max have features like auto-align horizontally/vertically and align and route patch cords which is very useful to organize patch cords and make the thinks more readable. I like them a lot. Object & canvas align could be made using a GUI plugin. Such a plugin might exist already, actually. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] How's Pd limited?
by Dan Wilcox 23 Feb '16

23 Feb '16

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

1 0

How does N-track manage to get past the "single instance" problem of Pure Data?
by Matti Viljamaa 23 Feb '16

23 Feb '16

So I found out today that N-track has a working PdVST implementation that handles multiple instances as well as generates very nice GUIs. How do they manage the multiple instance, if it’s a limitation in Pure Data? Any ideas?

1 1

Re: [PD] How's Pd limited?
by Dan Wilcox 22 Feb '16

22 Feb '16

> On Feb 22, 2016, at 2:09 PM, pd-list-request(a)lists.iem.at wrote: > > From: Eugene Lazarchik <evgenius.lazarchik(a)gmail.com <mailto:evgenius.lazarchik@gmail.com>> > > I consider sends and receives evil. They're similar to global variables or goto statements in general purpose programming languages. However they are extremely useful when used well, especially in conjunction with $0. I don’t quite get the goto comparison here. Goto is a low level execution construct while send/receives is a higher level abstraction. I tech them as “named, invisible patch cords”. > When you see a receive object, it's not obvious where all corresponding sends may be. As opposed to simply following where the cords go. The find menu is your friend here but of course one shouldn’t use send/receives for *everything*. I prefer to use patch chords as much as possible but their are times, especially when using GOP where send/receives make things not only more readable but *easier* to understand IMO. This, of course, is a style preference. Also, libpd and both PdParty & PdDroidParty *rely* on send/receives for both inter app communication as well as their UI implementations. > Also, consider a subpatch (or abstraction), with certain cords connected to it. In a way the inlets and outlets describe how this object can be used: it can receive certain messages through inlets and then send output to the outlets. But if there's sends and receives inside, it becomes much harder to track what the object may do. That’s a patching design issue and not a problem in the language/environment. If sends & receives are not used willy nilly, including ridiculous fanouts, there’s generally not too much of a problem, especially if a patch is documented. > In regards to the screenshot: it could be simplified by putting stuff into subpatches. However, even when there's only a couple of objects on a subpatch, the cords can still cross the objects if there's no way to segment them. Typical reasons include long objects ([pd $0-descriptive-name-of-the-subpatch], or [t a a a a a a a a] or [route this and that], etc.). Also it's hard to avoid a mess without segmenting if there's a lot of feedback connections (when A's output is connected to B but also B's output is connected to A). This is usually fixed by arranging things in a good order underneath the [t a a a a a a a a] and subpatching and/or fanning things out. Not impossible to make things easy to understand without overlapping lines. I’ve picked up quite a few tricks by looking at patches made by a number of people on this list. Maybe what we need is a wiki pages with examples of good patching practice? Also, simple segmenting can be accomplished via using [t a] objects when desired. > Also, moving functionality in a subpatch usually should only be done when there's something common between the objects inside and they implement a relatively siloed functionality. Otherwise it may be hard to understand what the subpatch is doing and the reader will have to constantly switch between the parent and the subpatch to understand how they work together. Again, this is a patching design issue. I agree that subpatches should only encapsulate common actions but not implementing things this way is a fault of the person who made the patch. I have been using the method of adding descriptions to my subpatch as well as inlet/outlet objects as they aren’t used by help in documenting what’s going on: [pd bass synth] [inlet midi note vel pair] [outlet~ pitched down audio] etc -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] How's Pd (is not) limited?
by jamal crawford 22 Feb '16

22 Feb '16

hi list >* Support for lists is quite limited. Wanna create a multidimentional > array? Build your own. Want a hash map? Build your own. "its not a bug, its a feature" :P > * Standard GUI objects are ugly .... thats a matter of taste matey. i think osx and dem abbles are *really* ugly products >* PD community uses mailing lists for communications, haha. In order to > find useful information I have to view one message per page, with > tons of distracting quotes from previous messages. ... and thats the beauty of it, the more you dive, the more you learn... oi

1 0

Re: [PD] Cyclone future
by Dan Wilcox 22 Feb '16

22 Feb '16

> On 02/21/2016 08:35 PM, Fred Jan Kraan wrote: >> This mail is the last I will write about cyclone in the foreseeable >> future. > > this is about the worst possible outcome of the entire discussion. Exactly. Discussions are great and all but discussions also involve listening to both sides. At some point, things seemed to go one sided. Developer burnout is a *huge* problem in open source so Fred’s concern about maintainability vs. extensibility is valid. Maybe that concern wasn’t quite coming through over email. I can personally say, OS developers tend to start getting into a situation were they work on things not because they are interested anymore but because they feel like they *have* to support the needs of others … for free. That’s where things get toxic and it’s sometimes hard to find a balance between the two. I’m not trying to figure blame, etc, I’m trying to see what we can all learn from this unfortunate outcome. Instead of consistently asking for Fred to integrate and increase his workload, the better course of action might have been to make a companion library that utilizes cyclone and begins adding functionality. Maybe start with abstractions and go from there? Putting up code and workable ideas always influences things more than "here’s a huge bug/feature list for one person to implement.” Oftentimes, if the work is good and the developer can see things are coming together nicely, talk begins about a possible integration with the base code base and direct collaboration. This has been the case in the OpenFramework community where a few addon libraries have been vetted and proven outside of the core code, then integrated later on. That being said, the huge compatibility list a *great* resource and basis for organizing work for a number of people. Sometimes, QA is great help in defining what makes sense beyond the developer perspective. Throw that up on a wiki with checkboxes and bring your students in on a “make an external/abstraction party”. :) > On Feb 21, 2016, at 10:14 PM, pd-list-request(a)lists.iem.at wrote: > > The repo is a fork from the last update in previous maintenance (cyclone version 0.2beta1), which was on its own a fork from cyclone's repo for version 0.1-Alpha56 (available in Pd Extended). Fred did a large amount of work in bring cyclone forward, build-wise and bug wise. Why wouldn’t you start with his work? Seems like a step backwards after all of this... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

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

Jump to page:

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 February 2016