Re: [PD-dev] [PATCH] Avoid crash in vd~ for nan/inf input values
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
--- ** [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] #1099 misleading message when single-stepping with global dsp off
--- ** [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] [pure-data:bugs] #1101 make install fails if already installed to the same prefix
---
** [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] floating point exception crashes (INT_MIN % -1)
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
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
-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] shared class data and functions
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...
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...
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
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
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?
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
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
Re: [PD-dev] Segfault without messages
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] Segfault without messages
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=13589view=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
[PD-dev] [maxlib/history] segfault
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=value optimised out)
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=value optimised
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=value optimised out,
argc=value optimised out, ubp_av=value optimised out,
init=value optimised out, fini=value optimised out,
rtld_fini=value optimised out, 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=13589view=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
[PD-dev] local libraries for local patches are impossible [Was: Re: 0.43 omission: 'set-startup' and 'set-path']
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 m_pd.h
extern int external_data;
extern void external_setup(void) { post(foo/external: %d,
external_data++); }
int external_data = 42;
$ cat bar/external.c
#include m_pd.h
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] local libraries for local patches are impossible
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 m_pd.h
extern int external_data;
extern void external_setup(void) { post(foo/external: %d,
external_data++); }
int external_data = 42;
$ cat bar/external.c
#include m_pd.h
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 m_pd.h
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 m_pd.h
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
Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'
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
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 obj5.bin.lua
[PD-dev] Pure-data libraries
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
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: snip bad option -cursor: Claude ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] modular pd-extended - when release?
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
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 h...@at.or.at 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 mailto: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 mailto: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?
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
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] ATI + GridFlow + Gem + C++ + Linux = BOOM
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???!?!?
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
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] Pure Data/adding _path for gridflow
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
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)
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)
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?
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] How to pass indeterminate args to a thread
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
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
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
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] developer
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] representing parent patch levels as args
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
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 newest = 0;
}
+}
t_symbol
Re: [PD-dev] Problem building pdlua on MinGW (solved for now)
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
[PD-dev] cross-platform support for externals (extern not enough?) (Was: Re: Problem building pdlua on MinGW (solved for now))
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
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] dump OSC bugs?
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
[PD-dev] pd_error in constructors (Was: Re: dump OSC bugs?)
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 m_pd.h
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] recording the overall state of a patch
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
[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
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
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] 'cnv' colors
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
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] changing glob_setfilename() to handle spaces in the dirname
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
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
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
Re: [PD-dev] Calling a method periodically
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.
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
Re: [PD-dev] naming loaders: pdlua, tclpd, etc.
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
[PD-dev] Pd OSC implementation(s) incompatible with SC3? [Fwd: Re: [sc-users] NetAddr]
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
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
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?
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
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] getting the classname in an class
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] pdlua: volatile objects...?
[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] pdlua: volatile objects...?
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
[PD-dev] sys_idlehook and audio API interaction
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=maximuspath=%2Fidlebang%2Frev=0isdir=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
Re: [PD-dev] sys_idlehook and audio API interaction
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=maximuspath=%2Fidlebang%2Frev=0isdir=1 https://devel.goto10.org/dl.php?repname=maximuspath=%2Fidlebang%2Frev=0isdir=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())
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
[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
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
[PD-dev] definitions in m_pd.h that aren't present in pd (and vice versa)
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]
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 claudiusmaximus at goto10.org 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)
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] how do I go about pd_bind()ing multiple symbols to one object and distinguish between them?
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?
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?
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
float a | [print] error: Bad arguments for message 'float' to object 'messresponder' but symbol 1 | [print] print: symbol (in fact an empty symbol: selectorsymbol messagesymbol, 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=maximuspath=%2Fhsext%2Frev=0sc=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()?
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?
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
