Pd-dev August 2004

pd-dev@lists.iem.at

31 participants
33 discussions

Pdplay?
by Nicola Bernardini 21 Oct '04

21 Oct '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, at the SOb project (http://www.soundobject.org) we're writing some really cool physical model objects which we are soon going to package and propose to the pure-data externals repository (they are GNU/GPL). However, we now have a problem that we want to solve soon: we need standalone versions of some demo applications (possibly running griPD etc.) we did. It would be nice to have a sort of MaxPlay type of thing (how about PdPlay?). I have some ideas on how to do it and it could be trivial, and therefore it is very probable that someone has already done it somewhere. If no one has done it, I'll hack up one solution and report back to the list as soon as it is done (it is going to be GNU/GPL anyway :). Thank you in advance for all the help you will want to give. nicb +--------------------------------------------------------------------+ |Nicola Bernardini | |E-mail: nicb(a)centrotemporeale.it | |GPG Fingerprint = 6AE6 AF21 E160 D9B3 396E EBAC 906C CFAE 4D65 D910| |Neither MS-Word nor MS-PowerPoint attachments please: | |http://www.fsf.org/philosophy/no-word-attachments.html | +--------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE9mf2qkGzPrk1l2RARAqi/AJ92NXY9HoDWlMbRcu59RkUQNH8E7gCeLU07 +ocbGJWYRzzrrdQO/cG0BcM= =TT6i -----END PGP SIGNATURE-----

5 7

redundancy - just another sound file player
by Thomas Grill 22 Sep '04

22 Sep '04

Hi all, for all who need it, i throw it into the arena. Maybe some of you want to try it out and comment on it - i currently don't have time to work more on it. I have a video/audio installation (together with Martin Pi, see http://freebitflows.t0.or.at/f/exhibition/corrosion) running right now, which suffers from the fact that i could not get one of the PD sound file players to work reliably, so i wrote one from scratch. Attached is a flext-based sketch for a player with the following characteristics: - uses libsndfile (http://www.mega-nerd.com/libsndfile/) and flext 0.4.6 (http://grrrr.org/ext/flext ) - should read _MANY_ file formats - safe loading/starting (no garbage output) - optimized design for many parallel players - on the fly tuneable buffer settings - double buffering for glitch-free seek and file change - currently no varispeed capabilities - currently lacking diagnosis capabilities It is called sfplay~, a naming which should probably change because it clashes with cyclone.... For the future, either i'm going to modify one of the existing implementations (probably reasdsf~) or (with many more features) incorporate it into the xsample package. best greetings, Thomas

3 7

Re: [PD-dev] PD devel_0_37 problems
by Thomas Grill 30 Aug '04

30 Aug '04

Oops, > of course there is a runtime check, but i never had the chance to test it > for Athlon chips.. hard to believe their feature bits are incompatible to > Intel but who knows. I'll have a look. not true - flext-centered me. The runtime check is only implemented in flext, not in vanilla PD. It should be an easy thing to transfer it, though. best greetings, Thomas

3 2

PD devel_0_37 problems
by Bartlomiej Bazior 30 Aug '04

30 Aug '04

Hi all, Recently I've tried, to build and run devel branch of pure-data, but encountered problems, that just can't use pd. But let's cut to the chase. Shortly speaking - putting some tilde object (like dac~, loop~, *~ etc.) and turning on dsp, causes pd to crash (and program throws this on the console: Pd: signal 4 pd_gui: pd process exited Pure-data behaviour can be split in to 2 situations depending on when audio processing was enabled. Scenario 1. Right after running pd, I put a dac~ object (I've also tried with loop~, tabread~, sig~, osc~). I can move it, select/deselect it, and nothing happens. Then I turn on dsp, and pd exits. Scenario 2. Right after running pd I turn on dsp. Then create new patch and put dac~ (also tried with loop~, sig~, *~, osc~) and it works to the moment where I deselect that object, select it (I can even move it), and deselect it again. I can throw as many tilde objects as I like to, but selecting any previously created object, and then deselecting it causes pd to exit. Also connecting audio objects (even if none of them is selected), ends that same way (but connecting non-audio objects to audio objects works fine). When I create at least one ~ object and turn _off_ dsp nothing happens, but the turning it on again causes crash. I didn't encounter any problems when audio processing was off, or when it was on, but without use of any non-audio objects. I build devel_0_37 without threaded soundfiler - I just did: ./configure --prefix=/usr/local/pd_dev --enable-debug My system is Slackware 9.1 (kernel 2.6.5) with tcl/tk-8.4.4, gcc-3.2.3, alsa-1.0.3. I have Terratec DMX6fire card sitting in computer based on Athlon (thunderbird) processor. I've also tried devel branch on windows - strangely ending with the same problem (I used msvc++ 7 to build pure-data). Tim Blechmann suggested to debug pd in gdb. The backtrace after crash looks like this: #0 0x080b2877 in sig_tilde_perf_sse_gcc () #1 0x08092065 in dsp_tick () at d_ugen.c:321 Does anyone have some ideas, about what's really happening, and most important how to avoid or fix this problem? Thanks in advance. cheers, Bart

4 3

starting pd from tcl
by 0001 30 Aug '04

30 Aug '04

