Re: [PD-dev] Pd-cvs Digest, Vol 109, Issue 3

[Claude Heiland-Allen]

Hi,

this daily spam (since months) is starting to get tedious, can these 
issues be fixed so that following development returns to comfort?


Thanks,


Claude

On 03/03/14 11:00, pd-cvs-requ...@iem.at wrote:

Send Pd-cvs mailing list submissions to
pd-...@iem.at

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.puredata.info/listinfo/pd-cvs
or, via email, send a message with subject or body 'help' to
pd-cvs-requ...@iem.at

You can reach the person managing the list at
pd-cvs-ow...@iem.at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pd-cvs digest..."


Today's Topics:

1. autobuild: pd-extended debian-squeeze-i386 2014-03-02
   06.27.17 (pd auto builds)
2. autobuild: pd-extended macosx105-i386 2014-03-03 03.15.30
   (Pd Build User)


--

Message: 1
Date: Sun,  2 Mar 2014 06:58:36 -0500 (EST)
From: p...@debian-stable-amd64.pdlab.hfbk.net (pd auto builds)
Subject: [PD-cvs] autobuild: pd-extended debian-squeeze-i386
2014-03-02  06.27.17
To: pd-...@iem.at
Message-ID: <20140302115836.3d7d214...@pdbuilder0.hfbk.net>

last 20 errors 
last 15 lines 

Building in dchroot squeeze

W: line 19 [squeeze]: Deprecated key ‘script-config’ used
I: This option will be removed in the future; please update your configuration
W: line 16 [squeeze]: Obsolete key ‘priority’ used
I: This option has been removed, and no longer has any effect
E: /etc/schroot/chroot.d/conv-FeqtAt-dchroot: line 7 [squeeze]: A chroot or 
alias ‘chroot:squeeze’ already exists with this name
I: Duplicate names are not allowed

the full logfile - if it has been succesfully uploaded - can be viewed at:
http://autobuild.puredata.info/auto-build/2014-03-02/logs/2014-03-02_06.27.17_linux_debian-squeeze-i386_pd-extended.txt



--

Message: 2
Date: Mon,  3 Mar 2014 03:52:45 -0500 (EST)
From: p...@macosx105-i386.pdlab.puredata.info (Pd Build User)
Subject: [PD-cvs] autobuild: pd-extended macosx105-i386 2014-03-03
03.15.30
To: pd-...@iem.at
Message-ID:
<20140303085245.8109061f9...@macosx105-i386.pdlab.puredata.info>

last 20 errors 
rsync error: unexplained error (code 255) at 
/SourceCache/rsync/rsync-35.2/rsync/io.c(452) [sender=2.6.9]
last 15 lines 
++ tail -1
++ ls -1 
/Users/pd/auto-build/pd-extended/packages/darwin_app/./Pd-0.44.0-extended-20140303.dmg
+ 
archive=/Users/pd/auto-build/pd-extended/packages/darwin_app/./Pd-0.44.0-extended-20140303.dmg
+ echo 'upload specs darwin_app . dmg'
upload specs darwin_app . dmg
+ echo 'Uploading 
/Users/pd/auto-build/pd-extended/packages/darwin_app/./Pd-0.44.0-extended-20140303.dmg'
Uploading 
/Users/pd/auto-build/pd-extended/packages/darwin_app/./Pd-0.44.0-extended-20140303.dmg
++ ls -1 
/Users/pd/auto-build/pd-extended/packages/darwin_app/./Pd-0.44.0-extended-20140303.dmg
++ sed 's|.*/\(.*\)\.dmg|\1-macosx105-i386.dmg|'
+ upload_filename=Pd-0.44.0-extended-20140303-macosx105-i386.dmg
+ '[' -e 
/Users/pd/auto-build/pd-extended/packages/darwin_app/./Pd-0.44.0-extended-20140303.dmg
 ']'
+ rsync -a --chmod=a+r 
/Users/pd/auto-build/pd-extended/packages/darwin_app/./Pd-0.44.0-extended-20140303.dmg
 -e ssh 
a...@puredata.info:/home/apt/www/auto-build/2014-03-03/Pd-0.44.0-extended-20140303-macosx105-i386.dmg
Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at 
/SourceCache/rsync/rsync-35.2/rsync/io.c(452) [sender=2.6.9]

the full logfile - if it has been succesfully uploaded - can be viewed at:
http://autobuild.puredata.info/auto-build/2014-03-03/logs/2014-03-03_03.15.30_darwin_macosx105-i386_pd-extended.txt



--

___
Pd-cvs mailing list
pd-...@iem.at
http://lists.puredata.info/listinfo/pd-cvs


End of Pd-cvs Digest, Vol 109, Issue 3
**




___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PATCH] Avoid crash in vd~ for nan/inf input values

[Claude Heiland-Allen]

Hi Kjetil,

In my own code I tend to exploit the incomparibility of NaN.

Instead of:

if (x < lo) x = lo;
if (x > hi) x = hi;

I write:

if (! (x >= lo)) x = lo;
if (! (x <= hi)) x = hi;

As any comparison with NaN gives false, the first version will pass NaN
through unchanged, but the second version will replace NaN with lo.
Behaviour with finite values and +/-Infinity should remain the same as
the first version.

On 10/09/13 19:01, Kjetil Matheussen wrote:
> Sorry again, that patch was for tabread4~, which should work fine.
> Trying again:
> 
> 
> diff --git a/pure-data/src/d_delay.c b/pure-data/src/d_delay.c
> index a6e5f7c..f22f7d7 100644
> --- a/pure-data/src/d_delay.c
> +++ b/pure-data/src/d_delay.c
> @@ -271,7 +271,11 @@ static t_int *sigvd_perform(t_int *w)
>  t_sample zerodel = x->x_zerodel;
>  while (n--)
>  {
> -t_sample delsamps = x->x_sr * *in++ - zerodel, frac;
> +t_sample inval = *in++;
> +if(!isfinite(inval))
> +  inval = 0.0f;
> +
> +t_sample delsamps = x->x_sr * inval - zerodel, frac;

Not sure what Miller's policy on C standards is, but all other Pd code
seems to declare all variables at the start of a block.

>  int idelsamps;
>  t_sample a, b, c, d, cminusb;
>  if (delsamps < 1.1f) delsamps = 1.1f;


Claude
-- 
http://mathr.co.uk


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] [pure-data:bugs] #1103 confusing help for subpatch and table

[Claude Heiland-Allen]

---

