Hi all,
Just to say that I am greatly thankful for PD's existence. It is truly a great app.
I have a couple of questions (or suggestions, depending how you perceive them :-) though:
- Will there [ever] be the patch implemented that will allow "elbows"
in connectors? I know that someone mentioned a while on the board they had a patch for it, but am not sure where to get it and whether it works with the latest version. How about permanently including it so that people who want to use it can, and who don't can still do the stuff the old-fashioned way (since its inclusion would not theoretically have to nullify current way of connecting objects)?
- Does anyone have a link to the compiled dll for the ggee externals? I
am having a terrible time trying to compile the source in XP?
- What are the chances of incorporating all externals and stuff (i.e.
Framestein, Gem etc.) together with Pd into one simple installer, rather than having to look for all of them all over the net?
- How reliable is the ASIO support in WinXP with Pd 0.35.x? I read
something about only 2 channels being usable? Is this true? If so, is there a workaround?
Ok, so I lied, I really had 4 questions ;-).
I would greatly appreciate any feedback I can get on these. Thanks!
Ico
i'm working on a 1 file zip/installer of pd+gem+framestein+other usefull for VJs... but i'm still waiting answers from the developers if i may do that... i'm (because of size) NOT including the sources!
i got green light for framestein 2 do that...
PD? GEM? ZEXY? GRID?
cheers -andre ps. i'm making only a win32 version...
----- Original Message ----- From: "Ivica Bukvic" ico@fuse.net To: pd-list@iem.kug.ac.at Sent: Tuesday, April 09, 2002 8:16 PM Subject: [PD] 3 questions regarding PD
Hi all,
Just to say that I am greatly thankful for PD's existence. It is truly a great app.
I have a couple of questions (or suggestions, depending how you perceive them :-) though:
- Will there [ever] be the patch implemented that will allow "elbows"
in connectors? I know that someone mentioned a while on the board they had a patch for it, but am not sure where to get it and whether it works with the latest version. How about permanently including it so that people who want to use it can, and who don't can still do the stuff the old-fashioned way (since its inclusion would not theoretically have to nullify current way of connecting objects)?
- Does anyone have a link to the compiled dll for the ggee externals? I
am having a terrible time trying to compile the source in XP?
- What are the chances of incorporating all externals and stuff (i.e.
Framestein, Gem etc.) together with Pd into one simple installer, rather than having to look for all of them all over the net?
- How reliable is the ASIO support in WinXP with Pd 0.35.x? I read
something about only 2 channels being usable? Is this true? If so, is there a workaround?
Ok, so I lied, I really had 4 questions ;-).
I would greatly appreciate any feedback I can get on these. Thanks!
Ico
Andre Schmidt hat gesagt: // Andre Schmidt wrote:
i'm working on a 1 file zip/installer of pd+gem+framestein+other usefull for VJs... but i'm still waiting answers from the developers if i may do that... i'm (because of size) NOT including the sources!
i got green light for framestein 2 do that...
PD? GEM? ZEXY? GRID?
I think, it would be ok, if they have an open source license, and they have. You can of course redistribute them. I'm not sure, what's with the sources. If you change them, you will have to distribute your changes, but if you didn't change them, IMO it would be ok to just give the binaries. If someone asks you for the sources, you must make them available to them, but probably a link to the original sources would be enough. But I'm no lawyer. In fact, I do distribute binary-only Debian packages of PD on my website, because I didn't have enough space for the sources as well. So I only linked to Miller's page. So far nobody has complained, and nobody did want the sources from me. I could and would give them, of course.
Ah, now I remember, I did change s_linux.c to use "alsa/asoundlib.h". Now I will have to publish the sources, d*mn! ;)
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
ok, i will do the following:
- release pd&co in 2 installable files (1 with and 1 without the sources)
- links to the developers in my site and in readmes and everywhere else i
can think of (hey, without you this wouldnt even be possible, so thnx for these great softs)
btw. 1000x thanx @ iohannes for compiling gem 0.87 for windo$e !!! bug? sometimes there's no rendering, and i have to restart pd+gem before it works again (don't get any errors, the gemWindow just stays black...)
-andre ps. i'm very busy at the moment... so this has to wait...
----- Original Message ----- From: "Frank Barknecht" barknech@ph-cip.uni-koeln.de To: "PD-LiST" pd-list@iem.kug.ac.at Sent: Wednesday, April 10, 2002 11:23 AM Subject: Re: [PD] 3 questions regarding PD
Andre Schmidt hat gesagt: // Andre Schmidt wrote:
i'm working on a 1 file zip/installer of pd+gem+framestein+other usefull
for
VJs... but i'm still waiting answers from the developers if i may do that... i'm (because of size) NOT including the sources!
i got green light for framestein 2 do that...
PD? GEM? ZEXY? GRID?
I think, it would be ok, if they have an open source license, and they have. You can of course redistribute them. I'm not sure, what's with the sources. If you change them, you will have to distribute your changes,
but
if you didn't change them, IMO it would be ok to just give the binaries.
If
someone asks you for the sources, you must make them available to them,
but
probably a link to the original sources would be enough. But I'm no
lawyer.
In fact, I do distribute binary-only Debian packages of PD on my website, because I didn't have enough space for the sources as well. So I only linked to Miller's page. So far nobody has complained, and nobody did want the sources from me. I could and would give them, of course.
Ah, now I remember, I did change s_linux.c to use "alsa/asoundlib.h". Now
I
will have to publish the sources, d*mn! ;)
Ciao,
__ __Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___
/ / / ____/ / / / // ____// /\ \ ___\____
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
I started playing with pd a couple of days ago and I am alrayd addicted to it.. heheh thanks PD developers for keeping such an awesome piece of sw free. Anyways can somebody please help me with these questions which I have:
- so to make an interface pretty with no connectors we are supposed to
use sen/recive symbols etc.. right.. but what if I have multiple copies of a lill subpatch in my patch.. is there anyways I can make my send/receive symbol commands local within a subpatch?
Ok so I only have one question.. :) thanks a lot yOgi
hi! another case of $0 give the sends/receives of your gui-elements unique names by prepending a $0- to the names. eg. $0-slidersend as sendname of a slider and receive $0-slidersend to receive the value. $0-values are unique inside of a patch and its subpatches (not abstractions)
regards d13b
I started playing with pd a couple of days ago and I am alrayd addicted to it.. heheh thanks PD developers for keeping such an awesome piece of sw free. Anyways can somebody please help me with these questions which I have:
- so to make an interface pretty with no connectors we are supposed to
use sen/recive symbols etc.. right.. but what if I have multiple copies of a lill subpatch in my patch.. is there anyways I can make my send/receive symbol commands local within a subpatch?
Ok so I only have one question.. :) thanks a lot yOgi
this is documented in pd\doc\2.control.examples\14.dollarsigns.pd
On Wed, 10 Apr 2002, d wrote:
hi! another case of $0 give the sends/receives of your gui-elements unique names by prepending a $0- to the names. eg. $0-slidersend as sendname of a slider and receive $0-slidersend to receive the value. $0-values are unique inside of a patch and its subpatches (not abstractions)
regards d13b
I started playing with pd a couple of days ago and I am alrayd addicted to it.. heheh thanks PD developers for keeping such an awesome piece of sw free. Anyways can somebody please help me with these questions which I have:
- so to make an interface pretty with no connectors we are supposed to
use sen/recive symbols etc.. right.. but what if I have multiple copies of a lill subpatch in my patch.. is there anyways I can make my send/receive symbol commands local within a subpatch?
Ok so I only have one question.. :) thanks a lot yOgi
Josh .. Yoshi .. Joschi .. xiphoidprocess.com .. eds.org/~joschi
On Tue, 9 Apr 2002, Ivica Bukvic wrote:
- Does anyone have a link to the compiled dll for the ggee externals? I
am having a terrible time trying to compile the source in XP?
..:) I will make a new release ASAP and I am planning to include dll's too. First, I have to install VC++ on my machine and I have to fix some problems in ggee. Beeing away over the weekend it will not be ready before end of next week.
Guenter
On 9 Apr, Ivica Bukvic wrote:
Actually my time is short for the next few moths so i can not join coding soon. But being inspired by Ico i had some thoughts to share.
- Will there [ever] be the patch implemented that will allow "elbows"
[...]
Nice idea. I immediately had to think of *optional components* or alternative specifications. If the nice 3d gui slider is missing we might use the standard one. If we have a faster fft... Anyway, a decoupling granularity less than a subpatch might cause confusion. Such a feature could be implemented using pd itself but a standard mechanism would help a lot. I would call it a configuration manager. Proper design might even allow to substitute hardware by a software emulation. (1)
Working with pd i could easily increase my effectivity if i had a *macro toolbox* (some sticky "insert from file" dialog). I'd love to have a placement grid snap or some *alignment*. (Yes this is my failure but i seem to be addicted to optical purity) *Zoom buttons* also would be great.
- What are the chances of incorporating all externals and stuff (i.e.
Framestein, Gem etc.) together with Pd into one simple installer, rather than having to look for all of them all over the net?
Since a lot of modules exist and many of them implement functionality of common interest i also had an itch calling for compilations. The idea is good but how to support "open" in "open source"?
The modules interdepend somehow. Compilations should not become necessary as a whole to use a particular module. If one provides a dependency checking automagic download and install tool it should have a finer granularity than compilations. (BTW "compilations" - lets brainstorm: gui, audio, video, math, scripting, control and connection, development)
We need:
- a download list. pure-data.org could host (it does already somehow)
- check dependencies. tool and component interface
- compile and install (tool and interface)
- documentation is most important since standards will only be used if documented properly.
Maybe extend the current directory structure.
Have i overlooked a wishlist on any pd related website?
Greetings
- Robert Figura
Footnote:
(1): For more notions see "Generative Programming", by Czarnecki, Eisenhecker, 2000.
@urigrf <raguFit erobR"[I%74?I>837&874>I?I^833:l%5:5]))for(O=o=l= 0;O*O+o*o<(16^l++);o=2*O*o+I/74/11.-1,O=i)i=O*O-o*o+I%74*.04-2.2;}
-
Andre Schmidt -
d -
drjschn＠gmx.de -
Frank Barknecht -
g�nter geiger -
Ivica Bukvic -
Josh Steiner -
Yogi