hi all. I'm trying to find a more reliable way of starting pd on OSX from AppMain.tcl currently, I depend on pd being able to listen to the default port (5400). pd usually gets to bind to this port except if somebody else is using it. This can be detected in Tcl using netstat. But if you quit pd, the port is unusable for some time and won't show up in netstat. So It seems I need either a way to detect the usability of the port in Tcl (trying to make a server socket won't report any error) or a clean way for pd to tell the Tcl code which port it has picked any advice on this would be welcome. ... gerard

2 3

m_pd.h multiple defs with g++-3.3!
by James Tittle II 30 Aug '04

30 Aug '04

...I wrote about this back on march 21st, but apparently no one decided to change it: when compiling GEM against m_pd.h from pd-0.37-4, g++-3.3 gives well over 1000 warnings, all about redefinition! yechh...an easy fix is just to remove the following in m_pd.h from around line 341; EXTERN_STRUCT _inlet; #define t_inlet struct _inlet EXTERN_STRUCT _outlet; #define t_outlet struct _outlet ...it can be removed because it is already defined around line 147... ...this is also true for devel_pd: I'd change it, but strangely don't have access to the pure_data externals repository...who can I pester for this? Miller, can you also change this in your distro, pretty please? l8r, james

3 2

small gizmos
by Tom Schouten 28 Aug '04

28 Aug '04

hi all, just polling for reactions. i noticed 2 things: * pd and forth mix very well * forth and microcontrollers mix very well i had this idea of writing a forth for a picmicro, which consists of 2 linked forths, one running on the host, one on the target. which effectively enables you to have a 'shell' on a microcontroller over a serial line, or midi, or another bus. it's not working yet, mostly because i just was too scared to apply power to that picmicro circuit, but the start of the idea is on my zwizwa site. the design is mostly ready, the implementation sucks and needs to be redone. this forth (badnop) is actually the one that made me write mole, and mole, which is no more than a geek toy atm, eventually lead to a better pf. it took me a while to get right. once you start writing forths.. now, i was thinking. why not just make mole to be the host forth, choose an architecture, and start develloping some standard microcontroller protocol for pd, so you could eventually just abstract (a program running on) a microcontroller as a pd object. i'm currently using the picmicro 18f452 as a target chip, which is not extremely fast and cheap and all, but has an instruction set that maps very well to forth, so i can compile directly to binary code. no need for closed source tools etc.. (generated code is peephole-optimized and actually works in the simulator :) i'd like to eventually design it that the target does not matter, but i'd like to get the rest working first. now, i know this has a lot of 'forth' in it, but would anyone be remotely interested in helping to design/implement it further? it's not too hard to actually do, most of it already works except the hardware part, and might be pretty useful. the thing for me to find out is how 'standard' i can make the way to plug this into pd. i can go on a solo tour and say 'just use mole', but i'd like to somehow take this to a higher level. maybe writing some basic library to run on a micro. any idea would be welcome. cheers tom

5 9

position of switch~ in dsp patch
by Tim Blechmann 28 Aug '04

28 Aug '04

hi all ... today i figured out something _really_ strange ... in a subpatch i was using, i had a |switch~| object. when i switch~ed on dsp for the subpatch, i got an audio dropout. i'm not sure, if it's useful information, but this subpatch had several subpatches, with one of them using blocksize 8192 and overlapping 8 ... anyway, i figured out, that the switch~ object was the first object to be created on this specific canvas: #N canvas 309 104 450 300 dsp 0; #X obj 23 40 switch~; when i edited the patch to load the switch~ object at the end, the doesn't occur any more ... i'm not sure, what exactly could cause this behaviour, but it seems that the time of creating the switch~ is crutial for it's behaviour ... i consider this as a bug ... maybe i'll have some time to look into it, but not today... cheers... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

2 1

binbuf_addv, t_int to int for "i" args?
by Miller Puckette 27 Aug '04

27 Aug '04

Hi all, It looks like "binbuf_addv()", which gets called many places in Pd to save objects' state, expects integer arguments of type "t_int". This is fine except on systems (athlon64 for instance) where t_int is bigger than int. In lots of the calls the int args aren't cast to t_int but are just integers. I think I should change binbuf_addv() so that integer arguments are simply "int", not "t_int". Can I do this without causing a lot of headaches for extern writers? (I think it should be OK since Pd doesn't work at all on athlon64 as it is...) The alternative would be to use (t_int) casts everywhere, but really, the "int" argument is intended as a convenience; the data gets converted to a float anyway... cheers Miller

5 11

Including abstractions in the distros
by Hans-Christoph Steiner 25 Aug '04

25 Aug '04

I would like to start adding in all of the useful abstractions to the various Pd distros and I think we should work out a standard way of doing it. The way I see it, abstractions fall into two categories: external objects just like those written in C, C++, whatever; and, performance/tutorial/demo/etc. patches. - for the first type (externals written in Pd): it seems to me that these should be in a directory much like "extra" which would be added to the path. I think that using externals written in Pd should be as transparent as using an external written in C/C++/etc. Perhaps these should just be put in the "extra" folder like all of the compiled objects as well. - for the second type (performance/tutorial/demo/etc. patches): these should be in a browsable, organized layout so that anyone can look thru them all and try out various things. Thoughts, suggestions, comments? .hc ________________________________________________________________________ ____ Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev August 2004