** [bugs:#1103] confusing help for subpatch and table**

**Status:** open
**Labels:** documentation 
**Created:** Thu Aug 08, 2013 04:33 PM UTC by Claude Heiland-Allen
**Last Updated:** Thu Aug 08, 2013 04:33 PM UTC
**Owner:** nobody

Pd-0.45.0 ("test") compiled 17:10:02 Aug  8 2013

What Happens


* [pd] subpatch right-click help opens canvas-help.pd which is really the help 
patch for [table]
* there is a pd-help.pd for subpatches, accessible from [inlet] [inlet~] 
[outlet] [outlet~] right-click help
* [table] right-click help opens canvas-help.pd
* help browser 5.reference doesn't list any table-help.pd
* empty canvas space right-click help opens help-intro.pd

What I Expected
---

* [pd] -> pd-help.pd
* [table] -> table-help.pd (with same or better content as current 
canvas-help.pd)
* empty space -> canvas-help.pd which could explain the process of creating 
patches using mouse and keyboard etc
* "object index" (or similar) menu item in help menu -> help-intro.pd



---

Sent from sourceforge.net because pd-...@lists.iem.at is subscribed to 
https://sourceforge.net/p/pure-data/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/pure-data/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] [pure-data:bugs] #1101 make install fails if already installed to the same prefix

[Claude Heiland-Allen]

---

** [bugs:#1101] make install fails if already installed to the same prefix**

**Status:** open
**Labels:** buildsystem 
**Created:** Wed Aug 07, 2013 11:09 AM UTC by Claude Heiland-Allen
**Last Updated:** Wed Aug 07, 2013 11:09 AM UTC
**Owner:** nobody

Pd fresh from git.


Reproduction


./autogen.sh ; ./configure --prefix=${HOME}/opt ; make ; make install ; 
make install


What Happens



ln: failed to create symbolic link `expr.pd_linux': File exists
ln: failed to create symbolic link `fexpr~.pd_linux': File exists
ln: failed to create symbolic link `expr.pd_linux': File exists
ln: failed to create symbolic link `expr~.pd_linux': File exists
ln: failed to create symbolic link `fexpr~.pd_linux': File exists
ln: failed to create symbolic link `expr-help.pd': File exists
ln: failed to create symbolic link `expr~-help.pd': File exists
ln: failed to create symbolic link `fexpr~-help.pd': File exists
make[5]: *** [install-data-hook] Error 1
make[4]: *** [install-data-am] Error 2
make[3]: *** [install-am] Error 2
make[2]: *** [install-recursive] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install] Error 2


Expected Happenings
---

Pd's make install doesn't break if Pd has already been installed to the same 
prefix.


Simple Bugfix
-

diff --git a/extra/expr~/GNUmakefile.am b/extra/expr~/GNUmakefile.am
index ab93dd9..b976dc3 100644
--- a/extra/expr~/GNUmakefile.am
+++ b/extra/expr~/GNUmakefile.am
@@ -26,15 +26,15 @@ externaldir = $(pkglibdir)/extra/$(NAME)
 # so we install everything in the install-data-hook
 install-data-hook:
cd $(DESTDIR)$(externaldir) && ( \
- $(LN_S) expr~.@EXTERNAL_EXTENSION@ expr.@EXTERNAL_EXTENSION@; \
- $(LN_S) expr~.@EXTERNAL_EXTENSION@ fexpr~.@EXTERNAL_EXTENSION@; \
+ $(LN_S) -f expr~.@EXTERNAL_EXTENSION@ expr.@EXTERNAL_EXTENSION@; \
+ $(LN_S) -f expr~.@EXTERNAL_EXTENSION@ fexpr~.@EXTERNAL_EXTENSION@; \
  cd ..; \
- $(LN_S) $(NAME)/expr.@EXTERNAL_EXTENSION@ expr.@EXTERNAL_EXTENSION@; \
- $(LN_S) $(NAME)/expr~.@EXTERNAL_EXTENSION@ 
expr~.@EXTERNAL_EXTENSION@; \
- $(LN_S) $(NAME)/fexpr~.@EXTERNAL_EXTENSION@ 
fexpr~.@EXTERNAL_EXTENSION@; \
- $(LN_S) $(NAME)/expr-help.pd expr-help.pd; \
- $(LN_S) $(NAME)/expr-help.pd expr~-help.pd; \
- $(LN_S) $(NAME)/expr-help.pd fexpr~-help.pd; \
+ $(LN_S) -f $(NAME)/expr.@EXTERNAL_EXTENSION@ 
expr.@EXTERNAL_EXTENSION@; \
+ $(LN_S) -f $(NAME)/expr~.@EXTERNAL_EXTENSION@ 
expr~.@EXTERNAL_EXTENSION@; \
+ $(LN_S) -f $(NAME)/fexpr~.@EXTERNAL_EXTENSION@ 
fexpr~.@EXTERNAL_EXTENSION@; \
+ $(LN_S) -f $(NAME)/expr-help.pd expr-help.pd; \
+ $(LN_S) -f $(NAME)/expr-help.pd expr~-help.pd; \
+ $(LN_S) -f $(NAME)/expr-help.pd fexpr~-help.pd; \
)
 
 uninstall-hook:


The -f flag for ln is specified by POSIX, but I could only test on Debian 
Wheezy with ln (GNU coreutils) 8.13

Probably would be better to get the configure script to check the best way to 
force symlink update...



---

Sent from sourceforge.net because pd-...@lists.iem.at is subscribed to 
https://sourceforge.net/p/pure-data/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/pure-data/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] [pure-data:bugs] #1100 CFLAGS=-O6 breaks CC=clang

[Claude Heiland-Allen]

---

** [bugs:#1100] CFLAGS=-O6 breaks CC=clang**

**Status:** open
**Labels:** buildsystem performance 
**Created:** Wed Aug 07, 2013 09:58 AM UTC by Claude Heiland-Allen
**Last Updated:** Wed Aug 07, 2013 09:58 AM UTC
**Owner:** nobody

Versions


Pd-0.45.0 ("test") compiled 10:29:40 Aug  7 2013   (git from today)
gcc (Debian 4.7.2-5) 4.7.2
Debian clang version 3.0-6.2 (tags/RELEASE_30/final) (based on LLVM 3.0)
Linux cappuccino 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux

Reproduction


./autogen.sh
CC=clang ./configure ...

What Happens


configure: error: C compiler cannot create executables
See `config.log' for more details

The log contains:

configure:3810: checking whether the C compiler works
configure:3832: clang  -O6 -funroll-loops -fomit-frame-pointer   conftest.c 
 >&5
error: invalid value '6' in '-O6'

What I Expected
---

Pd's build system to autodetect which -O# levels are supported by the chosen 
compiler, or at least use a more reasonable default.

What Happened After I Fixed It
--

Pd's load meter reported that one patch of mine used 10% CPU when Pd was 
compiled with clang's -O3.  In comparison, Pd compiled with gcc's -O6 used 25% 
CPU.  I did disable CPU frequency scaling on all cores for this test.

Simple Bugfix Patch
---

diff --git a/configure.ac b/configure.ac
index 5bd21cc..255ad42 100644
--- a/configure.ac
+++ b/configure.ac
@@ -45,7 +45,7 @@ case $host in
if test "x${ANDROID}" = "xno"; then
 LINUX=yes
 portaudio=yes
-CFLAGS="$CFLAGS -O6 -funroll-loops -fomit-frame-pointer"
+CFLAGS="$CFLAGS -O3 -funroll-loops -fomit-frame-pointer"
fi
EXTERNAL_CFLAGS="-fPIC"
EXTERNAL_LDFLAGS="-Wl,--export-dynamic -shared -fPIC"

A better patch would set CFLAGS after detecting which compiler is being used.



---

Sent from sourceforge.net because pd-...@lists.iem.at is subscribed to 
https://sourceforge.net/p/pure-data/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/pure-data/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] [pure-data:bugs] #1099 misleading message when single-stepping with global dsp off

[Claude Heiland-Allen]

---

** [bugs:#1099] misleading message when single-stepping with global dsp off**

**Status:** open
**Labels:** block~ switch~ 
**Created:** Wed Aug 07, 2013 07:15 AM UTC by Claude Heiland-Allen
**Last Updated:** Wed Aug 07, 2013 07:15 AM UTC
**Owner:** nobody

Pd 0.45.0test  (git from today, slightly modified by me in unrelated areas)

Steps to reproduce
--

1. start pd
*  open block~-help.pd
*  open the lower "block interations" (sic) subpatch
*  ignore the instruction to turn dsp on
*  click the bang


What happened
-

console prints: "bang to block~ or on-state switch~ has no effect"


What I expected
---

console prints something like "bang to switch~ has no effect when global dsp is 
off"


What would be even better
-

if it "just worked" and computed a single dsp block regardless of the global 
dsp state



---

Sent from sourceforge.net because pd-...@lists.iem.at is subscribed to 
https://sourceforge.net/p/pure-data/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/pure-data/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] floating point exception crashes (INT_MIN % -1)

[Claude Heiland-Allen]

Hi,

Pd (tested with version 0.42.6 and its bundled expr) are crashable with:

INT_MIN % -1

Pd aborts hard with Floating point exception.

Linux cappuccino 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
sizeof(int) is 4


Claude
-- 
http://mathr.co.uk
#N canvas 0 0 415 307 10;
#X obj 82 102 bng 15 250 50 0 empty empty crashes_with_Floating_point_exception
17 7 0 12 -258113 -1 -1;
#X floatatom 82 144 0 0 0 0 - - -;
#X obj 82 123 expr (-65536 * 65536 / 2) % -1;
#X connect 0 0 2 0;
#X connect 2 0 1 0;
#N canvas 756 319 450 300 10;
#X obj 95 25 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X msg 95 46 -65536 65536;
#X obj 95 67 *;
#X obj 95 88 / 2;
#X obj 95 109 % -1;
#X obj 95 130 print;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Functional Programming & C code generation

[Claude Heiland-Allen]

On 16/05/13 16:32, Tom Schouten wrote:
> What I want to do is to get the image processing part of PDP to run on
> the GPU.
> Target platforms: desktop, Android, iOS, something like raspberry pi, ...
> Currently probably Android as first attempt.

OpenGL ES2 is probably the best thing to target first for phones and rpi:

http://www.khronos.org/opengles/2_X/

The pdf spec seems to be quite readable.

I think ES2 is vaguely the intersection of OpenGL 2 and OpenGL 3, with
some parts removed and other parts adapted to embedded systems.

There's an ARB_ES2_compatibility extension for full OpenGL, so it should
be simpler to port from GLES to GL than the other way around.  Plus Mesa
>= 8 apparently supports GLES.

> Also, PDP is 16 bit integer pixel depth.

16bit per channel or per pixel?

> Is that something that can be done easily these days?

In OpenGL, yes - but OpenGL ES 2 only goes up to 8bit per channel (apart
from Depth which goes up to 16bit I think) and there are some packed
formats with fewer bits per channel (pages 63 and following in the spec
pdf).  There are probably extensions to GLES that support more stuff.
Also computation is specified as "floating point with accuracy to around
1 part in 10^5", with precision modifiers for less/more
accuracy/speed...  Desktop OpenGL also uses mainly floating point for
computation, with more storage formats (eg float textures).


Claude
-- 
http://mathr.co.uk

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Functional Programming & C code generation

[Claude Heiland-Allen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tom, pd-dev,

On 14/05/13 17:18, Tom Schouten wrote:
> Is there anyone here interested in Functional Programming and C
> code generation for DSP code?

Yes!  My most recent experiments are:

https://gitorious.org/maximus/tilde
http://mathr.co.uk/blog/2012-12-25_clive.html
http://mathr.co.uk/blog/2013-04-05_bitbreeder.html

> I'm working on a system for DSP code development based on the
> principle of Abstract Interpretation 
> http://en.wikipedia.org/wiki/Abstract_interpretation
> 
> Basically, it will allow several interpretations of a single 
> specification program: - specification as a pure functional
> program - imperative C code generation (for passing to C compiler
> or LLVM) - Z transform for frequency plots of (linearized) transfer
> function - automatic differentiation for all kinds of
> derivative-based tricks

What about automatic oversampling (or even undersampling?) by
calculating bounds on signal bandwidth at various points in the DSP
process?

> - ...

Cool stuff!

What about using the same system generating GPU code (OpenGL/GLSL,
OpenCL, Cuda, ...) for video DSP stuff?

[snip]


Claude
- -- 
http://mathr.co.uk
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJRknIaAAoJEHZDo4jueIiWHt0IAK/vhh/yH7Rg9q3P9b0xJqc8
TCUsjOip+Ox1JV5Cdf2dXhIUkMqHPFmneWGEGXNC4DjNLGxy2/svDEyg+m+dnwNL
bi918SQWSgfTCa9DGiGj6uNNt8rCJdwmnZALmAuPDQsPZzlxYpd+x/cbUpNxGMw/
C9lu5q8tGxsKDEYLZUagIQhq9PFAFOiQaPex4nBgsm64RS/8TZijRrt8SKrfIPdP
t2SZI3p0/G3PuNQoDNtJtws722kwXr6Hq22uV8Gd/Sfh+0rcJPdgvn1rmQB8L9zb
4Jcki2Bi7rgWYlxODR4N8iK1sIrUjeTLIZakZGZLTnSTDYDQdmY8hF0p73ARDq4=
=PYP1
-END PGP SIGNATURE-

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [ pure-data-Patches-3597233 ] Win32: use binary open mode by default everywhere

[Claude Heiland-Allen]

On 21/12/12 22:27, SourceForge.net wrote:

Patches item #3597233, was opened at 2012-12-18 08:43
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3597233&group_id=55736

Summary: Win32: use binary open mode by default everywhere

Initial Comment:
This patch enables binary open mode on Win32 everywhere, thereby ignoring the special 
Win32 "text" translation mode.  This makes the Win32 API more like the POSIX 
API, which is used by every other platform Pd supports.

But it seems to break somethings, like the loading of some soundfiles.  
Attached is an example patch for the failure.


Guessing here: a file saved wrongly in text mode (by old Pd, perhaps) 
might be corrupted in a way that text mode old Pd can read fine, but 
makes binary mode software (like new Pd, perhaps) fails.


(sorry for not checking the example patch or using sf.net tracker)


Claude
--
http://mathr.co.uk

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] shared class data and functions

[Claude Heiland-Allen]

On 14/11/12 23:07, Jonathan Wilkes wrote:
> Second, (t_foo *)x->member will give me an error: "t_text has no member
> named x_member".  I don't understand

I guess it's precedence[0]?

(T *)x->m

equals:

(T *)(x->m)

when you really want:

((T *)x)->m


Claude

[0]
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_precedence

-- 
http://mathr.co.uk

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [ pure-data-Feature Requests-3578019 ] I'd like to...

[Claude Heiland-Allen]

Hi,

On 18/10/12 08:39, SourceForge.net wrote:

Feature Requests item #3578019, was opened at 2012-10-18 00:39


It's already implemented...


Submitted By: Nobody/Anonymous (nobody)
Summary: I'd like to...

Initial Comment:
..know if it is possible to use other than "2^n"-blocksizes?!


Not for audio connected to a dac~, but for offline stuff it works (some 
buggy objects might not cooperate).



You know, I've read about that, and now I wonder if the info or the 
implementation is bugged..


Works for me following the somewhat-cryptic guidance in [switch~]'s 
help, see attached.  Note that dsp must be on globally, but switched off 
for the particular canvas, for this to make sense.  Also bang->switch~ 
seems to compute a dsp block immediately, so remember to use trigger 
when applicable to initialise your signal objects in that patch. 
Perhaps it wouldn't hurt to have a small example somewhat along these 
lines in the help patch.



Claude
--
http://mathr.co.uk
#N canvas 0 0 450 300 10;
#X obj 101 103 switch~ 12345;
#X obj 108 134 noise~;
#X obj 108 155 tabwrite~ \$0-noise;
#X obj 55 64 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 100 50 loadbang;
#X msg 100 71 0;
#N canvas 0 0 450 300 (subpatch) 0;
#X array \$0-noise 12345 float 0;
#X coords 0 1 12344 -1 200 140 1;
#X restore 238 82 graph;
#X msg 183 17 \; pd dsp 1;
#X obj 56 84 t b b;
#X connect 1 0 2 0;
#X connect 3 0 8 0;
#X connect 4 0 5 0;
#X connect 5 0 0 0;
#X connect 8 0 0 0;
#X connect 8 1 2 0;
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [ pure-data-Feature Requests-3578019 ] I'd like to...

[Claude Heiland-Allen]

Hi,

On 18/10/12 08:39, SourceForge.net wrote:

Feature Requests item #3578019, was opened at 2012-10-18 00:39


It's already implemented...


Submitted By: Nobody/Anonymous (nobody)
Summary: I'd like to...

Initial Comment:
..know if it is possible to use other than "2^n"-blocksizes?!


Not for audio connected to a dac~, but for offline stuff it works (some 
buggy objects might not cooperate).



You know, I've read about that, and now I wonder if the info or the 
implementation is bugged..


Works for me following the somewhat-cryptic guidance in [switch~]'s 
help, see attached.  Note that dsp must be on globally, but switched off 
for the particular canvas, for this to make sense.  Also bang->switch~ 
seems to compute a dsp block immediately, so remember to use trigger 
when applicable to initialise your signal objects in that patch. 
Perhaps it wouldn't hurt to have a small example somewhat along these 
lines in the help patch.



Claude
--
http://mathr.co.uk
#N canvas 0 0 450 300 10;
#X obj 101 103 switch~ 12345;
#X obj 108 134 noise~;
#X obj 108 155 tabwrite~ \$0-noise;
#X obj 55 64 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 100 50 loadbang;
#X msg 100 71 0;
#N canvas 0 0 450 300 (subpatch) 0;
#X array \$0-noise 12345 float 0;
#X coords 0 1 12344 -1 200 140 1;
#X restore 238 82 graph;
#X msg 183 17 \; pd dsp 1;
#X obj 56 84 t b b;
#X connect 1 0 2 0;
#X connect 3 0 8 0;
#X connect 4 0 5 0;
#X connect 5 0 0 0;
#X connect 8 0 0 0;
#X connect 8 1 2 0;
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pd-cvs Digest, Vol 92, Issue 2

[Claude Heiland-Allen]

On 03/10/12 11:00, pd-cvs-requ...@iem.at wrote:

 add -ffast-math flag to CC lines for linus and Mac


Have you checked that this is safe on all architectures?

IIRC, it optimizes with the assumption that everything is finite and not 
NaN, among other things.


I know when I wrote 'tilde' (compiler from Pd dsp to C++), which 
incidentally used 'double' all the way through, I couldn't always use 
-ffast-math because it broke some patches very audibly.  I didn't have 
time to debug the issue, so I just removed the flag globally.


https://gitorious.org/maximus/tilde
(currently unmaintained / dormant, but might still work)


Claude
--
http://mathr.co.uk

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] svn copy error in pure-data/branches/by-author/gg/externals/ggee

[Claude Heiland-Allen]

you didn't fill your disk? (just checking the obvious first...)

maybe git-svn would be more reliable for getting such ane enormously 
huge repository as the whole of pure-data with all the vendor sources 
etc than the svn tool itself?


On 19/05/12 19:41, Nicolas Montgermont wrote:

Hello all,

I want to do a copy of the complete svn (not only trunk) with:

svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data pure-data

but I have an error at some point:

svn: In directory 'pure-data/branches/by-author/gg/externals/ggee'
svn: Can't open file
'pure-data/branches/by-author/gg/externals/ggee/.svn/tmp/text-base/VERSION.svn-base':
No such file or directory

and I have to kill svn. I have tested twice and exactly the same problem
happened.
svn update to get the other files after that doesn't work:

Machiavel:pure-data nix$ svn update
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
Machiavel:pure-data nix$ svn cleanup
svn: In directory 'branches/by-author/gg/externals/ggee'
svn: Error processing command 'modify-wcprop' in
'branches/by-author/gg/externals/ggee'
svn: 'branches/by-author/gg/externals/ggee/configure' is not under
version control
Machiavel:pure-data nix$ svn update
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)

Do you think of a workaround, or a way to correct the error?

Best
n




___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] nusmuk audio [vdc~] missing?

[Claude Heiland-Allen]

Hi,

I was hoping to try out [vdc~] but it seems to have vanished from 
current pure-data repository; I can grab an old revision, but I'm 
wondering if there was a particular reason it was removed?


svn r14362 D /trunk/externals/nusmuk/tab
svn r11606 A /trunk/externals/nusmuk/tab/vdc~.c

Thanks,


Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] integrating pdlua into Pd-extended

[Claude Heiland-Allen]

Hey,

On 18/03/11 17:38, Martin wrote:

The error actually seems to originate in pkg-config not finding lua5.1:


From my limited experience, Lua 5.1 libraries have different names all 
over the place, even in different GNU/Linux distros (lua51, lua5.1, 
lua5, lua, ...).  A bit of a nightmare.



"pkg-config lua --libs" should do it on Mac OS X/Fink.

.hc



Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] [maxlib/history] segfault

[Claude Heiland-Allen]

I tried here with trunk/externals/maxlib/history.c and attached 
history-test.pd patch, crashed:


Program received signal SIGSEGV, Segmentation fault.
0x76aad862 in history_float (x=0x831a80, f=)
at history.c:153
153 else x->x_average = x->x_input[x->x_inpointer];
(gdb) bt
#0  0x76aad862 in history_float (x=0x831a80, f=out>)

at history.c:153
#1  0x0046a69f in outlet_float ()
#2  0x0046ab69 in outlet_bang ()
#3  0x004b8e04 in ?? ()
#4  0x004761ed in m_mainloop ()
#5  0x0047aaf5 in sys_main ()
#6  0x76ccec4d in __libc_start_main (main=,
argc=, ubp_av=,
init=, fini=,
rtld_fini=, stack_end=0x7fffe238)
at libc-start.c:226
#7  0x00412f99 in _start ()
(gdb) print x->x_inpointer
$1 = 4728264212663500800


I'm guessing that the array overrun dumped some garbage in the 
x_inpointer field, which then exploded...



with the s/>/>=/ patch to line ~155 (see below) I didn't manage to crash 
it, but I also don't know if the output was correct...



Claude


On 24/10/10 01:05, Brian Neltner wrote:

Thanks Claude for your help.

I will personally just be switching to mavg instead of history for now
since I need to be confident it will work. Is there someone I can notify
who maintains the history external who would be interested in knowing
about the bug?

Brian

On Sun, 2010-10-24 at 00:38 +0100, Claude Heiland-Allen wrote:


Yes, in the absence of symbol information from 'history.pd_linux', I
would guess that it is these lines that are the problem:

http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0.42/externals/maxlib/history.c?revision=13589&view=markup#l155

155  if(++x->x_inpointer>  MAX_ARG)
156 {
157 x->x_inpointer = 0;
158 }

Possibly it should be>= instead of>, otherwise the code might end up
reading/writing past the end of the 0-indexed arrays of size MAX_ARG,
causing all kinds of memory corruption and random crashes, but I don't
suggest making the change without checking whether it is correct - the
code doesn't have any comments indicating the data invariants.


#N canvas 0 0 450 300 10;
#X obj 160 96 random 1;
#X floatatom 161 148 5 0 0 0 - - -;
#X obj 161 72 metro 1;
#X obj 161 44 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 160 124 history 0.2;
#X connect 0 0 4 0;
#X connect 2 0 0 0;
#X connect 3 0 2 0;
#X connect 4 0 1 0;
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Segfault without messages

[Claude Heiland-Allen]

On 24/10/10 00:22, Brian Neltner wrote:

Thanks for the info Claude,

Here is what gdb eventually spit out.

I read the documentation page, but I'm afraid I don't really see what I
should do from that. Is it trying to do a trace with #0 being the
immediate call that crashed, while #1 is what called #0 and #2 called #1
and so on? If so, it seems that maxlib history is what is causing the
problem.


Yes, in the absence of symbol information from 'history.pd_linux', I 
would guess that it is these lines that are the problem:


http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0.42/externals/maxlib/history.c?revision=13589&view=markup#l155

155  if(++x->x_inpointer > MAX_ARG)
156 {
157 x->x_inpointer = 0;
158 }

Possibly it should be >= instead of >, otherwise the code might end up 
reading/writing past the end of the 0-indexed arrays of size MAX_ARG, 
causing all kinds of memory corruption and random crashes, but I don't 
suggest making the change without checking whether it is correct - the 
code doesn't have any comments indicating the data invariants.



Sorry, I wish I knew more about programming...
Brian

On Sat, 2010-10-23 at 21:13 +0100, Claude Heiland-Allen wrote:

On 23/10/10 20:36, Brian Neltner wrote:

I have attached the offending script.


Seems quite simple, but I don't have pd-extended and miss the required
libraries to test.


pd gui; pd process exited
Segmentation Fault

Not very useful...


You could try 'gdb' or 'valgrind' to get more useful output.

$ gdb --args pd-extended blah blah
  >  run
Segmentation Fault
  >  bt
(tells you where the error is, hopefully)
  >  quit
$

See also:

http://puredata.info/docs/developer/DebuggingPdExternals


Claude





Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Segfault without messages

[Claude Heiland-Allen]

On 23/10/10 20:36, Brian Neltner wrote:

I have attached the offending script.


Seems quite simple, but I don't have pd-extended and miss the required 
libraries to test.



pd gui; pd process exited
Segmentation Fault

Not very useful...


You could try 'gdb' or 'valgrind' to get more useful output.

$ gdb --args pd-extended blah blah
> run
Segmentation Fault
> bt
(tells you where the error is, hopefully)
> quit
$

See also:

http://puredata.info/docs/developer/DebuggingPdExternals


Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] FYI: lots of pd packages for Debian

[Claude Heiland-Allen]

On 05/08/10 23:10, Hans-Christoph Steiner wrote:


FYI: I'm in the process of getting all my pd packages into Debian.  If
you are interested, you can follow the progress by checking out all of
the packages that start with "pd-" on this page:

http://www.debian.org/devel/wnpp/being_packaged


I see - so they're marked with "intent to package", some have been in 
that state for almost 2 months, how is it progressing?



Or try them in Ubuntu here:
https://launchpad.net/~eighthave/+archive/libdirs/+packages


Looking through the filters it seems that many have been deleted?
Any particular reason why?


Next, I'm uploading them to mentors.debian.net so people can try them
there.


Any way for us to try them out already?


.hc



Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] local libraries for local patches are impossible

[Claude Heiland-Allen]

On 27/07/10 22:41, Claude Heiland-Allen wrote:

On 22/07/10 20:07, Claude Heiland-Allen wrote:

On 22/07/10 05:09, Miller Puckette wrote:

Oh yes, and -lib itself needs somehow to be made to work locally to the
patch, but this is a huge issue I don't know how to deal with.


At first glance it should be possible to have canvas-local objectmakers
and have the "put on load list" put the absolute pathname of the dll
instead of just the name, but maybe there are some libraries that simply
cannot be dlopen()d more than once by the same executable due to
clashing exported symbols or so? I don't know enough about dlopen() to
say!


[snip]

$ cat foo/external.c
#include 
extern int external_data;
extern void external_setup(void) { post("foo/external: %d",
external_data++); }
int external_data = 42;

$ cat bar/external.c
#include 
extern int external_data;
extern void external_setup(void) { post("bar/external: %d",
external_data++); }
int external_data = 42;

$ pd -lib foo/external -lib bar/external -stderr -send "; pd quit"
foo/external: 42
bar/external: 43

$ pd -version
Pd version 0.42-5
compiled 20:01:18 Jan 5 2010


Now suppose that foo/external and bar/external have completely different
semantics for 'external_data'. The consequence would be epic breakage.


Example of such:

$ cat foo/external.c
#include 
extern short int external_data;
extern void external_setup(void) { post("foo/external: %d", 
external_data++); }

short int external_data = -42;

$ cat bar/external.c
#include 
extern const char external_data[];
extern void external_setup(void) { post("bar/external: %s", 
external_data); }

const char external_data[] = "bar";

$ pd -lib foo/external -lib bar/external -stderr -send "; pd quit"
foo/external: -42
bar/external: ×ÿ


RTLD_DEEPBIND[1] might be beneficial in some cases (ie, self-contained
libraries), but in others (ie, libraries that depend on other libraries,
like Gem/pix_opencv, Gem/gridflow, pdp/pidip, pdp/pdp_opencv, etc) it
would just postpone the epic breakage.

Conclusion: local libraries for local patches are impossible to
implement, at least if you expect sane/safe behaviour.

Given this conclusion, what is the best we can do?

[1] RTLD_DEEPBIND (since glibc 2.3.4) Place the lookup scope of the
symbols in this library ahead of the global scope. This means that a
self-contained library will use its own symbols in preference to global
symbols with the same name contained in libraries that have already been
loaded. This flag is not specified in POSIX.1-2001. -- man dlopen


Claude



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] local libraries for local patches are impossible [Was: Re: 0.43 omission: 'set-startup' and 'set-path']

[Claude Heiland-Allen]

On 22/07/10 20:07, Claude Heiland-Allen wrote:

On 22/07/10 05:09, Miller Puckette wrote:

Oh yes, and -lib itself needs somehow to be made to work locally to the
patch, but this is a huge issue I don't know how to deal with.


At first glance it should be possible to have canvas-local objectmakers
and have the "put on load list" put the absolute pathname of the dll
instead of just the name, but maybe there are some libraries that simply
cannot be dlopen()d more than once by the same executable due to
clashing exported symbols or so? I don't know enough about dlopen() to say!


[snip]

$ cat foo/external.c
#include 
extern int external_data;
extern void external_setup(void) { post("foo/external: %d", 
external_data++); }

int external_data = 42;

$ cat bar/external.c
#include 
extern int external_data;
extern void external_setup(void) { post("bar/external: %d", 
external_data++); }

int external_data = 42;

$ pd -lib foo/external -lib bar/external -stderr -send "; pd quit"
foo/external: 42
bar/external: 43

$ pd -version
Pd version 0.42-5
compiled 20:01:18 Jan  5 2010


Now suppose that foo/external and bar/external have completely different 
semantics for 'external_data'.  The consequence would be epic breakage. 
 RTLD_DEEPBIND[1] might be beneficial in some cases (ie, self-contained 
libraries), but in others (ie, libraries that depend on other libraries, 
like Gem/pix_opencv, Gem/gridflow, pdp/pidip, pdp/pdp_opencv, etc) it 
would just postpone the epic breakage.


Conclusion: local libraries for local patches are impossible to 
implement, at least if you expect sane/safe behaviour.


Given this conclusion, what is the best we can do?

[1] RTLD_DEEPBIND (since glibc 2.3.4)  Place the lookup scope of the 
symbols in this library ahead of the global scope.  This means that a 
self-contained library will use its own symbols in preference to global 
symbols with the same name contained in libraries that have already been 
loaded.  This flag is not specified in POSIX.1-2001. -- man dlopen



Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'

[Claude Heiland-Allen]

On 22/07/10 05:09, Miller Puckette wrote:

Oh yes, and -lib itself needs somehow to be made to work locally to the
patch, but this is a huge issue I don't know how to deal with.


At first glance it should be possible to have canvas-local objectmakers 
and have the "put on load list" put the absolute pathname of the dll 
instead of just the name, but maybe there are some libraries that simply 
cannot be dlopen()d more than once by the same executable due to 
clashing exported symbols or so?  I don't know enough about dlopen() to say!


I'm sorta working on this, but there are a whole nest of things all 
interconnected with each other:


1. paths and search order, currently it's roughly this afaict:
   a. search relative to patch
   b. search this patch's declared paths
   c. search relative to parents (a and b)
   d. search global paths

2. loader plugins
   currently plugins have to do their own searching
   which means it's not consistent with "local first" priorities
   (ie, foo.pd next to the patch is overriden by some random library)

3. libraries and import scopes/namespaces
   a. libraries can register multiple objects, which might nameclash
   b. import/declare should have a way to bring only certain names
  from a library into "unqualified" scope
  eg: [import Gem maxlib maxlib/scale]
  then [scale] would be from maxlib
  and [Gem/scale] and [maxlib/scale] would work too
   c. http://lists.puredata.info/pipermail/pd-dev/2010-07/015606.html
  section "Clearer Error Messages" explains more

4. abstractions
   kinda second class citizens because they can't register classes
   how about if an abstraction is found, it is registered magically?
   enabling caching, but what if the file is modified outside of pd?

5. efficiency
   checking 100 or more files for a failed object is excessive
   especially if this is repeated many times


Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] new loader replacement progress report

[Claude Heiland-Allen]

Hi everyone,

I've been working on some algorithms to eventually replace the way Pd 
finds and loads and creates objects.  Sorry for the length of this mail, 
but you can skip some sections if you don't care about implementation 
details and/or user interface details :)



Table of Contents
  * Specifications
  * Example Loaders
  * Clearer Error Messages
  * Test Inputs
  * Test Outputs


Specifications
--

As agreed by everyone so far, the new load order will be roughly:

for path in paths do -- the core does this bit
  for loader in loaders do
loader(path, libray, object)

instead of the old, problematic:

   for loader in loaders do
 for path in paths do -- the loader does this bit
   loader(path, library, object)

I restructured the loader plugin mechanism to be (pseudocode):

   typedef err libloadfun(symbol *dir, symbol *lib);
   typedef err objloadfun(symbol *dir, symbol *lib, symbol *obj);
   struct loader {
 symbol *name;
 float priority;
 libloadfun *libfun;
 objloadfun *objfun;
   }


Example Loaders
---

  -- binary loader is super simple
  Loader.new("bin", 70,
function(dir, lib)  return loadbin(dir, lib) end,
function(dir, lib, obj) return loadbin(dir, obj) end)

  -- directory loader is needed if there is no main library file
  -- the core code checks the results to see if it succeeded
  Loader.new("dir", 10,
function(dir, lib)
  if dir:sub(-1 - #lib, -1) == ("/" .. lib) then
return function() end
  else
return nil, "dir doesn't match lib"
  end
end,
nil -- directory loader can't load objects
  )

  -- the abstraction loader is quite complicated
  -- if the file exists it creates a callback that
  -- registers the class, with a constructor that
  -- runs the abstraction itself
  -- a Context here is essentially a 'canvas'
  Loader.new("txt", 30,
nil, -- abstractions cannot register new classes
function(dir, lib, obj)
  local src = dir .. "/" .. obj .. ".txt.lua"
  local f, err = fileexists(src)
  if f then
local ldir, lobj = dir, obj
return function()
  register(lobj, src, function(o, arguments)
Context.push(Context.new({ ldir }))
runtxt(ldir, lobj)
Context.pop()
  end, src)
end
  else
return nil, err
  end
end)

The current implementation is entirely in Lua, in an unpublished git 
repository.  I'll upload it somewhere if there is any interest.



Clearer Error Messages
--

The main upshot so far is clearer error messages instead of random 
possibly-working-but-perhaps-not implementation defined behaviour when 
more than one library defines the same name:



OBJECT[obj4]
obj4 ... couldn't create (ambiguous)
 (found in: 'lib4')
 (found in: 'lib3')
 (found in: 'lib1')
 (found in: 'lib5')
 (found in: 'lib2')
 disambiguate by [import lib2/obj4]
 replacing lib2 by the library you want to import from

OBJECT[obj2]
obj2 ... couldn't create (ambiguous qualified import)
 (imported: 'lib2/obj2')
 (imported: 'lib1/obj2')
 disambiguate by removing extra qualified imports


The error messages for objects that are not found are better too:


OBJECT[obj8]
obj8 ... couldn't create (no such object)
 (looked in: 'lib4')
 (looked in: 'vanilla')
 (looked in: 'lib3')
 (looked in: 'lib1')
 (looked in: 'lib5')
 (looked in: 'lib2')

OBJECT[lib1/obj8]
lib1/obj8 ... couldn't create (no such object in library)

OBJECT[lib6/obj1]
lib6/obj1 ... couldn't create (no such library)


Note for that last [libc6/obj1] example: if libc6 actually did exist in 
the path but was not imported, the error would currently be the same.  I 
want to make it so that [somelibrary/someobject] would work even when 
[somelibrary] is not imported (but such "implicit imports" would be 
deprecated, and warnings emitted).



Test Inputs
---

The test input directory structure (.bin.lua approximates .pd_linux etc, 
.txt.lua approximates .pd patches/abstractions):

8<
.:
global  prj1

./global:
lib1  lib2  lib3  lib3.bin.lua  lib4  lib5.bin.lua  vanilla

./global/lib1:
obj1.txt.lua  obj3.txt.lua  obj4.txt.lua  obj5.txt.lua  obj7.txt.lua
obj2.txt.lua  obj4.bin.lua  obj5.bin.lua  obj6.bin.lua

./global/lib2:
lib2.bin.lua  obj2.txt.lua  obj4.bin.lua  obj5.bin.lua  obj6.bin.lua
obj1.txt.lua  obj3.txt.lua  obj4.txt.lua  obj5.txt.lua  obj7.txt.lua

./global/lib3:
obj1.txt.lua  obj3.txt.lua  obj4.txt.lua  obj5.txt.lua  obj7.txt.lua
obj2.txt.lua  obj4.bin.lua 

[PD-dev] Pure-data libraries

[Claude Heiland-Allen]

Hey everyone,

I had a chat with Hans on #dataflow about libraries in Pd (as I've been 
trying to get canvas-local namespaces working properly).  Blog post here 
with more info and a link to the log, which I annotated with extra 
information after the fact (the right hand column):


http://claudiusmaximus.goto10.org/cm/2010-07-16_pure-data_libraries.html

I think this list would be a good place to discuss the open questions 
mentioned at the end of the blog post.


Thanks,


Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] uploading Pd git repository to sourceforge

[Claude Heiland-Allen]

On 15/07/10 17:08, IOhannes zmölnig wrote:

On 07/12/2010 05:33 AM, Miller Puckette wrote:

o Pd developers --



is it only me that cannot open files via "open"?


No, I got this error too.  Command line -open is what I used so far, but 
obviously unsatisfactory.




i get:

bad option "-cursor":



Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] broken links in pd-extended rc4 deb

[Claude Heiland-Allen]

Hi Hans and other pd-extenders,

Just noticed this:

$ wget 
http://autobuild.puredata.info/auto-build/latest/Pd-0.42.5-extended-rc4-ubuntu-lucid-amd64.deb
$ dpkg -c Pd-0.42.5-extended-rc4-ubuntu-lucid-amd64.deb | grep "\->" | 
grep Gem
lrwxrwxrwx root/root 0 2010-06-19 14:43 
./usr/lib/pd-extended/doc/examples/Gem -> 
/home/pd/auto-build/pd-extended/packages/linux_make/build//usr/lib/pd-extended/extra/Gem/examples
lrwxrwxrwx root/root 0 2010-06-19 14:43 
./usr/lib/pd-extended/doc/manuals/Gem -> 
/home/pd/auto-build/pd-extended/packages/linux_make/build//usr/lib/pd-extended/extra/Gem/manual



Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] modular pd-extended - when release?

[Claude Heiland-Allen]

Hi,

I was hoping that pd-extended would be split into a core package 
(containing the Extended pd) and modular external packages, but it 
seems[1] that this has been postponed yet again until the next+1 release.


In case this becomes "jam tomorrow" forever, what can I do to guarantee 
that the next+1 release does indeed contain modular packages, so that 
users have the choice between Miller pd and Extended pd without having 
to worry about whether externals are available?


[1] http://puredata.info/dev/NextRelease

Thanks,

Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] WebPd in Pure Data's SVN

[Claude Heiland-Allen]

http://gitorious.org allows AGPL and runs on free/open source software; 
last time I checked github is proprietary.


Claude



On 30/05/10 18:40, Vilson Vieira wrote:

What about github?

2010/5/30 Hans-Christoph Steiner mailto:h...@at.or.at>>


How about just starting a new SourceForge project for it?  Then you
can use svn, git, or whatever.  I think the pure-data SVN is a
pretty big mess because there is so much stuff in it.  Since I'm
admin on a bunch of SF projects, I can easily create one and hand
over the admin status to you.  Then you can control who has commit
access directly.

.hc


On May 30, 2010, at 8:35 AM, chrism wrote:

Hello all,

It seems like Google Code might not allow for AGPL licensed
projects. How
do people feel about me checking the WebPd source into the Pure Data
Sourceforge SVN somewhere? If that's ok, where would be a good
subdirectory?

Chris.

---
http://mccormick.cx

___
Pd-dev mailing list
Pd-dev@iem.at 
http://lists.puredata.info/listinfo/pd-dev







You can't steal a gift. Bird gave the world his music, and if you
can hear it, you can have it. - Dizzy Gillespie





___
Pd-dev mailing list
Pd-dev@iem.at 
http://lists.puredata.info/listinfo/pd-dev




--
Vilson Vieira

vil...@void.cc

((( http://automata.cc )))

((( http://musa.cc )))



___
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] changes in atom_getsymbol between pd 0.40-3 and 0.42.4?

[Claude Heiland-Allen]

Hi,

B. Bogart wrote:
The problem is passing the A_GIMME arguments from a wrapper function to 
a function that runs in a separate thread.


[snip]

This is the thread safety problem right here:


threadArgs->argv = argv;


You need to *copy* *all* the data needed by the child thread that might 
be modified in the main thread later.


[snip]

In PD <.0.40.3 the proper argument is printed from both the thread and 
in the spawning function.


You've just been lucky!


How does the symbol "input.jpg" end up turning into "float" in 0.42.4?


It could turn into anything - when the inlet method exits pd can do what 
it likes with the argv memory...



Any ideas for solutions?


Copy the argv array into new memory.



Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] adding standard install paths to the 'puredata' package

[Claude Heiland-Allen]

Some quick comments..

Hans-Christoph Steiner wrote:
By the way, is anyone from pure:dyne listening?  It would be great to 
have some input from you.


1. The paths stuff: the status quo is fine, I don't understand what you 
are trying to fix at all, apart from disruptive "change for the sake of 
change" to make a name more perceptually uniform - wtf does that solve?


2. it was taking too long for us to get packages into Debian

3. Puredyne (Ubuntu Karmic based distro) packages are here:
https://launchpad.net/~puredyne-team/+archive/ppa

4. The Puredyne pd-foo external packages "Depends: puredata" (afaik).

5. Maybe it would be better for puredata and pd-extended to both 
"Provide: pd", but then pd-extended will have a long "Conflicts: .." 
list, which is a pain for things like pd-gridflow "Depends: pd-gem, 
puredata" which means Puredyne pd-gridflow won't work with Pd-extended 
unless Pd-extended "Provides: pd-gem", then things will crash if the 
respective Pd ABIs are different, etc...


5.b. There must be a good elegant technical solution out there 
somewhere, but so far the "accidental workaround" of Puredyne's pd and 
externals packages basically conflicting with Pd-extended completely, 
hasn't caused too many problems in the wild: either have Puredyne 
puredata and modular externals, xor have Pd-extended monolith - choose 
your poison..



Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] namespaces for send/receive

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
I am in the process of working on my 'framesync' library, and I just had 
a thought that I am not sure has come up before.  Lots of times, we want
to use send/receives in reusable code, but with a global namespace, 
there is the potential for nameclashes.  So I propose that for 
libraries, we make it a 'best practice' to use the same namespace prefix 
as you would for loading an object.


For example, this 'framesync' library, I need to send the FPS (Frames 
Per Second) to all the objects, so it needs to be a global send.  So 
just like I could do [framesync/fstabplay~]


Why not call it [framesync/tabplay~]?  Is [import] not yet good enough?
Missing a feature like [import framesync as fs] to use [fs/tabplay~]?

the internal send/receive 
would be [send framesync/fps] and [receive framesync/fps].


.hc


Personally I'm not a fan of globals(*) - better for the user to tell the 
objects explicitly what name they should use to share information, thus 
letting more than one instance of the library functionality be used in 
the same instance of Pd.


So, my suggestion would be to use the first argument (or other easy to 
remember convention) to be the namespace to use for communication: if 
the user really wants a global they can use [framesync/fstabplay~ fs] 
and if they don't they can use [framesync/fstabplay~ $0].


The three extra characters " $0" are hardly a huge burden, but the 
benefits can be large imho.


But yes, if globals *must* be used, then using a global name closely 
related to the name of the library seems sensible.


(*) Pd has no non-globals, just obfuscated names..


Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] CUDA discussion

[Claude Heiland-Allen]

Hey,

Some brief initial thoughts:

http://en.wikipedia.org/wiki/CUDA
pro: better than OpenGL GPGPU hackery
pro: API/ABI-stable for foreseeable future
con: only one hardware vendor

-vs-

http://en.wikipedia.org/wiki/OpenCL
pro: royalty free standard with several vendors
pro: works on cpus as well as gpus
con: newer, may be API/ABI-unstable

-vs-

http://faust.grame.fr/catalog.php
pro: dataflow language optimized for DSP
pro: has backend for Pd already
con: works by translation via C++


Any project worth doing is worth doing right.  So, I want to figure
out if:  a) it's worth doing 


Sufficiently-parallel DSP on GPU is probably worth doing, but only 
benchmarks will tell.  Parallel DSP could either be multichannel or 
blocky (no data dependencies between samples in the same block) or a 
mixture of both at different parts of the graph.



b) how to do it right.


I did have an idea that went something like this:

1. write ugens in Faust, compile them into dsp objects, link, load
2. write a transaction-based patcher environment (or dataflow language) 
wherein transactions (such as multiple object creation deletion 
connection etc) can be committed atomically (with OSC-style bundle time 
tags etc)

3. translate the generated networks of dsp objects back to Faust code
4. compile that Faust code into a new dsp object, link, load, run
5. rinse, repeat

So, an OpenCL backend (instead of C++ backend) for Faust is the missing 
link...



Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] ATI + GridFlow + Gem + C++ + Linux = BOOM

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:

Do you have any documentation on this as a suggested workaround?


http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception#Workaround_.231

"Explicitly linking against libstdc++ before linking against the opengl 
libraries resolves this issue!"


You can have an external (in fact, I use one[1]) that links libstdc++, 
and load it into Pd before anything else, which "works" - but it's much 
more fragile and hoop-jumping for users who just want something that 
works, how many times can you debug ~/.pdsettings or ~/.pdrc for users 
who don't care why C++ exceptions cause crashes when they use Gem or 
whatever...


[1] https://code.goto10.org/svn/maximus/pd-libstdcpp/


Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] bug???!?!?

[Claude Heiland-Allen]

Ed Kelly wrote:

[snip]
The only difference between them is an [envrms~] measuring object on the 
frequency signal to the filter - but it's not even in the chain of signals that 
affects anything.
[snip]


I didn't try the patch, but I looked at the source code (current svn, 
revision 11896) briefly, and noticed that envrms~.c doesn't use 
CLASS_MAINSIGNALIN(), so maybe the dsp stuff isn't initialized correctly.



Claude
--
http://claudiusmaximus.goto10.org


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pure Data/adding _path for gridflow

[Claude Heiland-Allen]

sisil mehta wrote:

hello,
i have just compiled gridflow from cvs and get a :

"/usr/lib/pd/extra/gridflow/gridflow.pd_linux:
/usr/lib/pd/extra/gridflow/gridflow.pd_linux: undefined symbol:
_ZN9CPPExtern8m_holderE

gridflow: can't load library"


did you compile gridflow with Gem support?
if so, you need to load  -lib Gem  before  -lib gridflow

$ nm -D /usr/lib/pd/extra/gridflow/gridflow.pd_linux \
| grep _ZN9CPPExtern8m_holderE
 U _ZN9CPPExtern8m_holderE

$ nm -D /usr/lib/pd/extra/Gem/Gem.pd_linux \
| grep _ZN9CPPExtern8m_holderE
00333ee8 B _ZN9CPPExtern8m_holderE


Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Pure Data/adding _path for gridflow

[Claude Heiland-Allen]

Hi,

Please remember to write to the list (cc'd again) too, in case others 
can help...


sisil mehta wrote:

Hi,
In the .pdrc filei added the following
-lib Gem
-lib gridflow
i Also dont know how to set the path for CPLUS_INCLUDE_PATH,LD_LIBRARY_PATH
and LIBRARY_PATH because i cant find any of the .so files that the
installation guide mentions. Basically what should be the path of the three
mentioned paths?


No idea, I never adjusted any of that stuff...

You need to have Gem.pd_linux (or similar) in your path: where did you 
install Gem?  Or, recompile gridflow without Gem support..





*on opening PD i got the error:*

reading startup file: /home/sisil/.pdrc
startup args from RC file:
-lib
Gem
-lib
gridflow
input channels = 2, output channels = 2
opened 0 MIDI input device(s) and 0 MIDI output device(s).
input channels = 2, output channels = 2
opened /dev/dsp for reading and writing

opened audio output on /dev/dsp\; got 2 channels
bytes per sample = 2
setting nfrags = 8, fragsize 1024

audiobuffer set to 50 msec
opened audio input device /dev/dsp\; got 2 channels
bytes per sample = 2
tried ./gridflow.l_i386 and failed
tried /usr/lib/pd/extra/gridflow/bundled/gridflow.l_i386 and failed
tried /usr/lib/pd/extra/gridflow.l_i386 and failed
tried ./gridflow.pd_linux and failed
tried /usr/lib/pd/extra/gridflow/bundled/gridflow.pd_linux and failed
tried /usr/lib/pd/extra/gridflow.pd_linux and failed
tried ./gridflow/gridflow.l_i386 and failed
tried /usr/lib/pd/extra/gridflow/bundled/gridflow/gridflow.l_i386 and failed
tried /usr/lib/pd/extra/gridflow/gridflow.l_i386 and failed
tried ./gridflow/gridflow.pd_linux and failed
tried /usr/lib/pd/extra/gridflow/bundled/gridflow/gridflow.pd_linux and
failed
tried /usr/lib/pd/extra/gridflow/gridflow.pd_linux and succeeded
/usr/lib/pd/extra/gridflow/gridflow.pd_linux:
/usr/lib/pd/extra/gridflow/gridflow.pd_linux: undefined symbol:
_ZN9GemPixObj10postrenderEP8GemState
gridflow: can't load library
tried ./Gem.l_i386 and failed
tried /usr/lib/pd/extra/gridflow/bundled/Gem.l_i386 and failed
tried /usr/lib/pd/extra/Gem.l_i386 and failed
tried ./Gem.pd_linux and failed
tried /usr/lib/pd/extra/gridflow/bundled/Gem.pd_linux and failed
tried /usr/lib/pd/extra/Gem.pd_linux and failed
tried ./Gem/Gem.l_i386 and failed
tried /usr/lib/pd/extra/gridflow/bundled/Gem/Gem.l_i386 and failed
tried /usr/lib/pd/extra/Gem/Gem.l_i386 and failed
tried ./Gem/Gem.pd_linux and failed
tried /usr/lib/pd/extra/gridflow/bundled/Gem/Gem.pd_linux and failed
tried /usr/lib/pd/extra/Gem/Gem.pd_linux and failed
Gem: can't load library


Thnks,
Sisil

On Sat, Aug 1, 2009 at 8:58 PM, Claude Heiland-Allen <
claudiusmaxi...@goto10.org> wrote:


sisil mehta wrote:


hello,
i have just compiled gridflow from cvs and get a :

"/usr/lib/pd/extra/gridflow/gridflow.pd_linux:
/usr/lib/pd/extra/gridflow/gridflow.pd_linux: undefined symbol:
_ZN9CPPExtern8m_holderE

gridflow: can't load library"


did you compile gridflow with Gem support?
if so, you need to load  -lib Gem  before  -lib gridflow

$ nm -D /usr/lib/pd/extra/gridflow/gridflow.pd_linux \
| grep _ZN9CPPExtern8m_holderE
U _ZN9CPPExtern8m_holderE

$ nm -D /usr/lib/pd/extra/Gem/Gem.pd_linux \
| grep _ZN9CPPExtern8m_holderE
00333ee8 B _ZN9CPPExtern8m_holderE


Claude
--
http://claudiusmaximus.goto10.org






___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] packaging pd and friends WAS: GIT repo

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
Since you are also thinking about packaging, it would be good to open up 
a discussion about how to handle some things.  If you plan on just 
packaging pd-vanilla, then its easy.  If you want to support multiple 
versions of Pd then it gets a bit more complicated.


Yes, because they are incompatible.

Basically, libraries/externals can't be installed into 'pd/extra' 
because then the packages would conflict.


Huh?  You can't have two packages installing the same file (but there 
are mechanisms to cope with this even then), but you can have different 
packages installing files into the same directory (/usr/bin/ for example).



 I proposed
/usr/lib/pd-externals/ as a place to install all packaged externals, so 
then you could have pd-vanilla, pd-extended, desiredata, etc. installed 
and they could all use the externals.  Claude of pure-dyne had an 
objection to this, but he didn't follow up on the details.


It's broken by design.

Where is the guarantee that pd, pd-extended, desiredata, etc all have 
exactly equal binary API for externals?  Some externals (that use GUI 
features, for example) won't work with desiredata while they work fine 
with pd.  Also, some abstractions (that use [initbang], for example) 
won't work with pd while they work fine with pd-extended.


I suggest something like: /usr/lib/pd for pd, /usr/lib/pd-extended for 
pd-extended, /usr/lib/desiredata for desiredata.  Otherwise you'll end 
up with a lot of broken-ness.



Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] proper debs (pure:dyne+pd-extended = good)

[Claude Heiland-Allen]

Hi,

Hans-Christoph Steiner wrote:


On Apr 21, 2009, at 3:09 PM, Claude Heiland-Allen wrote:


Hi Hans, all,

Hans-Christoph Steiner wrote:


[snip]

The key here is to make sure that the library packages can work with 
separate versions of pd.  Something like 'puredata' and 'pd-extended' 
which both provide 'pd' but can coexist.


Sure, that's possible with Debian packaging.

That means the libraries 
should probably be installed into a standardized shared location, so 
maybe instead of /usr/lib/pd, use /usr/lib/pd-externals, which would 
match ~/pd-externals/ and /usr/local/lib/pd-externals for user-installed 
stuff.


WTF??  This is exactly the kind of pointless disruptive change that I
was arguing strongly against here:


our job as packagers (in the .deb sense) isn't to save
the pd universe with some grand architecture, but simply to make
packages available for users :)


[snip]

Also pd-extended's policy of splitting every library into tiny pieces 
solves one problem but causes others, so I think it was slightly 
premature to do the splitting until the other issues are fixed. 


[snip]

When you guys encounter problems with it, I would greatly appreciate 
feedback so that those problems can be addressed. 


[>~] etc


[snip]

With abstractions the situation is worse.  If you make your abstraction 
called [threshold] and include it in the same folder as your project.  
Then you use a patch that uses smlib's [threshold] and close it.  Reopen 
your patch and [threshold] will be the smlib one, _not_ your 
threshold.pd.  Or say Miller adds [threshold] to Pd-vanilla, same story, 
except there is no way to ever load your threshold.pd, unless you stick 
into a folder and call it [myfolder/threshold].


Sure, but that's nothing to do with Debian packaging.


"Use it like it is because its like that" seems like surrender to me.


We're talking about packaging for Debian, not saving the world in one
jump.  When the issues are improved (by the upstream authors), they make
a new upstream release, then the packager can update the Debian package.

When you link libraries 
into one file, then you cannot address any of these name conflicts. 


True, but [>~]

A big part of these problems with Pd-extended comes from having so many 
libraries loaded by default.  I think that none of the libraries should 
be loaded by default, I am guessing that's how pure:dyne does it.


The live distribution has a ~/.pdrc that loads most things.

Yes, this is a definitely something to think about.  These days, I am 
thinking more and more that we should make it easy for people to package 
and release libraries themselves, and make it really easy to install 
libraries.  That's the first step. 


Yes.  We (as packagers) can only package what is there.

Once we have a whole bunch of Pd 
externals in SVN that are set up with clean .deb building code, there 
will be lots of examples for people to draw from when packaging their 
own libraries.


You can use "apt-get source" to get some examples from the pure:dyne
repositories already.

Personally I'm not in favour of keeping debian/ folders in the same 
svn as the upstream source code, as they have rather orthogonal purposes.


If the aim is to make official debian packages, I think it makes sense 
to maintain the debian/control, etc files in the main Pd repo: pure-data 
SVN.


Why?  The Pure-data repository is for Pure-data things, and Debian has
its own infrastructure for Debian things.


upstream authors (write externals)
 |
 | upstream source repository
 V
upstream maintainer (tidy up externals for release)
 |
 | upstream source release
 V
-- upstream responsibility ends here
debian maintainer (packages release for debian)
-- debian responsibility begins here
 |
 | debianized source release
 V
debian build system / repository (builds for debian users)
 |
 | debian packages
 V
user "aptitude install" (gets to enjoy the externals)


Thanks,


Claude
--
http://claudiusmaximus.goto10.org
http://puredyne.goto10.org
http://goto10.org


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] proper debs (pure:dyne+pd-extended = good)

[Claude Heiland-Allen]

Hi Hans, all,

Hans-Christoph Steiner wrote:
I don't know if any of the active pure:dyne packagers are on this list, 
but I thought I'd try.  From what I have seen, it looks like pure:dyne 
is doing a much better job of making .deb packages than Pd-extended.  I 
would be great to 'officially' merge efforts so that we don't duplicate 
work.


Sure, we strive for high quality packages.  Regarding duplication of 
work, the pure:dyne wiki [1] has some packaging tips, the main thing is 
to get a good source.deb that can then be built for any Debian-based 
distro.  We have a pbuilder machine ready to compile packages, if anyone 
wants to help broaden the range of pure data related packages in 
pure:dyne (and eventually Debian main) you are more than welcome to join 
in the effort.


[1] 
http://code.goto10.org/projects/puredyne/wiki/DevLounge#SoftwarePackaging


Regarding pd-extended, pure:dyne is based on pd-vanilla, which we've 
found to be quite stable, while pd-extended seems to have more 
experimental patches that don't always work out.


Also pd-extended's policy of splitting every library into tiny pieces 
solves one problem but causes others, so I think it was slightly 
premature to do the splitting until the other issues are fixed. 
pure:dyne policy as far as there is one is to build the way the 
author(s) intended, resulting in a mix of libraries and single-object 
externals - but our job as packagers (in the .deb sense) isn't to save 
the pd universe with some grand architecture, but simply to make 
packages available for users :)


Then we can make some really nice, proper packages and get them 
into Debian.


Makes sense, that's one of the key aims of pure:dyne too.

DebConf 2010 is in NYC, and I'll be helping to run it, so 
it would be great to have all this in Debian by then.  Plus, it seems 
that Guenter has less time for the Debian packages, so things like the 
pd-externals package has lapsed.


That sounds like a good target.  The pd-externals package is long 
obsolete (last updated 2004 iirc).


It seems to me that the next step would be to get the pure:dyne stuff 
into pure-data SVN, then make any tweaks to it to make it work with 
Pd-extended too.


We're more than happy to be good packagers and report bugs upstream, 
with any build patches required, but ideally there would be more 
upstream releases of known-quality code - currently it is still a bit 
hit-and-miss for some externals/libraries to know if there are 
unfinished pieces of code that will be fixed the next day or two, which 
acts as a disincentive for packagers to put the effort in to package 
from the svn.


Personally I'm not in favour of keeping debian/ folders in the same svn 
as the upstream source code, as they have rather orthogonal purposes.



Thanks, and apologies for the length,


Claude
--
http://claudiusmaximus.goto10.org
http://puredyne.goto10.org
http://goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] How to construct a dynamic length list in PD external?

[Claude Heiland-Allen]

B. Bogart wrote:

Hey all,

I searched the archives and looked at some of the code in SVN, but I'm
still unsure how to do this.

I have a nested for loop that grabs the config options from the PTP
camera. The length depends on the camera and its mode.

How can I append each name to a list suitable to be used by outlet_list?


choice 1 (if maximum length is known):

allocate t_atom out[MAX_LENGTH] on the stack (as a normal variable). 
set argc to the actual length.


choice 2 (if maximum length is not known):

loop through once to get the length
malloc() sufficient space
loop through again to copy the data
send to outlet
free() the space

choice 3 (an alternative):

send each config option to the outlet separately (may be more useful 
than having to parse a list later?)



Claude
--
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] cyclone and uppercase

[Claude Heiland-Allen]

João Pais wrote:
another detail: while creating objects, line~ is different from Line~. 
but while searching for help, it isn't. maybe than's a bug? try with 
append / Append.


I think this is down to your operating system / file system not 
distinguishing between line / Line / lInE / LINE / ...  so when Pd 
searches for a help file, the operating system returns the first match 
which might not be "sufficiently accurate".  It's likely in that 
OS/filesystem that you cannot have line~-help.pd and Line~-help.pd in 
the same directory, because they have "too-similar" names.



Frank Barknecht wrote:


Any comments or objections?


Objection, judge! :)

Some of the uppercase objects in Cyclone are there so the don't clash 
with

builtins. Line~ is different from line~.


and has been lengthily discussed on this list: aliasing will eventually
override already existing classes (including internals). so you get
cyclone's [Line~] when you really want [line~].


Yes, I second this - no more aliases, especially ones that don't add any 
value!



fgkasdr
IOhannes


Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] How to pass indeterminate args to a thread

[Claude Heiland-Allen]

B. Bogart wrote:
> I figured that doing this with a PD type was unlikely, so I started
> messing with creating a structure for my args and passing a pointer to
> that.
> 
> So I have defined my structure for a single float arg:
> 
> struct floatArgStruct {
>   gphoto2_struct *gphoto2;
>   t_symbol *s;
> };
> 
> 
> just under the typedef for the external structure. (Is the external
> struct a better place for its def?)
> 
> Then the function that is executed from the PD selector:
> 
> static void wrapGetConfig(gphoto2_struct *gphoto2, t_symbol *s) {
>   int ret;
>   pthread_t thread1;
> 
>   // instance of structure
>   struct floatArgStruct threadArgs;
> 
>   // packaging arguments into structure
>   threadArgs.gphoto2 = gphoto2;
>   threadArgs.s = s;
> 
>   post("I'm about to start the thread.");
> 
>   // Create thread
>   ret = pthread_create( &thread1, NULL, mythread, (void *)threadArgs);
> }
> 
> which populates the structure, and starts the thread. The struct stuff
> appears to work here)
> 
> Above this is the def of the function that is to execute in the thread:
> 
> void *mythread(struct floatArgStruct *threadArgs) {
>   int i;
>   post("thread start.");
> 
>   post("My symbol: %s", threadArgs.s->s_name);// line 92

threadArgs is a pointer, '.' is only for structs/unions

try '->' instead of '.' to both dereference pointer and access member

>   outlet_float(threadArgs.gphoto2->x_obj.ob_outlet, 0.1);
> 
>   post("thread end.");
> }
> 
> The errors I'm confused about are:
> 
> gphoto2.c:92: error: request for member 's' in something not a structure
> or union
> gphoto2.c:93: error: request for member 'gphoto2' in something not a
> structure or union
> 
> Which means that the structure is not being passed to the thread code
> correctly, as its not recognized as a structure.
> 
> Next gcc complains about the way I'm initiating the thread:
> 
> gphoto2.c:112: error: cannot convert to a pointer type
> gphoto2.c:112: warning: passing argument 3 of 'pthread_create' from
> incompatible pointer type
> 
> In the tutorial the function args were cast as (void *) which does not
> seem to be working in this case.
> 
> Does anyone have any code that does this kind of job I could look at?
> 
> Or is it obvious I'm doing something really wrong?
> 
> This is my first exploration into threads and custom structs (not
> counting the external struct) so I may have it totally wrong.
> 
> Thanks,
> B.
> 
> 
> 
> 
> B. Bogart wrote:
>> Hey all,
>>
>> I've got some simple threading code working, and it looks like that will
>> fix my HUP issues with PD and my gphoto external.
>>
>> Problem I'm having is that I need to pass thread arguments as a pointer
>> to a structure.
>>
>> Are there some PD types I can use to make this work? (A_GIMME?)
>>
>> Or do I need to make struct that holds the *argv argc stuff, pass that
>> structure to the thread, and have it unpack the content?
>>
>> Also my code function that executes the thread does not wait for the
>> threads to complete.
>>
>> What is the best way to make my object output a bang when the thread is
>> complete?
>>
>> Any advice appreciated.
>>
>> Thanks,
>> B.
>>
>>
> 
> ___
> 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] library proposal

[Claude Heiland-Allen]

IOhannes m zmoelnig wrote:
> Hans-Christoph Steiner wrote:
>>
>> The current setup means that you can override a pd-vanilla 
>> abstraction  using a binary class in ".", but you can't override a 
>> pd_vanilla  binary using an abstraction in "."  That seems to treat 
>> .pd  objectclasses as second class classes and I don't like that ;)
> 
> well, additional loaders are somewhere inbetween.
> e.g. .pdlua in path1 will override .pd in path0 but will be overridden 
> by .pd_linux in path2.
> which makes .pd a 3rd class citizen and .pdlua a 2nd class citizen.
> 
> personally i think this is something i can live with.
> what bothers me more is that .pd classes cannot "bypass" the 
> loader-mechanism (by registering the class).

Maybe compare with the abstraction cache patch I wrote a while ago, that 
has a similar observable result as a side-effect.

http://lists.puredata.info/pipermail/pd-dev/2008-10/012334.html


Claude
-- 
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd-devel code structure meeting on IRC

[Claude Heiland-Allen]

Steffen Juul wrote:
> On 14/02/2009, at 23.48, Claude Heiland-Allen wrote:
> 
>> Has the log been posted anywhere yet?
> 
> Please do - i'd like to see it. Maybe http://puredata.info/dev/pddevel 
> is a good place to stick it.

http://puredata.info/dev/pddevel/dataflow-2009-02-13.log/view


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd-devel code structure meeting on IRC

[Claude Heiland-Allen]

Has the log been posted anywhere yet?

I think I have it if no one else has a copy.

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] osc automatic routing

[Claude Heiland-Allen]

Forwind info wrote:
> Hi,
> 
> A late catch up on this (err 2 months)
> I have done what you suggested below.
> 
>>> "/foo/bar 1 2 3"  or other arbitrary osc messages
>>> |
>>> [t a a]
>>> |\
>>> |[list split 1] (or [list]--"$1" would also work here)
>>> | :
>>> [list split 1]
>>>  |  :
>>>  |  |
>>>  [send]
> 
> I made one adjustment:
> 
> Going from left to right the first output of [list split 1] which outputs
> the osc address symbol is sent to the right hand of the send object and the
> second output of list which outputs the actual value is sent to the first
> output.

[snip]

> Again there is probably an easy way to fix this but I'm stumped.

That's why I put [trigger] and *two* [list split]s.  Easier than trying 
to swap the order of the messages later (unless [swap] supports lists yet?)

But as was mentioned elsewhere in the thread, this doesn't work with OSC 
wildcards which you'll want to use sooner or later...


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] developer

[Claude Heiland-Allen]

Daniel Aschauer wrote:
> I wanted to add my external to the repository. How do I become a developer?

Send a bio (with your sourceforge username) and description of project 
to this list and wait for people to not object, or something.


BTW: this seems to be obsolete, if someone wants to update it :)

http://puredata.info/docs/developer/sf_project


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] osc automatic routing

[Claude Heiland-Allen]

Forwind info wrote:
> Hi all,
> 
> Does anybody know if there is a way to automatically send an OSC message to
> an internal PD messaging address which happens to be the same as the route
> of the OSC message.
> So for instance, an osc message arrives with route "/a/sample/route" and
> value 50, I would like to automatically send the value of the message to the
> internal message address of  "/a/sample/route".
> I would like to avoid having to explicitly patch this (using route and send
> and receive) as there quite a few.

something like this:

"/foo/bar 1 2 3"  or other arbitrary osc message
  |
[t a a]
  |\
  |[list split 1] (or [list]--"$1" would also work here)
  | :
[list split 1]
 |  :
 |  |
[send]

requires a recent Pd for the settable send, if i recall correctly

> I could be missing some basic pd knowledge ...
> 
> thx in advance.
> Conor

hope this helps,


Claude
-- 
http://claudiusmaximus.goto10.org


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] representing parent patch levels as args

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
> So I am just adding support to canvas_name and window_name for  
> getting the names from other canvases besides the current one, i.e.  
> parent, toplevel, etc. 

OK.

> I am using the now standard numeric notation  
> that is used in [getdir], iemguts, getdollarzero, etc.

Care to give a brief description of that for those that don't know?  I'd 
be interested in adding something similar to pdlua, so that .pd_lua(x) 
files can access the path(s) of their containing patch(es), would make 
sense to have the same numbers.

> What I am wondering is whether it is worth it to add symbol versions  
> of those names too, like "parent" and "toplevel". 

this sounds useful at first, but if it's only two cases then maybe it's 
not worth the hassle...

> Or perhaps it  
> would also be useful to be able to stick the name of a canvas there  
> too, like 'pd-mysubpatch' or 'pd-canvas_name-help.pd'.

Err, why would that be useful if the object is to get the name in the 
first place (and also, what happens if there are 42 copies of 
canvas_name-help.pd open...?)

> What are  
> people's thoughts on making that part of the standard technique of  
> looking up these kinds of things?

I think often numbers are nicer than names (eg, I'd hate to have to type 
"greatgreatgreatgrandparent" instead of 5 or whatever it would be).


Claude
-- 
http://claudiusmaximus.goto10.org


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] abstraction caching

[Claude Heiland-Allen]

Benchmarking an Abstraction Cache for Pd


I implemented a rudimentary abstraction caching mechanism for Miller
Puckette's pd-0.41-4, which stores the parsed text ("binbuf") associated
with the class name instead of looking for files to load every time it
is instantiated.


Benchmark Mechanism
---

Run 4 times, discarding first report:
$ time pd -open layer_2.pd -send "; pd quit" &>/dev/null

layer_2.pd contains 99 layer_1.pd contains 99 layer_0.pd,
total 9901 = 9801 layer 0 + 99 layer 1 + 1 layer 0


Results: Without Cache
--

real0m0.524s
user0m0.260s
sys 0m0.256s

real0m0.530s
user0m0.224s
sys 0m0.276s

real0m0.527s
user0m0.224s
sys 0m0.296s


Results: With Cache
---

real0m0.082s
user0m0.068s
sys 0m0.004s

real0m0.148s
user0m0.120s
sys 0m0.008s

real0m0.085s
user0m0.052s
sys 0m0.012s


Conclusion
--

Abstraction cache gives a speed boost of more than 500% when loading
patches containing a large number of abstractions.


Further Work


The main drawback (and the easiest issue to resolve) of the current
implementation is that once an abstraction is in the cache, it stays
there forever, no matter if the file is modified within or without Pd.
This could be fixed by flushing the cache immediately after the patch
is loaded (perhaps using Pd's scheduler).

Another drawback are that abstractions in different directories with
the same file name can clobber each other - the first one loaded is the
"one true abstraction" with that name, resolving this issue will be more
difficult.


--- pd-0.41-4.orig/src/m_class.c	2008-03-15 00:03:00.0 +
+++ pd-0.41-4/src/m_class.c	2008-10-01 11:15:12.0 +0100
@@ -514,14 +514,73 @@
 t_symbol* pathsearch(t_symbol *s,char* ext);
 int pd_setloadingabstraction(t_symbol *sym);
 
+
+/* abstraction cache */
+struct _abscache
+{
+struct _abscache *next;
+t_symbol *name;
+t_symbol *file;
+t_symbol *dir;
+t_binbuf *binbuf;
+};
+typedef struct _abscache t_abscache;
+
+t_abscache *abscache_list;
+
+t_abscache *abscache_find(t_symbol *s)
+{
+t_abscache *a = abscache_list;
+while (a)
+{
+if (a->name == s) return a;
+a = a->next;
+}
+return 0;
+}
+
+void abscache_add(t_symbol *name, t_symbol *file, t_symbol *dir, t_binbuf *binbuf)
+{
+t_abscache *a = getbytes(sizeof(t_abscache));
+a->next = abscache_list;
+a->name = name;
+a->file = file;
+a->dir = dir;
+a->binbuf = binbuf;
+abscache_list = a;
+}
+
 /* this routine is called when a new "object" is requested whose class Pd
 doesn't know.  Pd tries to load it as an extern, then as an abstraction. */
 void new_anything(void *dummy, t_symbol *s, int argc, t_atom *argv)
 {
+t_abscache *abscache;
 t_pd *current;
 int fd;
 char dirbuf[MAXPDSTRING], *nameptr;
 if (tryingalready) return;
+if ((abscache = abscache_find(s))) {
+if (sys_verbose)
+{
+post("tried cache for %s and succeeded!", s->s_name);
+}
+newest = 0;
+class_loadsym = 0;
+current = s__X.s_thing;
+if (!pd_setloadingabstraction(s))
+{
+int dspstate = canvas_suspend_dsp();
+canvas_setargs(argc, argv);
+glob_setfilename(0, abscache->name, abscache->dir);
+binbuf_eval(abscache->binbuf, 0, 0, 0);
+glob_setfilename(0, &s_, &s_);
+if (s__X.s_thing != current)
+canvas_popabstraction((t_canvas *)(s__X.s_thing));
+canvas_setargs(0, 0);
+canvas_resume_dsp(dspstate);
+}
+else error("%s: can't load cached abstraction within itself\n", s->s_name);
+} else {
 newest = 0;
 class_loadsym = s;
 if (sys_load_lib(canvas_getcurrent(), s->s_name))
@@ -542,7 +601,25 @@
 if (!pd_setloadingabstraction(s))
 {
 canvas_setargs(argc, argv);
-binbuf_evalfile(gensym(nameptr), gensym(dirbuf));
+{
+t_symbol *name = gensym(nameptr);
+t_symbol *dir = gensym(dirbuf);
+t_binbuf *b = binbuf_new();
+int dspstate = canvas_suspend_dsp();
+glob_setfilename(0, name, dir);
+if (binbuf_read(b, name->s_name, dir->s_name, 0))
+{
+perror(name->s_name);
+}
+else
+{
+
+binbuf_eval(b, 0, 0, 0);
+}
+glob_setfilename(0, &s_, &s_);
+abscache_add(s, name, dir, b);
+canvas_resume_dsp(dspstate);
+}
 if (s__X.s_thing != current)
 canvas_popabstraction((t_canvas *)(s__X.s_thing));
 canvas_setargs(0, 0);
@@ -551,6 +628,7 @@
 }
 else newes

Re: [PD-dev] downloading with svn

[Claude Heiland-Allen]

patco wrote:
> Hi,
> 
>  I tried to use svn to downlad pd sources and a few libraries for
> developing an external, but whatever the address I put, it always
> downloads all the stuff from everyone, every versions,

works fine here.

an example of selective download:

[EMAIL PROTECTED]:~/tmp/svn$ svn co 
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/extra/pique
Apique/pique.c
Apique/pique-help.pd
Apique/makefile
Checked out revision 10284.
[EMAIL PROTECTED]:~/tmp/svn$



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] cross-platform support for externals ("extern" not enough?) (Was: Re: Problem building pdlua on MinGW (solved for now))

[Claude Heiland-Allen]

Claude Heiland-Allen wrote:
>>After:
>> EXTERN void lua_setup(void) {
> 
> Applied this change.

Actually, I had to define a new macro depending on MSW, because 
otherwise the EXTERN stuff operates in the wrong direction (oops).

Should work now, thanks to IOhannes for pointing out the issue (albeit 
obliquely).

So the question is, does every external have to jump through this kind 
of hoop if it wants to compile on Windows?

/* support windows */
#ifdef MSW
#define EXPORT __declspec(dllexport) extern
#else
#define EXPORT   extern
#endif


Claude
-- 
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Problem building pdlua on MinGW (solved for now)

[Claude Heiland-Allen]

Hi,

Thanks for the help, hopefully pdlua svn should now build (and run!) on 
mingw with the only changes required being in the "user configuration" 
section at the top of the 'Makefile.static'.

PSPunch wrote:
> 
> 1. Copy the following files to the same directory as Makefile.static
>   1) lua-5.1.3.tar.gz (My MinGW did not have 'wget')
>   2) m_pd.h
>   3) pd.dll

Added to the documentation.

> 
> 2. Modify lua.c
> 
> - line:1271
> 
>Before:
> extern void lua_setup(void) {
> 
>After:
> EXTERN void lua_setup(void) {

Applied this change.

> -
> 3. Modify Makefile.static
> 
> - line:5  Comment out (#PLATFORM = linux)
> - line:7  Uncomment (PLATFORM = mingw)
> - line:30
>Before:
> CFLAGS_mingw = -export_dynamic -shared
> 
>After:
> CFLAGS_mingw = -shared -D MSW -D PD_INTERNAL -I./

Modified this slightly (no PD_INTERNAL, no -I which should go in the 
PDINCLUDE in the user configuration section).

> -
> (After `make -f Makefile.static')
> 4. Copy the following files to 'extra'
>1) lua.dll
>2) pd.lua

