Re: [PD-dev] Separating GUI from the engine in PD
On Mon Mar 12, 2007 at 11:08:42AM +0100, Pierpaolo Marcon wrote: I'm trying to put Pd on a DSP processor, but I need to separate completely the Pd engine from the GUI. Does anybody knows if it is available on the web the Pd engine code? (without GUI) sure.. just download PD from miller puckette's website. delete the GUI files, disable it in the makefile and on launch.. the desireData branch has gone further than that, but im not sure how well it works with nogui. youre porably better off using csound, supercollider, or chuck, if you dont want a GUi, for the time being ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: Request for dev access
On Wed Feb 14, 2007 at 03:15:10PM -0700, Luke Iannini (pd) wrote: Sorry, posted this to the wrong list the first time. Thanks Frank Hallo, I'd like to be added to the CVS dev list, such that I can begin posting a few of the publicly-useful abstractions I've been working on, and more presently to get the mmonoplayer externals added. I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project. i'd be more interested in moving us over to Git, so i can stop getting these emails. what do we need. a webpage to register repos? Reasons for my admission include the bad luck of a prime number of developers. Thanks! Luke proyekto.net ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended build logs
On Sat Jan 27, 2007 at 05:06:06PM -0500, Hans-Christoph Steiner wrote: On Jan 27, 2007, at 5:56 AM, Georg Holzmann wrote: Hallo! The Windows scripts might not send emails, since it's a pain to do that on Windows. Feel free to get that working. How should I get this working ? - I would have to log me into the windows machine ... Get it working on any machine, then check it into CVS. That's what the auto-builds use. Ideally, it would use only software in Cygwin or MinGW. So someone needs to figure out how to send emails from a script on a Windows machine. or you could just commit the build log to a file and use CVS's equivalenet of .git/hooks/post-commit to send it from the CVS server.. which is more likely to be able to get mails through the -cvs list address anyways .hc LG Georg As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended build system questions
On Mon Jan 08, 2007 at 04:30:20PM -0500, Hans-Christoph Steiner wrote: On Jan 8, 2007, at 1:21 PM, Georg Holzmann wrote: Hallo! Okay, I build now a shared library because I have a lot of shared code - it will be installed in the same directory as the pd externals. Hm - I just noted that the shared library can't be found now... Where do I have to install them now on all the platforms ? E.g. on linux do I have to install it now to /usr/lib or something similar - or is it also possible to install it somewhere relative to the pd binary ? Wow, that's great that you have a shared library already! Since Pd-extended is built with gcc on all platforms, porting the build process to other platforms isn't too difficult, its mostly a matter of getting the right flags, which are listed in externals/Makefile. As for using the shared library, I think that you have to explicitly load it in each external. You can look at pd/src/s_loader.c to see how Pd does it. An external is just a shared libray that Pd loads, so its the same mechanism. maybe the dlopen part. the library search part is hand-rolled. so putting things in /usr/lib won't get youa nything.. .hc Thanks, LG Georg News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended build system questions
On Tue Jan 09, 2007 at 12:03:14AM +0100, Georg Holzmann wrote: Hallo! So is there a way how the externals can find the shared library, whithout copying it into a global library path like /usr/lib/ ? It seems that the only way is, to add the /full/path/to/installed/library/directory to the LD_LIBRARY_PATH variable before starting pd ... I think you can link to it using a relative path, or even better, just the same dir, i.e. . Mac OS X has handy tools for managing library paths (otool -L and install_name_tool), I don't know about other platforms. . does not work on linux - I would have to install the library first and then link it to the full path where I have it installed. So it seems that the only way is to use dlopen() - where I have to modify the source (and handle it seperate for all platforms in the source file ...). I think it's not worth to do that for PDContainer - but we can continue to think about it if we can also use it for other externals ;) how about modifying s_loader to also check in system paths for externals.. then you could reuse the same method regardless of whether its external to PD, or external to PD externals.. LG Georg ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
Automatic type conversion sounds like a really bad idea if the language only partially supports it. Pd is strongly typed is it? it mainly has numbers that occasionally look like symbols, and symbols that more than occasionally look like lists and/or strings.. , so what Martin says is definitely appropriate. Perl is the opposite, everything can be automatically cast, so there it makes sense. it is definitely a design decision which way to go. could PD flexibly support both at once? or does there need to be an OCaml edition, and a Perl edition? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strings
Automatic type conversion sounds like a really bad idea if the language only partially supports it. Pd is strongly typed do you think the target user base wants to think in terms of casting types? i don't. i have a feeling that was why there are so few types. i think most users wan't to be able to plug anything into anythign and at least get some sort of result, more than expected bang, got '' scrolling 1000 times a second in stderr... my vote would be a nice selection of types, and autocasting (maybe warnings at most for int vs float, string to symbol, etc) of course the only real way to vote for this would be write the code - i think i'll wait for PNPD instead.. :) ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] moving iemgui from core to extra
If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports. Only the bare minimum is in the language itself. Everything else is a library. in Python 2.5, Tk is still a configure-time option, which means, TkInter isnt shipped as a seperate library (Even TCL ships Tk seperately). likewise, the JVM from sun includes a GUI as well. the Squeak VM includes a gui, debugger, source code editor, etc. these GUIs may be shipped as nonoptional parts of the core, but presambly they do have their own namespace and installation directory on disk - does this mean we'll be cerating [iemgui/numbox2]'s in patches soon (or [declare import iemgui] or whatever)? my question would be... what do you get out of this change. other than make people's patches slightly harder to build, and have to worry about getting your changes incorporated into miller's version or continually move around files every version bump.. i guess the prefs dialog has a setting for default library imports? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] ChangeLogs
ive found the file src/ChangeLog on the devel_0_39 branch, which contains some information on ImPd 0.37 through DesireData 0.39. are the changes from the devel branch documented somewhere? things like the scheduler, audio interfaces, SIMD/vectorization/memory-alignment, whatever else may be different.. likewise, is there a changelog for monsieur poquette's version? ive heard that its 1.manual/x5.htm, but that file doesn't exist in the devel branch.. - cdr ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
and that is the question: why do we necessarily need the fftw based fft-objects in plain pd and cannot use externals? so the only drawback is see is: the objects are called [fftw~] instead of [fft~]; but lo and behold, i vaguely remembered krzysztof magic in cyclone, where a newly loaded class raises itself over an already existing class. while he is using it to overwrite objects from other externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this should not work with internals. et voila, does this not sound good? sounds good. maybe there should be some official policy on the overloading of internals? mfg.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Refactoring Pure Data
On Mon Sep 11, 2006 at 02:21:33PM +0200, Vincent Lordier wrote: Hi enthusiasts devs ! I want to work on pd's code readability and structure, only refactoring, not adding new features. (http://en.wikipedia.org/wiki/Refactoring) The final goal is to make PD easy to scale (desactivate MIDI, Audio, Network, some CoreLibs, ...) 'We've got to undo the MIDI revolution! said Miller' = Well, as far as I know, removing MIDI from PD's hairy code isn't as easy as ./configure --nomidi' make install ... yet ! There is quite a bit to do in this area, some of it is just renaming, indenting, some of it might be cleaning out stuff.h to separate clearly MIDI, Audio, engine, GUI and CoreLibs. Again, my goal is not to alter pd in its behavior (yet), nor optimizing anything (yet), just to improve readability and separation of modules. Any help on this and / or pointers to previous work is welcomed :) I want to make it easier for anyone to get into the code, to maintain it and to address issues like portability (from embedded - PDa-like or even tinier - to bigger systems). BUT my main problem right now is : on which version / branch should I work on ? whichever you want. you cant work on the MAIN branch, since youre not g-d. if you work on the devel_0_39 branch yo might break it (it is currently used for DesireData and Vibrez, afaik). you might want to at least peak at the devel_0_39 branch, building with 'scons desire=1' since a lot of refactoring has already taken place, mainly in regards to GUI/engine seperation. i dont think anyone has taken on moving all the 'internals' to 'externals'. since the only thing differentiationg an internal and an external is the makefile, and where the source resides (As it is, many externals use private 'internal' headers)... ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