Added as a suggestion in the documentation.

Thanks again,


Claude
-- 
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Problem building pdlua on MinGW

[Claude Heiland-Allen]

PSPunch wrote:
> Hi Claude,
> 
> 
> I have lua.dll and pd.lua both in my "extra" directory now.
> 
> A little excerpt of the output of -stderr -verbose..
> This is when trying to create a [lua] object.
> 
> 
> tried C:\Program Files\pd\extra\flatspace\lua.dll and failed
> tried C:\Program Files\pd\extra\lua.dll and succeeded
> C:\Program Files\pd\extra\lua.dll: couldn't load

hmm, very uninformative error message.  any windows experts know what 
this error means?

> Did you imply that if pd.lua not being recognized is the case, there 
> should be an output mentioning it?

yes.  that error message looks like:


error: lua: error loading `pd.lua': canvas_open() failed
error: lua: loader will not be registered!


to fix it, add the directory containing pd.lua into the -path

(TODO: look relative to the pdlua binary, so that you don't need to 
fiddle with path settings)

> The file seems to be found.

Yes.

> It seems like it is not able to load.

Indeed, but why?

>>> As a base line, I am using the following combination of files.
>>>
>>> - MinGW for building
>>> - Using pd.dll from pd-extended 0.40.3-20080721 (Win binary package)
>>> - Using m_pd.h from pd-0.40.3 source

what is pd-extended compiled with?  internet search suggests that there 
might be incompatibilities between Microsoft and GNU compilers, but now 
I'm thinking the below is more likely the cause:

>>> Info: resolving _garray_class by linking to __imp__garray_class
>>> (auto-import)
>>> Info: resolving _s_ by linking to __imp__s_ (auto-import)

Guessing now: pd.dll doesn't export "s_" or "garray_class", which means 
externals can't use them like on the unixoid OSs?  That would be 
"somewhat disadvantageous" :(

Any windows people have any ideas?


Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Problem building pdlua on MinGW

[Claude Heiland-Allen]

PSPunch wrote:
> This may or may not be a question specific to pdlua.

I have no mingw machines, but I can try to answer.

> As a base line, I am using the following combination of files.
> 
> - MinGW for building
> - Using pd.dll from pd-extended 0.40.3-20080721 (Win binary package)
> - Using m_pd.h from pd-0.40.3 source
> 
> 
> Although I am not fully aware of the compatibilities between binaries
> built on different compilers, if the above combination is an obvious no
> no, that may be the problem. (The last two lines of the output seem a
> bit suspicious)

No clue on this.

> Attempting to build pdlua, the build completes but leaving me with a dll
> which fails to load on pd-extended 0.40.3-20080721 (Windows installer).

More info on this would be useful - ie, what error messages are 
produced, what is printed if you start pd from the console with the 
-stderr -verbose flags (in case some system messages don't go to Pd's 
window)?

The main pdlua-related problem I can think of is not having pd.lua in 
Pd's -path, but pdlua should print out messages to that effect if it 
can't find it.

[snip]

> Info: resolving _garray_class by linking to __imp__garray_class
> (auto-import)
> Info: resolving _s_ by linking to __imp__s_ (auto-import)

No idea about these either.


Claude
-- 
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] pd_error in constructors (Was: Re: dump OSC bugs?)

[Claude Heiland-Allen]

Claude Heiland-Allen wrote:
can you make it use pd_error (or whatever it's called) so you can find 
the object more easily?  would that even work in the constructor?


I was curious, so I tested it..

Calling pd_error on the newly constructed object in the newmethod does 
work (in that find last error finds it), which is nice.



Claude
#include 

static t_class *errorconstructor_class;

struct errorconstructor {
  t_object obj;
};

static struct errorconstructor *errorconstructor_new(void) {
  struct errorconstructor *e = (struct errorconstructor *) pd_new(errorconstructor_class);
  pd_error(e, "errorconstructor!");
  return e;
}

extern void errorconstructor_setup() {
  errorconstructor_class = class_new(
gensym("errorconstructor"),
(t_newmethod) errorconstructor_new,
0,
sizeof(struct errorconstructor),
CLASS_NOINLET,
0
  );
}
#N canvas 0 0 450 300 10;
#X obj 87 131 errorconstructor;
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] dump OSC bugs?

[Claude Heiland-Allen]

IOhannes m zmoelnig wrote:
> whenever i find the time, i want to add a note into the constructor of 
> the OSCx objects, so you get a warning each and everytime you create one 
> of these objects.
> if someone finds the time before me, i would be glad...

can you make it use pd_error (or whatever it's called) so you can find 
the object more easily?  would that even work in the constructor?


Claude

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] recording the overall state of a patch

[Claude Heiland-Allen]

forwind wrote:
> Hello Everybody,
> 
> Apologies if this is not the correct place to post this but could
> someone point me towards ways to record/save the overall state of a
> patch.

http://lists.puredata.info/search/PD-list?query=state+saving

 > What solutions do people generally use ?

sssad appears to be popular
memento/rradical was also popular, not sure what the current status is
netpd has a distributed state saving/propagation system

 > I was considering
> writing something in python which would save/recall a patch's state via
> OSC.

seems over complicated and rather tricky to synchronise (lots of 
possible race conditions i can imagine..)

 > Each patch would have to define an 'API' to facilitate this but
> would work well considering hooking up python and pd via OSC is pretty
> straight forward using something like pickle to serialize/deserialize a
> patches state. 
> 
> Best regards
> Conor


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] sms pd external - design choices

[Claude Heiland-Allen]

[EMAIL PROTECTED] wrote:
> Quoting Mathieu Bouchard <[EMAIL PROTECTED]>:
> 
>> On Fri, 18 Jul 2008, Hans-Christoph Steiner wrote:
>>
>>> It would be great to have people start using this string/blob   
>>> functionality, but it needs to be changed so that it'll work   
>>> without patching Pd itself.  IOhannes outlined this idea, and we   
>>> talked about it briefly in the past.
>> How do you get [print] to print a peachy string?
> 
> in the way we (including miller) kind of agreed at LAC2008 the answer  
> is simple: you don't.
> 
> my initial idea of having a "type registry" (which was turned down as  
> it seemed to be too complicated for the "minor" (not so many devs  
> would probably use it anyway) feature of adding more types) would have  
> added a callback for the use in atom_getstring()

I'd be more worried about what to do when arbitrary atom-type-agnostic 
objects keep copies of my atoms around long after my world has 
deallocated the memory pointed to, and what to do when those expired 
atoms come back into my world...

Claude
-- 
http://claudiusmaximus.goto10.org


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] sms pd external - design choices

[Claude Heiland-Allen]

Rich E wrote:
> I do not see how I could have more than one buffer at the same time if it
> were declared statically.  The data has to be 'findable', so I need some way
> to name it.

Well, you could do what Pd does, and have a static datastructure 
pointer, with a list/tree/whatever that you can look through to find 
values associated with keys.  I think this is what the findbyclass stuff 
does internally, but you'd have to check the source to confirm and see 
how to use it (it's used in [value] and [table], and others too).


Claude
-- 
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] sms pd external - design choices

[Claude Heiland-Allen]

m_pd.h declares:

EXTERN t_pd *pd_findbyclass(t_symbol *s, t_class *c);

maybe that's worth investigating?

Rich E wrote:
> Hi all,
> 
> As I may have mentioned in a few other places, I have been working
> with a c library for analysis/synthesis known as SMS.  The library,
> although in flux still, is now capable for performing synthesis in
> real-time; I wrote a prototype external that does this by reading a
> streaming file from disk.
> 
> Now, I want to turn write a set of externals using a buffered
> analysis.  Originally, I thought that all operations to the buffer
> would happen using one external, but this now seems like it will get
> too messy once anything more than basic operations are attempted
> (something like cross-synthesis would take enough code to constitude
> its own external).  So, I have decided that, like the process of SMS,
> the different modes of operation should be seperated into analysis,
> synthesis, and editing.  However, they would all still need access to
> the same buffer (which could also be its own external, or possibly be
> inside the analysis external).
> 
> So now I am looking for a way to make it where various externals have
> access to the same buffer - a data structure containing a header and
> sequential frames of analysis.
> 
> I originally thought that outputting a pointer would be the easiest,
> but then realized that pd can output 'gpointers', which are not the
> same as a void pointer.  So it does not look possible to pass a
> regular c pointer around in pd land.
> 
> I see that [pool] has the ability to share a data space among
> different buffers by taking a name as its first argument.  I am
> digging through its code right now, but am not familiar with the flext
> API. I don't yet see how it manages to allow different [pool]'s to
> share the same data.
> 
> Any suggestions from this list is appreciated..
> 
> cheers,
> rich
> 
> On Jan 27, 2008 6:01 PM,  <[EMAIL PROTECTED]> wrote:
>> Quoting Rich E <[EMAIL PROTECTED]>:
>>
>>> Hi Gunter Geiger, pd devs,
>>>
>>> I have recently begun to write an external for SMS synthesis, by basically
>>> porting the command line tool Xavier Serra wrote within the original SMS
>>> code (found at 
>>> http://www.iua.upf.es/~sms/software/Old-SMS-for-NextStep.zip).
>>> I was talking to Xavier about this and he mentioned that you almost got an
>>> external working with sms.. Before I did too much work, I figured I would
>>> ask to see what types of problems you ran into, or if you have any
>>> suggestions.
>> Hi,
>>
>> I have part of the SMS process implemented, but not as a single external
>> but as a collection of externals for generation of windows, peak
>> detection, interpolation, FFT resynthesis. These are glued together
>> with standard
>> pd objects.
>> I sort of got stuck trying to figure out how to use the extracted data in
>> a meaningful way inside pd.
>>
>> So, after all,it might be a better approach to do it as a single external and
>> program your transformations in C/C++. So maybe the best bet would be
>> to have a
>> base SMS analysis/synthesis engine and do an external for each effect that
>> you want to implement with it.
>>
>> Gunter
>>
>>
>>
>>
>>
>>> I'm also sending this to the pd-dev list to see if others have suggestions.
>>> I figure that I will start by doing just a port of the command line tool,
>>> and then later add in features for seeking through frames at any speed and
>>> direction, visually manipulating the data, and other fun things.  But I
>>> would like to know what others think.
>>>
>>> regards,
>>> rich
>>>
>>
>>
>> 
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
> 
> ___
> 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] abstractions

[Claude Heiland-Allen]

[EMAIL PROTECTED] wrote:
> btw such "range" is very feasible with only pd language

  dollarg
... couldn't create

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] 'cnv' colors

[Claude Heiland-Allen]

Mike McGonagle wrote:
> Hello all,
> 
> I have a program that I have written that creates lots of small 'cnv'
> objects, where I am changing the colors of the backgrounds and the text in
> the object. I was noticing that when I create these cnv objects, I have to
> use a different 'color number' to get the same color when I change it with
> the cnv 'color' message (which changes both the background and text colors
> in the same message).
> 
> Is this documented anywhere as to the relation between these two different
> color definitions?

Not as far as I'm aware, but here's my implementations that work for me:

/* colour */
float r, g, b; /* 0<={r,g,b}<=1 */

/* RGB -> Pd file */
int c = int) (r * 63.0)) << 12)
   | (((int) (g * 63.0)) << 6)
   | ((int) (b * 63.0))) ^ (-1);

/* RGB -> Pd message */
int c = int) (r * 255.0)) << 16)
   | (((int) (g * 255.0)) << 8)
   | ((int) (b * 255.0))) ^ (-1);


Claude
-- 
http://claudiusmaximus.goto10.org


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] please remove old pdlua from SVN

[Claude Heiland-Allen]

Hello,

Can one of you fine developers with sf.net access please delete:

pure-data/trunk/externals/loaders/pdlua

It's at pdlua-0.3, 2 versions behind the current release...

Either that or make it refer dynamically to the current development 
repository:

https://devel.goto10.org/svn/maximus/pdlua

Thanks,


Claude
-- 
http://claudiusmaximus.goto10.org

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] bang [block~] to query current blocksize

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
> On May 23, 2008, at 9:00 AM, IOhannes m zmoelnig wrote:
>> Hans-Christoph Steiner wrote:
>>> I just had a thought, what about adding an outlet to [block~]  
>>> that  will output the block size as a float when [block~] is  
>>> banged?  I  can't think of any other way to query what the current  
>>> block size is,  and it would be useful sometimes.
>> banging [switch~] allows you to do dsp processing on demand.
>> since [block~] and [switch~] are so closely related (on the Pd side  
>> they are very similar (with [switch~] being a better [block~]); on  
>> the C side they are the basically same) i would suggest to do any  
>> additional overloading.
>>
>> i agree however, that it would be nice to get the current  
>> blocksize, overlap and oversample from within Pd.
> 
> It seems that adding an outlet to block~/switch~ seems to be the most  
> obvious interface for getting the data.  Perhaps just a message then?

I'd personally prefer new objects:

[blocksize~]
[overlap~]
[oversampling~]

to match the existing:

[samplerate~]


Rationale:

You might want to get the blocksize etc in more than one place.
It might be inconvenient to patch cables from the [block~].
Plus the reasons that IOhannes mentioned.


Thanks,


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] changing glob_setfilename() to handle spaces in the dirname

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
> How does that sound?

Hacky.  What about multiple consecutive spaces? etc

> Any better approach?

Some sort of escaping mechanism to allow spaces (and other characters)
to be safely transmitted in symbols in both directions.

> .hc


Claude
-- 
http://claudiusmaximus.goto10.org



___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd external memory weirdness

[Claude Heiland-Allen]

Hi Tim, list,

First, I never wrote anything with pthreads, so this may be way off the 
mark, but this looks suspicious:

tim redfern wrote:
> void thread_bang(t_thread *x)
> {
> char* temp=(char*)malloc(100);
> free(temp);
> 
> pthread_t stest;
> pthread_create (&stest,&gen_attr,threadtester,(void *) x);
> post("hello world!");
> }

stest disappears when the thread_bang() returns, the thread is still 
running, and maybe pthread internals write to stest after it is no 
longer there, which would be very bad:  at best, a segmentation fault, 
at worst, no crash but wrong behaviour.

At a guess: malloc() a list node with the pthread_t in it, and store 
those nodes in a list in the Pd object struct.


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] allow only one instance of external object

[Claude Heiland-Allen]

best boy wrote:
> hi
> is there a way to keep track of the number of opened instances of an 
> external?

Is this an external you are writing?  Then yes.  Otherwise there's weird 
tricks you can probably do to keep track, but not control.

> if so, can anyone point me to an example object?

Just have a global counter variable that you initialise to 0 in 
foo_setup(), and in foo_new() you increment it, and in foo_free() you 
decrement it.

> thanks
> olli

Claude
-- 
http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] call for test: uline~ = vline~ without blowup when dsp is off

[Claude Heiland-Allen]

Hi all,

I've been increasingly annoyed by:

"[ 1736518 ] [switch~]ing [vline~] causes ever increasing CPU usage"

https://sourceforge.net/tracker/index.php?func=detail&aid=1736518&group_id=55736&atid=478070

So I tried to fix it, by pruning expired segments from the start of the 
queue when segments are added, instead of waiting for the perform method 
to do it (which only happens when DSP is active).

I probably made some errors, most likely in the munging of the internal 
state - would appreciate testing, particularly any deviations in 
comparison to vline~.

I'm also not sure about the timefudge - it's set to 1000ms which aims to 
be higher than the block size, if the block size is huge then uline~ 
might incorrectly expire some messages sent when DSP is off.  I'm not 
sure what vline~ does when you change the block size, I'm guessing all 
bets are off?

Tarball is here:

https://devel.goto10.org/dl.php?repname=maximus&path=%2Fuline_tilde%2F&rev=0&isdir=1

or:

svn co https://devel.goto10.org/svn/maximus/uline_tilde uline_tilde

When sufficient testing shows there are no remaining bugs, I'll file a 
patch against d_ctl.c on the tracker.


Thanks,


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Calling a method periodically

[Claude Heiland-Allen]

Greg Surges wrote:
> Hi all,
> 
> Is there any way to have an external call a method periodically, without 
> being triggered?

Clocks.  Check the C API in "m_pd.h"..

> I'm thinking of a histogram with a decay function, where the values are 
> decremented every second (or other time value).

I've done something like this with Lua, although I had the decrementing 
done by a [gemhead] not an internal clock, for tighter syncing with 
visuals.  That's what made the keys fade from orange->grey->blue, if you 
happened to be at LAC Club Night during my set.

> Thanks!
> 
> -Greg


Claude
-- 
http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] naming loaders: pdlua, tclpd, etc.

[Claude Heiland-Allen]

Albert Graef wrote:
> Frank Barknecht wrote:
>> May I throw in another one: As loaders are a bit different than
>> externals,
> 
> Uhm, did I miss anything? In which way is a "loader" different from an
> external? 

A loader-external adds a hook into Pd's loader (the bit that searches 
for files to load when an object of unknown class is instantiated). 
This hook can do anything, but most commonly it adds support for classes 
written in languages other than (already compiled) C or .pd text patches.

A "loader" is a subset of an external, any compiled code loaded by Pd is 
an external, but some externals can use the loader API.

 > In that it loads another interpreter? Is there a special new
> API for this kind of things? 

Yes, a simple one: there is a function typedef (for the loader hook 
functionality) and a function to add a hook to the list.  I forget the 
exact names, they're in m_pd.h if you have a new enough Pd.

 > I just want to know as I'm maintaining the
> Pd-Faust and -Q interfaces, and I'm always looking for ways to make them
> work better...

In my experience trying to use Haskell in Pd didn't work so well, partly 
because it was compiled.  Lua, being interpreted, worked much better.

> Albert

Hope this helps,


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] naming loaders: pdlua, tclpd, etc.

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
> XXX
> ---
> lua.pd_linux

^^ this is what I use.  The project as a whole is called 'pdlua' but the 
external for Pd is called 'lua', like '-lib lua' and [lua].

> tcl.pd_linux
> haskell.pd_linux

^^ this is probably what I will use if I ever resume work on my Haskell 
external, or maybe 'ghc.pd_linux' if it depends on that Haskell 
implementation.

The extra 'pd' in the other alternative are redundant.

> Any perferred name?  I don't think I have a strong preference of any  
> name, but I do think there should be a simple, standard naming scheme.

Remove redundant 'pd's.


Claude

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] Pd OSC implementation(s) incompatible with SC3? [Fwd: Re: [sc-users] NetAddr]

[Claude Heiland-Allen]

Hi all,

Thought this might be of interest to developers of OSC externals.

In short: Pd OSC implementations should send OSC on the same port that 
they listen on, as that is the "standard" way OSC works.


Claude

 Original Message 
Subject: Re: [sc-users] NetAddr
Date: Tue, 04 Mar 2008 21:48:37 -0500
From: nescivi
Reply-To: SuperCollider users mailing list <[EMAIL PROTECTED]>
To: SuperCollider users mailing list <[EMAIL PROTECTED]>

Hiho,

On Tuesday 04 March 2008 21:28:27 William Brent wrote:
> Hmm.  I've been doing a little more testing on this, using two separate
> machines.  Here's what seems to be true:
>
> 1) With both machines using SC, OSC messaging is fine through port 57120.
> Each side simply specifies
>
> n = NetAddr("address of other machine", 57120);
> o = OSCresponder(n, '/chat', { |t, r, msg| msg.postln }).add;
>
> n.sendMsg("/chat", "blah");
>
> This means each machine is listening for messages *from* the address of the
> other machine, on port 57120, and sending messages *to* the other addresss
> on port 57120.
>
> So within SC, of course, all is well.

correct, since SC sends from the same port as that it listens to, which 
is as
it should be.
In OSC world it is custom to send reply messages, so from the received 
message
you are able to figure out from which ip and port is was sent, so you can
back a message.


> 2) OSC communication between Max and Max, Pd and Pd, or Pd and Max is all
> fine.
>
> 3) Using either the sendOSC object in Pd, or the udpsend object in Max/MSP,
> communication with SC fails unless SC's OSCresponder addr argument is set
> to nil.  This is in spite of the fact that sendOSC and udpsend require you
> to specify the address and port number you'd like to send *to*.

Again, there is a difference between the address they are sending from and
sending to. Like putting your address on a letter you send by snail 
mail. It
gives the receiver a method to figure out where the letter came from, and
enables him to send a letter back.



> There is 
> no way to specify what port you're sending *from* on the Pd or Max
> machines, but I've been told that if you're sending to a specific port on
> another machine, the local machine must necessarily be sending out the same
> port.  I have no idea if that's true or not...

no.
The fact that there is no way to specify *from* which Pd or Max are 
sending is
a weakness on their side. They should either let you specify it, or 
document
which port they are using. But chances are that they just take any port, in
which case you have no other option than to use nil in the OSCresponder.

But maybe Max and Pd are consistent in their behaviour.

I am not entirely sure whether this will work, for lack of Pd on my system,
but possibly with this bit of code, you van figure out from which 
address Pd
is sending.

o = OSCresponder(nil, '/chat', { |t, r, msg, addr| addr.postln; }).add;

I think it should post the addr. that the message comes from; please 
test this
by banging your sendOSC object multiple times to see if it is consistent.

> So, in a way, there's no problem, as long as you explicitly specify no
> NetAddr to listen for.  A friend of mine did a piece by Paul Lansky that
> required SC/Max communication, and that code also has OSCresponders
> listening to a "nil" NetAddr, since it was the only way to make it happen.
>
> I don't know enough about this to suggest what's going on.  Maybe I'm still
> missing something (and sorry if I am!), but it seems like there could be a
> problem on the SC side here...

nope, the problem is on the other side.
SC allows for a safe mechanism by only listening to one specific port. 
It is
up to the sending application to provide an equally safe mechanism to send
messages out.

sincerely,
Marije
___
sc-users mailing list
[EMAIL PROTECTED]
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd-extended loadlib request

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
> On Jan 24, 2008, at 2:31 PM, Mathieu Bouchard wrote:
> 
>> On Wed, 23 Jan 2008, Hans-Christoph Steiner wrote:
>>
>>> What other programming language has aliases?
>> Ruby accepts both 'indices' and 'indexes' as selectors in the Array  
>> and Hash classes. Ruby has 'alias' as a reserved word.
>>
> 
> I mean aliases for functions.  I know of no programming language  
> besides Pd (and maybe Max) that has multiple names for functions that  
> do the exact same thing.

In most languages, you can define your own *local* names/aliases:

C:
   typedef double (*function)(double);
   function foo = sin;

Lua:
   local foo = somepackage.somefunction

Haskell:
   foo = Module.function


I think most agree that global aliases don't really add much, but local 
aliases, ie, per "module" or smaller unit (which in Pd would be per 
abstraction) are very useful.


Claude
-- 
http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Lua object help-path strangeness

[Claude Heiland-Allen]

Hi Frank, all,

Frank Barknecht wrote:
 > This doesn't seem to be specific to Lua: pdlua doesn't do anything
 > regarding help file searches at all, "grep help pdlua/src/*" yields no
 > results. So Claude and I suspect it's something with the loader
 > functionality. Can someone comment on this?

I did some digging through Pd's source code, specifically s_loader.c, 
and found the trick to make things loaded by loaders find help patches:

8<
   /* defined in m_class.c but not exported. */
   void class_set_extern_dir(t_symbol *);
8<

Use it like this:

8<
   fd = canvas_open(canvas, name, ".lua", dirbuf, &ptr, MAXPDSTRING, 1);
   if (fd >= 0) {
 class_set_extern_dir(gensym(dirbuf));
 /* Lua-specific loader stuff goes here. */
 class_set_extern_dir(&s_);
   }
8<

Seems to work here, at least it finds help patches correctly now.  In 
pdlua SVN at revision 496.

This is with pd-0.40-3 from Miller's site on Linux, fwiw.

Thanks,


Claude
-- 
http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] autotools magic for externals?

[Claude Heiland-Allen]

Hi all,

I've been trying to use autotools (autoconf and friends) to build pdlua, 
but have ended up in a world of pain and deleted my experiments out of 
frustration.  I tried to understand the system used in 
CVS/externals/moocow/, but the wizardry was somewhat beyond me.  Even 
more so with the Gem system.

So, is there a set of macros I can drop into my acinclude.m4 that 
provide a nice auto-n00b-friendly environment as a base for creating a 
configure.ac and a Makefile.am for a Pd external that requires some 
libraries?

In other news regarding pdlua, I created a Makefile.static for those 
that want to compile Lua into the external statically.  Currently only 
in the development version, soon to be pdlua-0.3 once I've added enough 
new features to merit a release.

Thanks for any input,


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] getting the classname in an class

[Claude Heiland-Allen]

Mathieu Bouchard wrote:
> On Sat, 27 Oct 2007, Claude Heiland-Allen wrote:
> 
>> See attached external and Pd patch for a solution (workaround?) using 
>> an A_GIMME constructor, at least with pd-miller-0.40-2...
> 
> This is because the first argument of the constructor is the same thing 
> as the first element of the binbuf of the object, as that element is the 
> selector in the message that is sent to [objectmaker]. So it does like 
> what our latest solutions do, but because you get it from the 
> constructor, you can only use it in the constructor or you have to store 
> it. but it's already stored in the object, as the first element of the 
> binbuf, so...

Ah, I didn't quite understand what was going on.  Thanks for clarification.

(I was going to say requiring non-m_pd.h files was bad, but that's no 
issue for modifying Pd itself...)

Thanks,


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] getting the classname in an class

[Claude Heiland-Allen]

Hi,

See attached external and Pd patch for a solution (workaround?) using an 
A_GIMME constructor, at least with pd-miller-0.40-2...


Thanks,


Claude
--
http://claudiusmaximus.goto10.org



howto-get-creation-classname.tar.gz
Description: application/gzip
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Was: [PD] Good sounding PD reverb patches - anyone?

[Claude Heiland-Allen]

Patrice Colet wrote:
> Peter Plessas a écrit :
>> Hi,
>>
>> have a look at Thomas Musil's excellent Room Reverberation Simulation
>> too:
>>
>> http://pure-data.cvs.sourceforge.net/pure-data/externals/iem/iem_roomsim/
>>
>> Ah, i am not sure how to find binaries for windows though...
>>
> 
> Hello,
>   my attempts to make a win32 binary has failed, and I couldn't find out 
> how to fix, maybe someone could give some help with reading the 
> following error message:

Remove all -Werror from the Makefile.  -Werror makes warnings into 
errors, which is fine if you're testing/developing, but really bad if 
you're releasing code into the wild because different versions of gcc 
have different warnings.

> 
> ~/externals/iem/iem_roomsim/src
> $ make -f makefile_win-mingw
> gcc -Wall -W -Wshadow -Wstrict-prototypes -DPD -DNT -W3 -WX -Werror 
> -Wno-unused -mms-bitfields -Wno-parentheses -Wno-switch -O6 
> -funroll-loops -fomit-frame-pointer -I.. -I../include -I/home/pat/pd/src 
> -c -o early_reflections_3d.o early_reflections_3d.c -l lpthreads -l ldl 
> -l lm
> early_reflections_3d.c: In function `early_reflections_3d_doit':
> early_reflections_3d.c:247: warning: declaration of 'y0' shadows a 
> global declaration
> c:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/math.h:251: 
> warning: shadowed declaration is here
> make: *** [early_reflections_3d.o] Error 1


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pdlua: volatile objects...?

[Claude Heiland-Allen]

Claude Heiland-Allen wrote:
> [EMAIL PROTECTED] wrote:
>> hi list, hi claude.

[snip]

>> would this be easy to implement?
> 
> Not too hard, hopefully, but not trivial either.

I found it rather harder than I expected (eg: what is the rationale 
behind the type of class_addcreator()?), so I wrote a dirty quick class 
(in Lua) that lets you load/reload scripts at object initialization 
time.  Doesn't have a reload method because iolet counts may change. 
See "luax-help.pd".

> Also I plan [lua] to have an inlet/method where you can send names of 
> scripts to be executed, which could be useful for quickly modifying some 
> classes/objects without having to restart Pd.

This is done, also quick and dirty, neither:
  "load foo"--[lua]  (which runs 'foo.lua')
nor:
  [luax foo]  (which grabs an initialization function from 'foo.luax')
use the pd path yet.  Shouldn't be hard to fix.


Claude

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pdlua: volatile objects...?

[Claude Heiland-Allen]

[EMAIL PROTECTED] wrote:
> hi list, hi claude.
> 
> using the great pdlua extension it is easy to create object(classe)s in lua.
> however, the class is registered on loading and then kept in memory of pd.

The problem is Pd doesn't give loaders the chance to load a class if it 
is already loaded, but there is a way around it, I think.

> for rapid prototyping it would sometimes be nice to be able to do a  
> "volatile" load (just like abstractions) of an object: so when i  
> change the code and re-instantiate the object, i will get a new version.

It's certainly possible, here's a quick hack method:


-- volatile.lua
volatile = pd.Class:new():register("volatile")

function volatile:initialize(s, m)
   dofile(m[1] .. ".lua")   -- note, only searches current dir!
   return run(self, m)
end


-- volatile-test.lua
function run(self, m)
   pd.post("just testing stuff")
   self.inlets = 0
   self.outlets = 0
   return true
end


Sorta works, but not elegant.  Should be possible to do it so that the 
volatile user code is minimally different from the normal user code. 
Something like

-- volatile-test.lua
pd.volatile(function()
-- normal class code here
end)

where pd.volatile(f) would munge the environment before calling the 
function argument, then unmunge the environment afterwards.  Munging 
would take the form of replacing pd.Class with pd.VolatileClass or so. 
All VolatileClass objects would have the same real class registered in 
Pd,, but the loader can keep reloading classes that are not found 
because no new classes are really registered.

> would this be easy to implement?

Not too hard, hopefully, but not trivial either.  It's a nice idea that 
would be useful, it's a pain having to restart Pd when testing.

Also I plan [lua] to have an inlet/method where you can send names of 
scripts to be executed, which could be useful for quickly modifying some 
classes/objects without having to restart Pd.


Claude

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] sys_idlehook and audio API interaction

[Claude Heiland-Allen]

Hi Thomas,

Yes, I remember, with different return codes from the hook for "I'm 
done" and "I have more to do" (and also "I did nothing"?).

I also think there should be a better mechanism for registering hooks, 
that also allows unregistering hooks later.  Example:

1. X stores existing loader hook W, registers hook X
2. Y stores existing loader hook X, registers hook Y
3. X wants to remove hook, so restores loader hook to W
4. Y no longer has its hook registered => badness

Something like a priority queue of hooks would be useful, but then 
you're in the realm of implementing a multitasking scheduler

Thanks,


Claude


Thomas Grill wrote:
> Hi Claude,
> since we were in the same paper session at the convention you might 
> remember that i was advocating a different idle processing scheme in my 
> talk.
> When you are looking into m_sched.c you'll notice that the sys_idlehook 
> call is dependent on the didsomething varialbe, which is again dependent 
> on the behavior (type, blocksize etc.) of the specific audio api.
> I haven't had time to provide patches for the devel_0_39 solution to 
> this, but i'll promise that i'll do one of these days.
> 
> greetings,
> Thomas
> 
> Am 05.09.2007 um 20:48 schrieb Claude Heiland-Allen:
> 
>> Hi,
>>
>>
>> I made an external to let patches do things when Pd is idle:
>>
>> [idlebang] -- output a bang when Pd is idle
>>
>> but it seems to be heavily dependent on the audio API.
>>
>>
>> With OSS, I get around 200 bangs per second.
>>
>> With ALSA, I get around 7 bangs per second.
>>
>> With JACK, I get around 1 bang per second.
>>
>> With audio off, I get around 16 bangs per second.
>>
>> I haven't tried PortAudio yet.
>>
>>
>> Any idea why this might be?
>>
>>
>> Source code tarball is here:
>>
>> https://devel.goto10.org/dl.php?repname=maximus&path=%2Fidlebang%2F&rev=0&isdir=1
>>  
>> <https://devel.goto10.org/dl.php?repname=maximus&path=%2Fidlebang%2F&rev=0&isdir=1>
>>
>>
>> Thanks for any insights,
>>
>>
>> Claude
>> -- 
>> http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] sys_idlehook and audio API interaction

[Claude Heiland-Allen]

Hi,


I made an external to let patches do things when Pd is idle:

[idlebang] -- output a bang when Pd is idle

but it seems to be heavily dependent on the audio API.


With OSS, I get around 200 bangs per second.

With ALSA, I get around 7 bangs per second.

With JACK, I get around 1 bang per second.

With audio off, I get around 16 bangs per second.

I haven't tried PortAudio yet.


Any idea why this might be?


Source code tarball is here:

https://devel.goto10.org/dl.php?repname=maximus&path=%2Fidlebang%2F&rev=0&isdir=1


Thanks for any insights,


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] fix for pd compilation on OpenSUSE (HZ and sysconf())

[Claude Heiland-Allen]

irc.freenode.net/#dataflow 2007-08-26
11:21 < AndyGraybeal> x_misc.c: In function 'cputime_bang2':
11:21 < AndyGraybeal> x_misc.c:233: error: 'HZ' undeclared (first use in 
this function)
11:21 < AndyGraybeal> x_misc.c:233: error: (Each undeclared identifier 
is reported only once
11:21 < AndyGraybeal> x_misc.c:233: error: for each function it appears in.)
11:21 < AndyGraybeal> make: *** [x_misc.o] Error 1
11:22 < AndyGraybeal> this is where i've been getting stuck every 
time no matter what version of pd
11:34 < ClaudiusMaximus> try adding this to x_misc.c below the #include 
lines:
11:34 < ClaudiusMaximus> #ifndef HZ
11:34 < ClaudiusMaximus> # define HZ sysconf(_SC_CLK_TCK)
11:34 < ClaudiusMaximus> #endif
11:38 < AndyGraybeal> holy pooop it works!


It seems OpenSUSE is following this document:

http://www.opengroup.org/onlinepubs/009695399/functions/sysconf.html

which makes some sense regarding portability of binaries to systems 
other than the one they were compiled on.


Since sysconf() is a function, it might be better to cache HZ in a 
variable together with the above "quick fix" #define, given that it is 
guaranteed to remain unchanged throughout the lifetime of the process.


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] help-array crashing outlet_anything

[Claude Heiland-Allen]

[EMAIL PROTECTED] wrote:
> Intstore *storepointer;

> Intstore *storepointer = new Intstore();

>   storepointer[arraynumber] = *pointer;

This is the problem.  You have only one Intstore object pointed to by 
storepointer, but you're assuming you have more than one whenever 
arraynumber is not 0.  When arraynumber is not 0, you get undefined 
behaviour (which could be wrong results or (if you're lucky) a crash).


Claude
-- 
http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pd_error() deprecated

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
> How about a compiler warning, isn't it something like #warning?

No, that emits a warning when the #warning line is reached by the 
preprocessor.  In GNU C you can emit warnings when deprecated functions 
are *used* like this:

int old_fn () __attribute__ ((deprecated));

But that's GNU C not ANSI C nor Microsoft C nor...


Claude
-- 
http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] recursion in Gem - a tutorial

[Claude Heiland-Allen]

IOhannes m zmoelnig wrote:

i haven't had a look at the tutorial files, but i was wondering why you
couldn't build [nrepeat] (i haen't seen [nnrepeat] on the website, so i
don't know what it does) with [repeat] or with the [s]/[r] idiom claude
has proposed.

see attached patch for a solution using zexy's [repeat].



Yes, that is what I tried too.  But it doesn't work -- it fails with 
re-entrancy bugs when recursion is used.


See attached test patch.


With max-depth 3, repetitions 2:

My [nrepeat] external outputs:
nrepeat: 3 0
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 2 1
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 3 1
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 2 1
nrepeat: 1 0
nrepeat: 1 1

Your [nrepeat-abs] abstraction outputs:
nrepeat: 3 0
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 2 2
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 3 2
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 2 2
nrepeat: 1 0
nrepeat: 1 1


With max-depth 3, repetitions 3:

My [nrepeat] external outputs:
nrepeat: 3 0
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 1
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 2
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 3 1
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 1
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 2
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 3 2
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 1
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 2
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2

Your [nrepeat-abs] abstraction outputs:
nrepeat: 3 0
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 3
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 3
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 3 3
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 3
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 3
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 3 3
nrepeat: 2 0
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 3
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2
nrepeat: 2 3
nrepeat: 1 0
nrepeat: 1 1
nrepeat: 1 2



mfgasdr
IOhannes


Thanks,


Claude

#N canvas 0 0 481 517 10;
#X obj 71 95 r \$0-recurse;
#X obj 71 380 s \$0-recurse;
#X obj 108 260 t b a b;
#X obj 192 280 v \$0-depth;
#X obj 192 300 - 1;
#X obj 192 320 max 0;
#X obj 130 340 spigot;
#X obj 192 340 v \$0-depth;
#X obj 166 160 t b f;
#X obj 166 183 v \$0-depth;
#X obj 166 208 pack f f;
#X obj 165 239 print nrepeat;
#X obj 108 280 v \$0-depth;
#X obj 108 320 v \$0-depth;
#X obj 108 300 + 1;
#X obj 108 50 t a b;
#X msg 108 21 nrepeat test;
#X obj 285 108 v \$0-depth;
#X floatatom 262 77 5 0 0 2 max-depth - -;
#X floatatom 261 38 5 0 0 2 repetitions - -;
#X obj 246 108 f 3;
#X obj 108 135 nrepeat 2;
#X connect 0 0 21 0;
#X connect 2 0 12 0;
#X connect 2 1 6 0;
#X connect 2 2 3 0;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
#X connect 5 0 6 1;
#X connect 5 0 7 0;
#X connect 6 0 1 0;
#X connect 8 0 9 0;
#X connect 8 1 10 1;
#X connect 9 0 10 0;
#X connect 10 0 11 0;
#X connect 12 0 14 0;
#X connect 14 0 13 0;
#X connect 15 0 21 0;
#X connect 15 1 20 0;
#X connect 16 0 15 0;
#X connect 18 0 20 1;
#X connect 19 0 21 1;
#X connect 20 0 17 0;
#X connect 21 0 2 0;
#X connect 21 1 8 0;
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] definitions in m_pd.h that aren't present in pd (and vice versa)

[Claude Heiland-Allen]

Hi,


I'm trying to use SWIG in my work on a Lua external for Pd, and had to 
comment out the following definitions in m_pd.h to get code generated by 
SWIG to load without "undefined symbol" errors:

EXTERN t_symbol *pd_getfilename(void);
EXTERN t_symbol *pd_getdirname(void);
EXTERN void pd_anything(t_pd *x, t_symbol *s, int argc, t_atom *argv);
EXTERN t_parentwidgetbehavior *class_parentwidget(t_class *c);
EXTERN int sys_isreadablefile(const char *name);
EXTERN float garray_get(t_garray *x, t_symbol *s, t_int indx);
EXTERN void c_extern(t_externclass *cls, t_newmethod newroutine,
  t_method freeroutine, t_symbol *name, size_t size, int tiny,
  t_atomtype arg1, ...);
EXTERN void c_addmess(t_method fn, t_symbol *sel, t_atomtype arg1, ...);

I guess these have either been removed from pd, or aren't declared with 
the right visibility in the source.  It would be great if this could be 
fixed.


Also, the following are visible in pd, but undeclared in m_pd.h, meaning 
I have to declare them myself:

typedef int (*loader_t)(t_canvas *, char *);
void sys_register_loader(loader_t loader);

Would be super if this could be fixed too.


Tested with pd-0.40-2 from Miller's site.


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how do I get my containing canvas? [solved]

[Claude Heiland-Allen]

Rich E wrote:
> I've been using a block of code I found in the [textfile] and [msgfile]
> externals:

[snip]

>  dirname = canvas_getdir(x->canvas)->s_name; // of type t_canvas

[snip]

> Hope this helps,

Well, it helped a little indirectly as it showed me to look for where 
x->canvas was initialized, and I found one example here:

static void *qlist_new( void)
{
 snip
 x->x_canvas = canvas_getcurrent();
 snip
}

I think I'll be doing that in my external's _new function, and use the 
canvas I get from canvas_getcurrent() with canvas_open().

canvas_getcurrent() is only valid in the _new function, I assume?

> rich

Thanks,


Claude

> 
> On 3/23/07, Claude Heiland-Allen  wrote:
>>
>> Steffen wrote:
>> > On 22/03/2007, at 23.41, Roman Haefeli wrote:
>> >
>> >> When opening patches by sending messages to pd, the path is
>> >> relative to
>> >> pd's startup-location. when loading other files (text-, audio-,
>> >> data-files etc) the path is set relative to the location of the patch.
>> >> since the patch doesn't know, where pd was started, you actually
>> >> cannot
>> >> use relative pathes when opening patches by messages without:
>> >
>> > Maybe [declare] can help you? (Pd >= 0.40)
>>
>> (Maybe) relatedly:
>>
>> How would I open a file relative to a patch in an external instantiated
>> within that patch?
>>
>> canvas_open() seems to be exactly what I want, but how to get the
>> containing canvas of my object?
>>
>> Hoping there is a solution,
>>
>>
>> Claude
>> -- 
>> http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] how do I get my containing canvas? (Was: Re: [PD] relative pathes: problems with [open(-message to pd)

[Claude Heiland-Allen]

Steffen wrote:
> On 22/03/2007, at 23.41, Roman Haefeli wrote:
> 
>> When opening patches by sending messages to pd, the path is  
>> relative to
>> pd's startup-location. when loading other files (text-, audio-,
>> data-files etc) the path is set relative to the location of the patch.
>> since the patch doesn't know, where pd was started, you actually  
>> cannot
>> use relative pathes when opening patches by messages without:
> 
> Maybe [declare] can help you? (Pd >= 0.40)

(Maybe) relatedly:

How would I open a file relative to a patch in an external instantiated 
within that patch?

canvas_open() seems to be exactly what I want, but how to get the 
containing canvas of my object?

Hoping there is a solution,


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Separating GUI from the engine in PD

[Claude Heiland-Allen]

Chris McCormick wrote:
> On Tue, Mar 13, 2007 at 12:27:33AM -0400, carmen wrote:
>> 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
> 
> You also might want to try PDa - I had some trouble trying to compile Pd
> with no GUI (but that was some time ago).

I've compiled Pd without pd-gui, on a machine without X (and so probably 
no tk, not sure about X).  Can't remember how I did it now, probably 
./configure, make pd pdsend pdreceive, edit Makefile if/when make fails, 
repeat as necessary.

I used pd -nogui -lib gridflow on that machine to render video.


Claude
-- 
http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how do I go about pd_bind()ing multiple symbols to one object and distinguish between them?

[Claude Heiland-Allen]

Frank Barknecht wrote:

Hallo,
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
The initial aim is to write an external that does similar to what an 
abstraction made up of loads of copies of


   [receive $1-balb]--[list prepend balb]--[list trim]--[outlet]

would do, with 'balb' different each time, and only one outlet for the 
whole abstraction.


Okay, sounds like a very useful time saver.

Ciao


Attached is a simple, unoptimized version implemented in Pd.  It could 
be improved by exploding the abstraction into the constructor subpatch 
(loading abstractions NN times is slow, and fewer files mean less to go 
missing...).


Still haven't worked out how to do this in an external...


Claude
--
http://claudiusmaximus.goto10.org


nreceive-0.1.tar.gz
Description: application/gzip
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how do I go about pd_bind()ing multiple symbols to one object and distinguish between them?

[Claude Heiland-Allen]

Frank Barknecht wrote:
> Hallo,
> Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
> 
>> I'm writing an external, and I want it to have multiple named receivers 
>> that do different things (something that seems trivial for an 
>> abstraction but rather tricky for an external).
> 
> Does it really have to be multiple receivers?

Yes, because...

> Maybe you could use the
> equivalent of [route] as in 
> 
>   [r GLOBAl]
>   |
>   [route local-1 local-2 local-3 ...]
> 
> Then you would only need one receiver (with pd_bind) and most of the
> rest could be copied from the "route"-code. You would however need to
> use specially formatted messages on the sender-side, that use these
> "tags" to reach their correct destination.

...afaik no GUI objects send these specially formatted messages.

The initial aim is to write an external that does similar to what an 
abstraction made up of loads of copies of

   [receive $1-balb]--[list prepend balb]--[list trim]--[outlet]

would do, with 'balb' different each time, and only one outlet for the 
whole abstraction.

I guess I could implement this as an abstraction with internal messages, 
but why should externals be second-class citizens? ;)

And it's also a learning exercise, of course :)

> Ciao

Thanks,


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] how do I go about pd_bind()ing multiple symbols to one object and distinguish between them?

[Claude Heiland-Allen]

Hi,

I'm writing an external, and I want it to have multiple named receivers 
that do different things (something that seems trivial for an 
abstraction but rather tricky for an external).

I worked out how to have multiple 'anything' inlets using a proxy class 
(modelled after the [list ...] internals), but I'm stuck when it comes 
to multiple 'anything' receivers.

If i just do:

   pd_bind(myobject, gensym("blah"));
   pd_bind(myobject, gensym("glah"));

then myobject can't distinguish whether the message got sent to "blah" 
or "glah", which is loss of information that I need.

So, I somehow need to create fake objects (one for each receiver) that 
forward the messages to the real object (adding in some extra info 
unique to the receiver).

The problem is I don't know how to create the fake objects.  Anyone have 
any ideas / example code / tips to offer?


Claude


PS:

It would have been nicer if instead of:

   pd_bind(object, symbol)

there was also something like:

   pd_bind_method(object, symbol, method)

or even better:

   pd_bind_method(object, symbol, method, methoddata)


-- 
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] "float a" vs "symbol 1"

[Claude Heiland-Allen]

"float a"
 |
[print]

error: Bad arguments for message 'float' to object 'messresponder'


but


"symbol 1"
 |
[print]

print: symbol

(in fact an empty symbol: selector message>, checked 
with Print.hs from hsext [1])



I think *both* cases should error, with a more informative error message 
(such as listing the offending arguments).



Also, maybe (optional) warnings for cases such as:

"float 1 2 3"   (equivalent to "float 1")
"float 1 a b"   (equivalent to "float 1")
"symbol a b c"  (equivalent to "symbol a")
"symbol a 1 2"  (equivalent to "symbol a")


Any thoughts?


[1] 
http://devel.goto10.org/listing.php?repname=maximus&path=%2Fhsext%2F&rev=0&sc=0


Claude
--
http://claudiusmaximus.goto10.org


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

[PD-dev] inverse of myclass_setup()? myclass_unsetup()?

[Claude Heiland-Allen]

Hi,

Say I have the following:

hsext_setup() {
  /*
start Haskell run time system
  */
}

hsext_unsetup() {
  /*
stop Haskell run time system
cannot be restarted hereafter
  */
}

Am I correct in assuming hsext_setup() will be called at most once?

How can I ensure hsext_unsetup() is called when Pd exits?

Is atexit() the right way?  Seems dirty:


$ man atexit

Since glibc 2.2.3, atexit() can be used within a shared library to 
establish functions that are called when the shared library is unloaded.


Functions registered using atexit() are not called if a process 
terminates abnormally because of the delivery of a signal.





Thanks for any ideas,


Claude
--
http://claudiusmaximus.goto10.org

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] glob for windows?

[Claude Heiland-Allen]

Hans-Christoph Steiner wrote:
Does anyone know of a glob implementation in C for Windows? 


My naive Google Code Search turns up this:

http://tinyurl.com/yfllga -- part of PHP5, BSD license


___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [ pure-data-Bugs-1602066 ] iemgui empty vertical offset crashes X on Linux

[Claude Heiland-Allen]

Frank Barknecht wrote:
> Hallo,
> SourceForge.net hat gesagt: // SourceForge.net wrote:
> 
>> Summary: iemgui empty vertical offset crashes X on Linux
>>
>> Initial Comment:
>> Steps to crash X windowing system on Linux using Pd:
>>
>> 1. Start X
>> 2. Start Pd
>> 3. Create a new patch
>> 4. Create a new vslider in that patch
>> 5. Open the properties window for that vslider
>> 6. Set the label to x, and delete all text in the y-off field
>> 7. to cause X to crash, click apply
>>
>> at this point X starts to use 100% CPU and its memory usage shoots up, 
>> making the whole machine largely unresponsive and requiring X to be aborted 
>> with Ctrl-Alt-Backspace
> 
> Doesn't crash here at all, CPU usage stays low. Am I doing something
> wrong?
> 
> Ciao

Don't know - I just tried with a freshly compiled pd-0.40-2 from
Miller's site, on the same linux install, and got the same crash, so
I've got a feeling it must be something in my tcl/tk and/or X versions
that is to blame...

Thanks,


Claude

___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev