[PD-dev] libpd partly working with pd instances
To Pd developers...
I've adapted Pd to nternally use a pdinstance structure to allow
multiple schedulers (including DSP chains) to run in one address space.
With slight modification (see below) libpd can use this to run separate
patches asynchronously.
I tried to instance-ize all Pd symbols to keep them private but ran into
seemingly insoluble problems, so am leaving all symbols global for now.
(So patches used in pdlib, if they want to be usable in a multiple-instance
scenaro, should protect all send/receive/table/delay/etc named objects with
a $[0-9] somewhere.
I didn't look hard, but I thnk pdlib now will need a way to send $ arguments
to patches via libpd_openfile() somehow. Also, libpd_init_audio() will want to
make number of channels per-instance, etc. I've put some relevant comments
in the test program I'll include below (and sorry for the length of this
mail!)
Here's how I modified libpd_wrapper/z_libpd.c:
55d54
sys_time = 0;
110c109
sched_tick(sys_time + sys_time_per_dsp_tick);
---
sched_tick();
130c129
sched_tick(sys_time + sys_time_per_dsp_tick); \
---
sched_tick(); \
--
and here (sorry again) is the test program, pdtest2.c adapted from
libpd-master/samples/c_samples/c/pdtest.c :
-
#include stdio.h
#include z_libpd.h
#include m_imp.h
#define TIMEUNITPERMSEC (32. * 441.)
void pdprint(const char *s) {
printf(%s, s);
}
void pdnoteon(int ch, int pitch, int vel) {
printf(noteon: %d %d %d\n, ch, pitch, vel);
}
int main(int argc, char **argv) {
t_pdinstance *pd1 = pdinstance_new(), *pd2 = pdinstance_new();
if (argc 3) {
fprintf(stderr, usage: %s file folder\n, argv[0]);
return -1;
}
int srate = 44100;
// maybe these two calls should be available per-instnace somehow:
libpd_set_printhook(pdprint);
libpd_set_noteonhook(pdnoteon);
/* set a current instance before libpd_init() or else Pd will make
an unnecessary third default instance. */
pd_setinstance(pd1);
libpd_init();
/* ... here we'd sure like to be able to have number of channels be
per-nstance. The sample rate is still global within Pd but we might
also consider relaxing that restrction. */
libpd_init_audio(1, 2, srate);
float inbuf[64], outbuf[128]; // one input channel, two output channels
// block size 64, one tick per buffer
pd_setinstance(pd1); // talk to first pd instance
// compute audio[; pd dsp 1(
libpd_start_message(1); // one entry in list
libpd_add_float(1.0f);
libpd_finish_message(pd, dsp);
// open patch [; pd open file folder(
libpd_openfile(argv[1], argv[2]);
pd_setinstance(pd2);
// compute audio[; pd dsp 1(
libpd_start_message(1); // one entry in list
libpd_add_float(1.0f);
libpd_finish_message(pd, dsp);
// open patch [; pd open file folder(
libpd_openfile(argv[1], argv[2]);
/* the follownig two messages can be sent without setting the pd nstance
and anyhow the symbols are global so they may affect multiple instances.
However, if the messages change anyhing in the pd instacne structure
(DSP state; current time; list of all canvases n our instance) those
changes will apply to the current Pd nstance, so the earlier messages,
for instance, were sensitive to which was the current one.
Note also that I'm using the fact taht $0 is set to 1003, 1004, ...
as patches are opened -it would be better to opent the patches with
settable $1, etc parameters to libpd_openfile(). */
// [; pd frequency 1 (
libpd_start_message(1); // one entry in list
libpd_add_float(1.0f);
libpd_finish_message(1003-frequency, float);
// [; pd frequency 1 (
libpd_start_message(1); // one entry in list
libpd_add_float(2.0f);
libpd_finish_message(1004-frequency, float);
// now run pd for ten seconds (logical time)
int i, j;
for (i = 0; i 3; i++) {
// fill inbuf here
pd_setinstance(pd1);
libpd_process_float(1, inbuf, outbuf);
if (i 2)
{
for (j = 0; j 8; j++)
printf(%f , outbuf[j]);
printf(\n);
}
pd_setinstance(pd2);
libpd_process_float(1, inbuf, outbuf);
if (i 2)
{
for (j = 0; j 8; j++)
printf(%f , outbuf[j]);
printf(\n);
}
}
return 0;
}
--
I replaced test.c as follows:
-
#N canvas 406 290 450 300 10;
#X obj 97 64 loadbang;
#X obj 97 131 print;
#X obj 186 106 dac~;
#X obj 97 107 f 0;
#X obj 128 107 + 1;
#X obj 97 86 metro 2;
#X obj 185 41 r \$0-frequency;
#X obj 188 73 osc~;
#X obj 248 127 print \$0-frequency;
#X obj 248 97 loadbang;
#X connect 0 0 5 0;
#X connect 3 0 1 0;
#X connect 3 0 4 0;
#X connect 4 0 3 1;
#X connect 5 0 3 0;
#X connect 6 0 7 0;
#X connect 6 0 8 0;
#X connect 7 0 2 0;
#X connect 7 0 2 1;
#X connect 9 0 8 0;
and got this output:
print: 0
1003-frequency: bang
print: 0
Re: [PD-dev] libpd partly working with pd instances
Cool. The API as it stands is well designed, very straightforward. Perhaps it will work to wrap the pdinstance structure and related functions calls (pdinstance_new() etc) in a libpd instance structure/API that can keep track of callback functions, etc. cheers Miller On Sun, May 11, 2014 at 12:01:24PM +0200, Kjetil Matheussen wrote: On Sun, May 11, 2014 at 9:00 AM, Miller Puckette m...@ucsd.edu wrote: To Pd developers... I've adapted Pd to nternally use a pdinstance structure to allow multiple schedulers (including DSP chains) to run in one address space. With slight modification (see below) libpd can use this to run separate patches asynchronously. This is really great news! When I'm finished with some other things I'll try to wrap the libpds API around this new system, and see how it works with Radium. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] oggread~ not working on pd-extended or libpd on windows.
I THink it should really be:
if((x-x_file = sys_fopen(filename-s_name, r)) == 0)
sys_fopen returns NULL (also known as 0) on failure, otherwise a pointer;
it makes no sense to check the sign of a pointer as far as I know.
cheers
Miller
On Fri, Apr 04, 2014 at 11:21:37PM -0400, Martin Peach wrote:
I think it's here:
http://sourceforge.net/p/pure-data/patches/
Martin
On 2014-04-04 21:49, Rafael Vega wrote:
Even more stuff ;)
In the same file, oggread~.c there is a line that reads:
if((x-x_file = sys_fopen(filename-s_name, r)) 0)
But it should be:
if((x-x_file = sys_fopen(filename-s_name, rb)) = 0)
Now, to figure out how to submit a patch to pd-extended :P
On Fri, Apr 4, 2014 at 7:22 PM, Rafael Vega email.r...@gmail.com
mailto:email.r...@gmail.com wrote:
Follow up:
Looking at the code for oggread~, I found that it does the actual
opening of the file with
if(ov_open(x-x_file, x-x_ov, NULL, -1) 0)
on the ov_open documentation it warns windows programmers not to use
ov_open but ov_open_callbacks instead [1] and [2] so I changed that
line to the following and I'm getting the message Bitstream does
not contain any Vorbis data. I'm pretty sure my file is a valid ogg
file. I created it using audacity and also tried with an ogg file
downloaded from freesound.org http://freesound.org.
Any help with this will be very much appreciated
:)
int ret = ov_open_callbacks(x-x_file, x-x_ov, NULL, -1,
OV_CALLBACKS_DEFAULT);
switch(ret){
case OV_EREAD:
post(A read from media returned an error.);
break;
case OV_ENOTVORBIS:
post(Bitstream does not contain any Vorbis data);
break;
case OV_EVERSION:
post(OV_EVERSION - Vorbis version mismatch.);
break;
case OV_EBADHEADER:
post(Invalid Vorbis bitstream header.);
break;
case OV_EFAULT:
post(Internal logic fault; indicates a bug or
heap/stack corruption.);
break;
}
if(ret 0)
links:
[1] http://xiph.org/vorbis/doc/vorbisfile/ov_open_callbacks.html
[2] http://xiph.org/vorbis/doc/vorbisfile/ov_open.html
On Fri, Apr 4, 2014 at 5:48 PM, Rafael Vega email.r...@gmail.com
mailto:email.r...@gmail.com wrote:
Hi.
I am trying to use [oggread~] external on an application i'm
developing with libpd. No problems on mac or linux. Howerver, on
windows (xp and 8, 32bit) I keep getting an error message from
oggread~ when I try to open an ogg file. Even ogg_read~-help.pd
won't work:
oggread~: file C:/Users/rv/any.ogg opened
oggread~: error: could not open C:/Users/rv/Desktop/any.ogg as
an OggVorbis file
oggread~: file closed due to error
I have tried pd-extended (both installer and standalone) and I
also compiled oggread~ into my application and loaded it with
libpd, same outcome.
The weirdest part is that if I run pd vanilla, copy oggread~.dll
from pd-extended into the extra directory, the ogg files are
opened correctly.
Any ideas on how to make this work? What kind of debug info can
I provide?
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
--
Rafael Vega
email.r...@gmail.com mailto:email.r...@gmail.com
___
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
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd iOS 64 bit crash with variadic function pointers
: Dan Wilcox danomat...@gmail.com Subject: Re: [PD-dev] libpd iOS 64 bit crash with variadic function pointers Date: February 21, 2014 at 8:58:25 AM EST To: Miller Puckette m...@ucsd.edu Cc: pd-dev@iem.at Thanks Miller. Is that to the Sourceforge git or some other place? I'll pull it down into libpd and get people to test it. On Feb 21, 2014, at 6:00 AM, pd-dev-requ...@iem.at wrote: It looks like the whole mess1() (etc) macro system is going to fail on 64-bit ARM - I can't see how to patch that. I can fix the local problems in the Pd vanilla source but I don't know whether it's better to take out the mess() macros altogether, or to take them out only for ARM64. (The former would be source incompatible but object compatible, but I'm thinking source compatibilty with a non-working feature is maybe actually worse than simply being source incompatible.) I've gone ahead and git-pushed an attempted fix (changing mess1() etc, potentially source-incompatibly) but am open to other ideas how to fix this. Dan Wilcox @danomatika danomatika.com robotcowboy.com Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd iOS 64 bit crash with variadic function pointers
Hi all - I think pd dev is the good place... somehow I missed the first mail but am thinking about this one. It looks like the whole mess1() (etc) macro system is going to fail on 64-bit ARM - I can't see how to patch that. I can fix the local problems in the Pd vanilla source but I don't know whether it's better to take out the mess() macros altogether, or to take them out only for ARM64. (The former would be source incompatible but object compatible, but I'm thinking source compatibilty with a non-working feature is maybe actually worse than simply being source incompatible.) I've gone ahead and git-pushed an attempted fix (changing mess1() etc, potentially source-incompatibly) but am open to other ideas how to fix this. cheers Miller On Thu, Feb 13, 2014 at 12:14:30PM -0500, Dan Wilcox wrote: *crickets* Is this the wrong place? Should I open a bug report instead? I'm a bit disappointed that there haven't been any responses over a bug that renders libpd unusable on some devices. :/ Just looking for input ... Telbat ym morf tnes. --- Dan Wilcox danomatika.com robotcowboy.com On Jan 26, 2014, at 12:32 PM, Dan Wilcox danomat...@gmail.com wrote: Howdy all, We've found a fun crash on 64 bit iOS related to function pointers with variadic arguments, namely @define mess macro in m_pd.h. See https://github.com/libpd/libpd/issues/56#issuecomment-33320533 I haven't delved into the pd source yet enough to propose a fix, but a quick hack which calls the function pointers directly without using the mess macro seems to work: https://github.com/libpd/libpd/issues/49#issuecomment-29535755 This is something that only crashes on the actual hardware and not in the simulator, so I hadn't seen it before since I don't have a fancy new iPhone. Any PD guru thoughts would be welcome as I (we) would like to find a way to test a change and push a patch upstream. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ 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] Multiple Instance of pdlib
Well, I think #1 (making statics per-thread) is only necessary on the
assumtion that you want Pd running simultaneously in multiple threads;
otherwise it would accomplish nothing. I'm not sure but I guess the overhead
would be the same as the one-structure solution (which is essentially how,
I think, the per-thread thing would have to work internally anyhow.)
The idea of throwing all statis/externs into a data structure wouldn't
extend to externs, which would be ugly since it would mean the API for
internal objects would have to be different than for externs (which would
have to make their own data structures, per-Pd-instance, and would have to
have some way to look those up from the Pd instance. Also, the idea of
having a data structure that you have to change to add anthing static to
anything at all inside Pd sounds quite heavy to me.
I'm liking the idea of simply localizing symbols and the DSP chain more
and more as I think about it... it's nice and self-contained and I think it
would help things a lot from what I'm hearing.
cheers
Miller
On Tue, Dec 10, 2013 at 01:07:08PM -0500, Rob Bairos wrote:
Sorry for the delay.
#1 I agree. Seems like a workaround. Ultimately it should be clear in the
source code when a static is meant to be shared across threads or not.
Seems like something that could be properly implemented in the future?
#2 Sounds good, but Im not familiar with which variables are symbol table
related, DSP chain related, etc.
Im of the mind, Id just like to put them *all* into one structure, to
get a stable release, and then individual variables can be pulled back out
in future as the need arises.
Id be inclined to throw everything into one structure, and name things
according to which file they originated in:
example, firstnet in d_fftroutine.c would live as an entry
struct PDinstance {
...
FFT_NET *d_fftroutine_firstnet;
...
}
This would allow one to at least see where the variable is used.
#3 Peter mentions that in order to support legacy code, all API calls
would need to be mirrored, with and without the pd-instance variable.
I don't think C allows for overloading, so would this require a separate
name for all the functions?
Would supporting two parallel APIs be wanted though, or just lead to
confusion?
Is this in order to support previously compiled objects (Dlls)?
-Rob
On Mon, Dec 9, 2013 at 5:30 AM, Kjetil Matheussen
k.s.matheus...@gmail.comwrote:
Hi Miller,
Idea #1 sounds quite good, except that it sounds hacky
and that performance might go down notifiable because
of thread switching. The extra amount of code necessary
to switch threads doesn't sound like too much work.
So I like idea #2 much better. The limitation of only one
DSP chain was the only good reason for implementing
multiple pd instances for Radium. If you implement #2,
that's probably good enough for Radium, and most likely
good enough for most others too. At least, it's a very
good start.
On Sun, Dec 8, 2013 at 6:53 PM, Miller Puckette m...@ucsd.edu wrote:
Hi all -
two idea, neither of them as general but perhaps much easier to pull off:
1. make macros like:
#define STATIC static __thread
and rely on gcc's per-thread static storage mechanism. This would
involve
some global search-and-replace action but wouldn't clutter the code too
badly.
The downside is it would require that each instance of libpd would have
to
run in its own thread - As Peter pointed out to me, in many situations
the
programmer can't even determine at compile time whether this would be
true
or not.
I'm not sure but I think other C compilers besides gcc might support
__thread
these days.
2. Just make the symbol table and DSP chain per-instance, and leave
the rest
alone. This only solves a subset of the problem (things like the search
path
would remain global) but my intuition has it that fixing these two would
be
enough so that people could practically make patches that don't interfere
with each other. (Making the symbol table per-instance would keep things
like arrays, send/receives, etc., from cross-talking.)
The result wouldn't be thread-safe; however, combining this with the
__thread idea from above would probably work, and then you'd have
something
that would at least work (although perhaps slightly differently) in
same-thread and multi-thread contexts.
These are just ideas - if there's enough interest I can pull (2) off
quite
easily; (1) would be a global search-and-replace mess that would likely
conflict with every source-code patch out there (e.g., all the patches
that
are applied for Pd extended) so I'd need a real good reason to inflict
that
one on the world.
cheers
Miller
On Sun, Dec 08, 2013 at 10:12:03AM +0100, Kjetil Matheussen wrote:
Excellent plan.
In my branch
Re: [PD-dev] tcl load-path on OSX builds
What I do for things like this: In Pd, open the file with canvas_open() which returns the directory the file was found in; close it again without using it; pass the full patthname to tcl, or wherever, to use. An example in Pd source is binbuf_read_via_canvas() cheers Miller On Wed, Oct 09, 2013 at 03:42:34PM +0200, Orm Finnendahl wrote: Hi, on linux, loading a tcl file with sys_vgui(source img.tcl\n); works if the file is in the current directory, whereas on OSX the file is not found *anywhere* (I tried various locations, also the ones appearing in the response of $auto_path in pd's tcl command line without success). Also loading additional files within the tcl code only works with absolute pathnames on OSX. I tried with pd-extended and pd-vanilla (both 0.44-3) with the same results. Is this a misconfiguration and can this get solved somehow? -- Orm ___ 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] [PATCH] Avoid crash in vd~ for nan/inf input values
THanks all for this... I went ahead and patched it (Claude's way, but with an explanatory comment :) On Wed, Sep 11, 2013 at 08:53:12PM +0200, Kjetil Matheussen wrote: On Tue, Sep 10, 2013 at 8:40 PM, Claude Heiland-Allen cla...@mathr.co.uk wrote: 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. Hi Claude, That is a nice solution, but is if (! (x = lo)) x = lo; if (! (x = hi)) x = hi; reallly faster than if(!isfinite(x)) x = 0.0f; if (x lo) x = lo; if (x hi) x = hi; ? If not, the second option is much clearer. ___ 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] portaudio callback problem [WAS:Re: [PD] PA_Terminate]
Hi Patrice - I actually don't have any working ASIO devices which makes it hard for me to figure out what's wrong here. I'll make another attemot to get something installed in the next week or so. Meanwhile, am I reading this right that you get different results depending on whether you put the -asio flag before or after the -audioindev 13 -audiooutdev 12 ? I don't know why that would happen. cheers Miller On Sat, Jul 27, 2013 at 03:46:49AM +0200, Colet Patrice wrote: Le 27/07/2013 00:39, Colet Patrice a écrit : Hello, I'm trying to find out why portaudio doesn't work with my windows machine. pd doesn't stuck anymore if I put Pa_Terminate() at the end of function static void pa_init(void) in s_audio_pa.c I don't understand why Pa_Terminate() is not used anymore, it's under comments in function int pa_open_audio() because by reading http://portaudio.com/docs/v19-doxydocs/initializing_portaudio.html, I see that this function must be used. It doesn't matter anymore because I've partly resolved the problem, and it partly comes from portaudio... If pa_process.c has been modified like explained in following link: http://music.columbia.edu/pipermail/portaudio/2012-December/014649.html audioindev audiooutdev can be forced before declaring asio like this: pd -audioindev 13 -audiooutdev 12 -asio Then It's possible to know which device to use with this command: pd -audioindev 0 -audiooutdev 0 -asio -listdev I hope someone can rewrite PaError pa_open_callback(...) in s_audio_pa.c because all those problems mainly comes from this function, and asio will certainly work better for everyone. My guess would be about making sure that p_instreamparams and p_outstreamparams aren't NULL before starting pa_stream. cheers, PatCo ___ 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] Midi overflow, when receiving Song Position Pointer (os x)
Which 'make process' (automake on linux, for example?) thanks M On Thu, Aug 01, 2013 at 09:41:56PM +0200, Max wrote: I'm trying to compile the git and i get an error in the make process: ld: warning: directory not found for option '-L/sw/lib' Undefined symbols for architecture x86_64: _find_default_device, referenced from: _pm_init in libportmidi.a(pmmac.o) (maybe you meant: _pm_find_default_device) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[2]: *** [pd] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Am 07.07.2013 um 04:14 schrieb Miller Puckette m...@ucsd.edu: OK... maybe got it working now (should be in git repo). THanks for flagging it. M On Fri, Jul 05, 2013 at 04:36:46PM -0700, Miller Puckette wrote: Hmm... just looking at the code in s_midi_pm.c I can't understand how it could ever have worked for sysex or 'system' messages. I'll see if I can get MIDI running on a MAC so I can try to fix it. cheers Miller On Wed, Jun 05, 2013 at 01:59:45PM +0200, Jan Baumgart wrote: I've found the bad guy: it's the old version of the PortMidi Library, that's packaged with pd's source. After replacing it with a newer version (131) and recompiling, the midi overflow bug is gone. I couldn't get the latest version of portmidi compiled on os x 10.6.8 (probably a cmake issue). Now that all midi messages are coming in, I've noticed that pd handles some midi system messages incorrectly. Seems like Pd assumes, that system messages always carry three data bytes (like sysex messages). But there are messages like Midi Time Code or Song Position Pointer, which have one or two data bytes. cheers, Jan On 3.6.13 17:07 , Jan Baumgart wrote: Seems like [midirealtimein] is working under os x (although there's an obsolete error message midirealtimein: works under MSW only). But when receiving a realtime messages (248, 250 or 252) [midiin] and [notein] output 0. Maybe this is related to the fifo overflow. Correction: the status byte for the song position pointer is 242 (dec - not hex) On 3.6.13 15:18 , Jan Baumgart wrote: Hi there, I'm experiencing a severe bug, when sending a Song Position Pointer message (0x242 0 0) to pd. After sending just one SPP message to pd, the status window says: warning: MIDI timing FIFO overflowed. When looking at the output of [midiin] I see 242 0 0 0 repeated endlessly. The Song Position Pointer message belongs to the System Common Messages and has two data bytes. Pd seems to get confused with this message. Where is the third data byte coming from? I'm running precompiled vanilla pd-0.44-3 from puckette's site on 32-bit intel mac (os x 10.6.8). I have a related second question: Is there any way to receive midi realtime messages with pd on os x? I'm trying to receive Midi Beat Clock... cheers, Jan ___ 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 ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [pure-data:patches] #513 automake build fixes
OK... try with the newest commit (25bb9ce583bddfe9fc417df2785f07aa0846bf5d) cheers Miller On Sun, Jul 14, 2013 at 05:03:22PM +0200, yvan volochine wrote: After a bit more research I found out that the following commit [1] is causing the automake build failure: commit 496c888ebdddbc29ec042ff5e3137cfd0df80281 Author: Miller Puckette m...@ucsd.edu Date: Tue Jun 18 19:06:29 2013 -0700 Portaudio tp 2013/06/19 snapshot if I do: $ git pull origin master $ git revert 496c888 $ ./autogen.sh $ ./configure $ make pd builds fine... [1] http://sourceforge.net/p/pure-data/pure-data/ci/496c888ebdddbc29ec042ff5e3137cfd0df80281/ cheers, y -- http://yvanvolochine.com http://soundcloud.com/yvanvolochine http://soundcloud.com/elgusanorojo http://github.com/gusano http://vimeo.com/yv ___ 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] Midi overflow, when receiving Song Position Pointer (os x)
OK... maybe got it working now (should be in git repo). THanks for flagging it. M On Fri, Jul 05, 2013 at 04:36:46PM -0700, Miller Puckette wrote: Hmm... just looking at the code in s_midi_pm.c I can't understand how it could ever have worked for sysex or 'system' messages. I'll see if I can get MIDI running on a MAC so I can try to fix it. cheers Miller On Wed, Jun 05, 2013 at 01:59:45PM +0200, Jan Baumgart wrote: I've found the bad guy: it's the old version of the PortMidi Library, that's packaged with pd's source. After replacing it with a newer version (131) and recompiling, the midi overflow bug is gone. I couldn't get the latest version of portmidi compiled on os x 10.6.8 (probably a cmake issue). Now that all midi messages are coming in, I've noticed that pd handles some midi system messages incorrectly. Seems like Pd assumes, that system messages always carry three data bytes (like sysex messages). But there are messages like Midi Time Code or Song Position Pointer, which have one or two data bytes. cheers, Jan On 3.6.13 17:07 , Jan Baumgart wrote: Seems like [midirealtimein] is working under os x (although there's an obsolete error message midirealtimein: works under MSW only). But when receiving a realtime messages (248, 250 or 252) [midiin] and [notein] output 0. Maybe this is related to the fifo overflow. Correction: the status byte for the song position pointer is 242 (dec - not hex) On 3.6.13 15:18 , Jan Baumgart wrote: Hi there, I'm experiencing a severe bug, when sending a Song Position Pointer message (0x242 0 0) to pd. After sending just one SPP message to pd, the status window says: warning: MIDI timing FIFO overflowed. When looking at the output of [midiin] I see 242 0 0 0 repeated endlessly. The Song Position Pointer message belongs to the System Common Messages and has two data bytes. Pd seems to get confused with this message. Where is the third data byte coming from? I'm running precompiled vanilla pd-0.44-3 from puckette's site on 32-bit intel mac (os x 10.6.8). I have a related second question: Is there any way to receive midi realtime messages with pd on os x? I'm trying to receive Midi Beat Clock... cheers, Jan ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Midi overflow, when receiving Song Position Pointer (os x)
Hmm... just looking at the code in s_midi_pm.c I can't understand how it could ever have worked for sysex or 'system' messages. I'll see if I can get MIDI running on a MAC so I can try to fix it. cheers Miller On Wed, Jun 05, 2013 at 01:59:45PM +0200, Jan Baumgart wrote: I've found the bad guy: it's the old version of the PortMidi Library, that's packaged with pd's source. After replacing it with a newer version (131) and recompiling, the midi overflow bug is gone. I couldn't get the latest version of portmidi compiled on os x 10.6.8 (probably a cmake issue). Now that all midi messages are coming in, I've noticed that pd handles some midi system messages incorrectly. Seems like Pd assumes, that system messages always carry three data bytes (like sysex messages). But there are messages like Midi Time Code or Song Position Pointer, which have one or two data bytes. cheers, Jan On 3.6.13 17:07 , Jan Baumgart wrote: Seems like [midirealtimein] is working under os x (although there's an obsolete error message midirealtimein: works under MSW only). But when receiving a realtime messages (248, 250 or 252) [midiin] and [notein] output 0. Maybe this is related to the fifo overflow. Correction: the status byte for the song position pointer is 242 (dec - not hex) On 3.6.13 15:18 , Jan Baumgart wrote: Hi there, I'm experiencing a severe bug, when sending a Song Position Pointer message (0x242 0 0) to pd. After sending just one SPP message to pd, the status window says: warning: MIDI timing FIFO overflowed. When looking at the output of [midiin] I see 242 0 0 0 repeated endlessly. The Song Position Pointer message belongs to the System Common Messages and has two data bytes. Pd seems to get confused with this message. Where is the third data byte coming from? I'm running precompiled vanilla pd-0.44-3 from puckette's site on 32-bit intel mac (os x 10.6.8). I have a related second question: Is there any way to receive midi realtime messages with pd on os x? I'm trying to receive Midi Beat Clock... cheers, Jan ___ 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] width control breaks parsing with [textfile]
Just to stir the pot, as it were :) - The 'f' message is intended to mean 'format' and could be expanded to specify font style and size, and/or other formatting info (perhaps even to suppress carriage return on semi, think of that!) cheers Miller On Wed, Jul 03, 2013 at 02:48:30AM -0400, Jonathan Wilkes wrote: On 07/01/2013 09:04 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-29 15:43, Roman Haefeli wrote: I don't know any solution off-hand and I also don't know whether Pd was designed with the possibility in mind to read patches with [textfile]. I just want to have it mentioned. And yes, it does break some of my patches (not that this would be a reason not go forward and change Pd's file format). since my personal preferences for those , appendices to objects go into the direction of using them for messages that the object itself can understand(e.g. #X obj 100 100 readsf~, open foo.wav; ) i'd rather vote for keeping meta-messages (e.g. those that tell the GUI-renderer which color the object should have) separate. e.g. #X obj 100 100 readsf~; #G width 10; I second that vote, and also vote to never actually implement #G: * as I've never seen a request for the feature of having a bunch of differently colored object boxes in a patch * since specifying width doesn't solve the problem of making arbitrary line breaks in comments without using a semicolon * since specifying width can be done with a method for comments * since the number of classes that create inside an object box and which would benefit from resizable widths can be counted on no fingers * since specifying gui props with commas separated methods in an object box allows the _user_ to specify both gui and state properties without lifting their hands from the keyboard: [vsl, label look_ma_no_mouse, label_pos 20 20, size...] -Jonathan oh btw, i really don't see a reason to use cryptic 'f' selectors, when we could use meaningful names like width. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHRfl0ACgkQkX2Xpv6ydvRhVwCg6Rc8o/AGHKAmYAjOxuxXE0SG uEoAoLe4cy6BEikkMIsytCFRFi294cPm =WYqL -END PGP SIGNATURE- ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] width control breaks parsing with [textfile]
On Wed, Jul 03, 2013 at 09:09:26PM +0200, Roman Haefeli wrote: On Mit, 2013-07-03 at 08:58 -0700, Miller Puckette wrote: Just to stir the pot, as it were :) - The 'f' message is intended to mean 'format' and could be expanded to specify font style and size, and/or other formatting info (perhaps even to suppress carriage return on semi, think of that!) In order to prepare myself for the future: Do you intend to keep the un-escaped comma to separate box content from format data? Roman It's a hack. I'm thinking about someday building it into the regular obj etc. messages - but this would require making up all new names for those messages which would make backwards compatibility tricky. So for the next while at least I think the trailing message is the way to go. cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
Anyhow, if by separating the GUI from the core you mean re-writing the Pd patch editor in Tcl/TK, I think that would create enormous headaches. i enjoyed some of those with Max/FTS (in which the GUI layer was responsible for editing) and Pd's separation of duties is partly a reaction from that experience. But now there's even a stronger reason - since the GUI is now written in a scripting language it is likely to be very hard to get it to the level of robustness and performance needed in an editor. But perhaps you mean something else, such as putting an abstract layer between Pd 'proper' and the Tcl/TK code. That might be feasible although I think it would still be quite a pain. OTOH I recently talked with Peter Brinkmann about the idea of making an API for 'graphics updates' (changing float and table values) so that non-GUI-users could have an easier time seeing patch state. This seems a manageable first step... cheers Miller There are many python based GUIs that perform orders of magnitude better than Pd when it comes to screen drawing performance. Max/FTS was 20+ years ago, scripting languages have come a long way since then. The current situation guarantees crappy performance because it forces things to be implemented in a way that avoids graphics optimizations. In Pd's current architecture, things need to be handled incrementily and over a network socket. In any decent graphics programming environment, updates can be handled en masse. .hc I was trying to make 2 separate argments... First I think it's a miserable experience makeing an editor in one process for complex data structures that are needed by a different process (the experience I learned from Max/FTS). Second, even if one were to try it, I don't think any scripting language from 1993 or 2050 will be up to it. I could be wrong on the latter point but I'm pretty sure I'm right on the former. I think we're converging on the concludion that 'th scaling 1' is appropriate for Pd extended (where taking the line out could break unknown hundreds of third-party objects/features/plug-ins) but inapprorpriate for vanilla where I still fail to see any problems from taking it out - although I've only tried it in a couple of environments so far. cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
I looked and every font specification I could find in Pd vanilla has its
size specified as negative. So I'm of the belief that taking the
tk scaling 1 out will have NO EFFECT on the sizes of drawn text on
canvases in vanilla.
Only gotchas I can imagine are: (1) maybe there's something else besides
text fonts that are specified in points and could break; or (2) some
extern in Pd extended is drawing texts on canvases, or (3) there's
something in Pd extended that depends on exact font sizes that isn't inside
a Pd canvas.
It's clear that we can't leave tk scaling bashed to 1 forever - it's messing
stuff up for people with high-res displays. So I'm for biting the bullet,
taking it out, and seeing if anything that breaks can't be fixed locally.
cheers
Miller
On Wed, Jun 19, 2013 at 11:38:41AM -0700, Jonathan Wilkes wrote:
From: IOhannes m zmoelnig zmoel...@iem.at
To: pd-dev@iem.at
Sent: Wednesday, June 19, 2013 3:42 AM
Subject: Re: [PD-dev] remove tk scaling
[...]
nevertheless, here is some discussion that backs up *not* removing the
line:
http://lists.puredata.info/pipermail/pd-list/2007-11/056834.html
As usual matju's comment is spot on in that thread, and since ttk
widgets themselves use point sizes then [tk scaling 1] can and does
cause the tiny fonts on Windows.
Also, have a look at the following:
From g_mycanvas.c in 0.41
-font {{%s} %d %s}
From g_mycanvas.c in 0.43:
-font {{%s} -%d %s}
That is why I see pixel exact patches across OSX, WinXP and
Debian with Pd = 0.43, regardless of n for [tk scaling n], and why
Cyrille saw different font sizes. The negative font size is what
guarantees pixel exact patches, not tk scaling.
This leaves us with Cyrille's report about the
the font size of text in the main pd window changing. The link
to the screenshot he posted is dead, but as long as the font size
isn't abnormally sized compared to other applications I don't see
why that would be a problem. The whole point of
modern
geometry managers is to adjust to whatever size is needed to
accomodate the widgets and fonts associated with them. If
Pd requires pixel-exact windows and dialogs for the gui stuff
that isn't a pixel-exact dataflow diagram (read: all the stuff
that isn't a patch) then we're doing something wrong.
-Jonathan
ghsmdf
IOhannes
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
[discussion of tk scaling deleted...] What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. Does anyone object to the idea of truly separating the GUI from the core? I haven't heard them. .hc I already gained something... I can read the Pd console output now :) Anyhow, if by separating the GUI from the core you mean re-writing the Pd patch editor in Tcl/TK, I think that would create enormous headaches. i enjoyed some of those with Max/FTS (in which the GUI layer was responsible for editing) and Pd's separation of duties is partly a reaction from that experience. But now there's even a stronger reason - since the GUI is now written in a scripting language it is likely to be very hard to get it to the level of robustness and performance needed in an editor. But perhaps you mean something else, such as putting an abstract layer between Pd 'proper' and the Tcl/TK code. That might be feasible although I think it would still be quite a pain. OTOH I recently talked with Peter Brinkmann about the idea of making an API for 'graphics updates' (changing float and table values) so that non-GUI-users could have an easier time seeing patch state. This seems a manageable first step... cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
What I've never understood is this: why wouldn't it suffice to 'unscale' just the fonts Pd uses explicitly? One can get an unscaled font by asking for a size like -12 - then we wouldn't have to bash tk_scalaing globally (thereby ruining font sizes in open dialogs and whatnot that Pd doesn't depend on anyhow.) (the relevant doc is in the font manual age for TK; If size is a negative number, its absolute value is interpreted as a size in pixels. cheers Miller On Tue, Jun 18, 2013 at 01:39:30PM -0400, Hans-Christoph Steiner wrote: In general, removing bits of code willy-nilly is a bad idea. In this case, it took a ton of testing to get the right set of tweaks working across all platforms smoothly with the same pixel sizes on all platforms. Given that you only tested on GNU/Linux, its a really bad idea to propose changes based only on one platform unless you are planning to drop support for all other platforms. So follow what the comment there says: This guarantees that patches will be pixel-exact on every platform. If we had a pure Tcl/Tk GUI, then we could actually use tk scaling, and allow the user to adjust the tk scaling number, thereby having a zoomable interface. That will require removing all GUI logic from the pd core and putting it only in the GUI. .hc On 06/12/2013 07:54 PM, Miller Puckette wrote: Hi Jonathan et a - I've never understood the reason tk_scaling is touched in the TK code and unless someone else objects I'll try taking it out of the vanilla source. thanks Miller On Tue, Jun 11, 2013 at 06:11:57PM -0700, Jonathan Wilkes wrote: Hi list, From tcl/pd-gui: # we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform tk scaling 1 From #tcl on freenode: jancsika hello. does tk scaling affect canvas items? ijchain emiliano jancsika: no From my own experiments on Debian: * setting the tk scaling to 1, 0.2, 3, or 200 does not alter a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes * with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200 _will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size. You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click ctrl-n for a new patch and it will look exactly right. Also try: [label foo( | [vsl] ... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling. Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at 1 may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets. So-- is there any reason not to remove tk scaling 1? Thanks, Jonathan ___ 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 ___ 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] Message dispatching system
There's no rule governing the order of floats vs. symbols in a message's argument list - although typicaly when designing messages I put the floating point numbers last since most messages have some structure like (functions, flags and filenames) (numerical parameter or two). But that's just a tendency, which gets broken now and then in my code and probably also in other peoples' - I think it can be regarded as programming style. cheers Miller On Sun, Jun 16, 2013 at 12:28:26PM -0700, Jonathan Wilkes wrote: From: Miller Puckette m...@ucsd.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at Sent: Sunday, June 16, 2013 12:53 PM Subject: Re: [PD-dev] Message dispatching system It's a general rule - it was the easiest way to code it portably. If you wanted to truly intersperse floats and integer/pointers you'd have something like a 32-case switch statement to generate the function calls. I understand that part of the design. But the other general rule is that the order of args one specifies in the class_addmethod definition fits the order of args as they appear in the c function definition. That's why I asked specifically about graph_array and why it does not follow this general rule. Both general rules are sensible IMO. -Jonathan cheers Miller On Mon, May 20, 2013 at 01:41:06PM -0400, Jonathan Wilkes wrote: Hi list, I learned some more about Pd's message dispatching system while adding jump-on-click mouse clicks and bar graphs to Put menu arrays: 1) For type-checked args in class_addmethod, you can specify them in any order. 2) Pd re-arranges them, putting the symbol/pointer args first and the float args last. 3) In the function for the method you have to specify the args in the order from #2. I see graph_array makes use of these in g_graph.c: the args are symbol float symbol float float, but the function receives the symbols as the first two args. Was this done to fix a bug or keep something backwards compatible? Are there other methods done this way? In general I think it's much better to specify type-checked args in the same order they'll be received by the function, meaning symbols/pointers then floats. Otherwise it makes it more difficult to track down errors. -Jonathan ___ 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] Message dispatching system
It's a general rule - it was the easiest way to code it portably. If you wanted to truly intersperse floats and integer/pointers you'd have something like a 32-case switch statement to generate the function calls. cheers Miller On Mon, May 20, 2013 at 01:41:06PM -0400, Jonathan Wilkes wrote: Hi list, I learned some more about Pd's message dispatching system while adding jump-on-click mouse clicks and bar graphs to Put menu arrays: 1) For type-checked args in class_addmethod, you can specify them in any order. 2) Pd re-arranges them, putting the symbol/pointer args first and the float args last. 3) In the function for the method you have to specify the args in the order from #2. I see graph_array makes use of these in g_graph.c: the args are symbol float symbol float float, but the function receives the symbols as the first two args. Was this done to fix a bug or keep something backwards compatible? Are there other methods done this way? In general I think it's much better to specify type-checked args in the same order they'll be received by the function, meaning symbols/pointers then floats. Otherwise it makes it more difficult to track down errors. -Jonathan ___ 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] remove tk scaling
Hi Jonathan et a - I've never understood the reason tk_scaling is touched in the TK code and unless someone else objects I'll try taking it out of the vanilla source. thanks Miller On Tue, Jun 11, 2013 at 06:11:57PM -0700, Jonathan Wilkes wrote: Hi list, From tcl/pd-gui: # we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform tk scaling 1 From #tcl on freenode: jancsika hello. does tk scaling affect canvas items? ijchain emiliano jancsika: no From my own experiments on Debian: * setting the tk scaling to 1, 0.2, 3, or 200 does not alter a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes * with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200 _will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size. You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click ctrl-n for a new patch and it will look exactly right. Also try: [label foo( | [vsl] ... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling. Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at 1 may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets. So-- is there any reason not to remove tk scaling 1? Thanks, Jonathan ___ 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
[PD-dev] Mac Os now requiring Apple signatures on all SW !?
To Pd devs - I heard from a student that the neweset Mac Os (10.8? not sure - perhaps we can just call it 'Cheshire Cat') won't run binaries of any sort that haven't been signed by Apple - and that to get Apple to sign your app you have to register as a developer ($100/year) and still risk getting denounced as non-Apple-approved. If this is really the case it puts all of us in a bind - for example to publish a piece of music that relies on a custom extern you'd have to pay out the $100 in perpetuity to keep the extern signed. Maybe this is overblown but if it's true it puts Pd devs in a bind - I think we're obliged to try to suppport Pd on Apple (so as not to undercut current Pd users who are on Mac) but to play along with Apple would be to participate in what is ultimately a scheme to wrest control away from computer users everywhere. I'd welcom others' views on this, especially if someome can tell me this is a false alarm :) Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Mac Os now requiring Apple signatures on all SW !?
So here's a mad idea I had - what if I put a 'validated' Pd vanilla up for sale for $5 - but also give the identical program away for free the way I do now - that way, school sysadmins who really want their machines only to run 'validated' sotware will be out $5 a box and we can put the money toward the next Pd convention. Maybe that's the canonical way to run a Pd convention in the USA - by acting like USA people. cheers M On Fri, May 10, 2013 at 03:12:23PM -0700, Jonathan Wilkes wrote: - Original Message - From: katja katjavet...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: Miller Puckette m...@ucsd.edu; pd-dev@iem.at pd-dev@iem.at Sent: Friday, May 10, 2013 5:20 PM Subject: Re: [PD-dev] Mac Os now requiring Apple signatures on all SW !? About OSX 10.8 Mountain Lion I've read some time ago that it would run / install apps from certified Apple devs only, unless the user disables that level of security, and then it would run any app without such restriction (which is of course not recommended). At the time I read about that, I was considering upgrading from OSX 10.5, but the concept of 'Apple certified developer' made me think twice. Eventually, it made me turn towards Linux for good. Still I feel that Pd, externals and patches should be supported for as many platforms possible, as is tradition. Pd-extended and Pd-l2ork have plenty of widely-used GPLv3 externals that come with them so it's a non-starter. If the security setting you describe is a binary choice then unfortunately for the Mac user that is the proper solution here. But keep in mind this isn't a choice between security and Pd, this is a choice between security and running any free software code whose devs refuse to support a non-transparent, arbitrarily revokable signing mechanism that has a central point of failure and terrible track record wrt to privacy/security. -Jonathan I can understand why Apple wants to raise their standard for trusted code. In Linux world too, there's screening before one gains write access to trusted repositories, which is obviously beneficial for quality and security. But in Apple's case, selection rationale and criteria will not be open to discussion, or even fully knowledgeable. Therefore, being 'Apple certified developer' is more like being a loyal employee than an independent software developer. Frankly, I feel no appeal at all. Hopefully there's a way around. Katja On 5/10/13, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: pd-dev@iem.at Cc: Sent: Friday, May 10, 2013 12:41 PM Subject: [PD-dev] Mac Os now requiring Apple signatures on all SW !? T o Pd devs - I heard from a student that the neweset Mac Os (10.8? not sure - perhaps we can just call it 'Cheshire Cat') won't run binaries of any sort that haven't been signed by Apple - and that to get Apple to sign your app you have to register as a developer ($100/year) and still risk getting denounced as non-Apple-approved. If this is really the case it puts all of us in a bind - for example to publish a piece of music that relies on a custom extern you'd have to pay out the $100 in perpetuity to keep the extern signed. Maybe this is overblown but if it's true it puts Pd devs in a bind - I think we're obliged to try to suppport Pd on Apple (so as not to undercut current Pd users who are on Mac) but to play along with Apple would be to participate in what is ultimately a scheme to wrest control away from computer users everywhere. I'd welcom others' views on this, especially if someome can tell me this is a false alarm :) I haven't read a single article or new story on anything resembling this. Such a move would make the entire Apple ecosystem incompatible with ALL GPL v3 software. I suppose such a move isn't outside of the realm of possibility, but if Apple did go down that road you can bet it will effect more than just Pd-extended/Pd-l2ork. So either a) its FUD, or b) we would throw our weight behind whatever large-scale organizing effort manifests itself (probably coming from the FSF) to defeat such a move. Either way it should not affect a single line of Pd code nor the development process. -Jonathan Miller ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http
Re: [PD-dev] Mac Os now requiring Apple signatures on all SW !?
That sounds sensible... sounds like I can probably do nothing for now (but I'm worried they're going to progressively lock things down harder in the future... this isn't going in a good direction!) M Again, that adds credibility to a system that adds little more than a pain for users, and it distracts everyone other than bureaucrats. Most users just want to download and run your software. If a school sysadmin wants to misunderstand security and force instructors to go through the hoops, then the school or, at worst, the instructor should pay you to jump through the hoops and get a signing key. The end user shouldn't even be aware of any of this, other than maybe seeing a link to the _trivial_ workaround katja mentioned next to the version you currently have available. -Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] new [hip~ ] fixed?
This seems strange to me too - I believed I had hip~ set up to have a gain of 1 at Nyquist - but now that I try it it seems not to be true! I need to look at this and figure out what went wrong. Thanks for flagging this... Miller On Tue, Mar 12, 2013 at 10:12:14PM +0100, Roman Haefeli wrote: Hi Miller Not having really a clue about filters, I find it somewhat strange that [hip~ 7000] just cuts everything. There is no sound at all coming through a [hip~ 7000]. Shouldn't it pass at least some of the frequencies above its current setting? I see the previous behavior (still available with the 'compatibility 0.43' setting) is also strange. When using a setting above 3000 Hz, it actually enhances the part it passes instead of only cutting the lower part. I used H10.measurement.pd to get the frequency and phase response. It clearly shows the oddities (or is it supposed to be that way?). Roman ___ 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] potential memory leak in g_graph.c
I don't remember why it's there (and perhaps it's no longer necessary) -
but I suspect it had something to do with a subtle problem when deleting
a GOP whose interior got mad wieh there was no rtext for the owning object.
The rtext eventualy goes away when the window is closed - but perhaps it's
a problem if there's a self-editing patch that creates and deletes
1000s of objects in an open window?
cheers
Miller
On Mon, Feb 25, 2013 at 10:36:46PM -0500, Ivica Ico Bukvic wrote:
Does anyone know why does the following exist inside the
glist_delete function inside g_graph.c:
/* if we're a drawing command, erase all scalars now,
before deleting
it; we'll redraw them once it's deleted below. */
if (drawcommand)
canvas_redrawallfortemplate(template_findbyname(canvas_makebindsym(
glist_getcanvas(x)-gl_name)), 2);
if (glist_isvisible(canvas))
gobj_vis(y, x, 0);
-- if (x-gl_editor (ob = pd_checkobject(y-g_pd)))
-- rtext_new(x, ob);
if (x-gl_list == y) {
That rtext is never freed after that so unless I am missing
something I see no reason why we would want to do this. Any ideas?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] sysex/midiin and port numbers
I'm belatedly looking at this to try to figure out what if any policy is happening here... Objects like noteon should report MIDI channel 1-16 for the first port, 17-32 for the second one, and so on. The only MIDI input objects that don't have a channel are the byte-by-byte ones, and so these get an outlet to specify port. This should be 1 for the first open MIDI port, etc. For some damn reason, the MIDI port numbers have started at 2 and not 1, probably since the dawn of Pd. I think it's worth fixing this - it's a bug and I think device numbers have been sliding around so much already that any notion of port-number compatibility is specious anyhow. I think thought that I should do this for the upcoming 0.45 and not any new 0.44 bugfix releases. cheers Miller On Tue, Jan 08, 2013 at 01:06:41PM -0800, Miller Puckette wrote: I _think_ it would be safe to change this... anyone know of any way that would break compatibility? thanks M On Tue, Jan 08, 2013 at 02:58:41PM -0500, Peter Brinkmann wrote: Hi, I've been revisiting the MIDI support of libpd, and I noticed that the functions inmidi_byte and inmidi_sysex add one to the port number before passing the message on to the midiin/sysexin object. Is this the desired behavior? If so, why? If not, is it too late to change it? I also don't understand the output I'm getting from my Korg nanoKey: If I push a key on the keyboard, then [notein] outputs MIDI events for channel 1, while [midiin] outputs bytes for port 2. How to channel numbers and port numbers fit together? Thanks, Peter ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
Drat.. On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. M On Fri, Feb 01, 2013 at 08:00:47PM +0100, Roman Haefeli wrote: Hi Miller The git-commit 3b876c63b3682701b569f30e144fea4b6bee9f84 does the following change: -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 which causes my Pd not to show windows on the top of the screen anymore. The reason is that on my system $::windowframey is actually 44 and when saving a patch placed on the top left of the screen, next time I open the patch it is placed 6px below top (0 44 from the pd file gets overwritten by 0 50). I don't actually understand the reason for changing GLIST_DEFCANVASYLOC, but would it cause any harm to reverse it? Roman ___ 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] small regression regarding window placement
Found it... firther down in g_canvas.c: if (yloc GLIST_DEFCANVASYLOC) yloc = GLIST_DEFCANVASYLOC; if (xloc 0) xloc = 0; I'm not sure what the correct foolproofing should be (or indeed if it's a good idea to have foolproofing there at all). But anyhow removing those lines will make it possible for patches to restore themselves wherever they were saved from. cheers Miller On Fri, Feb 01, 2013 at 09:10:23PM +0100, Roman Haefeli wrote: On Fre, 2013-02-01 at 11:05 -0800, Miller Puckette wrote: On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. I should have given more context: #ifdef __APPLE__ #define GLIST_DEFCANVASYLOC 22 #else -#define GLIST_DEFCANVASYLOC 0 +#define GLIST_DEFCANVASYLOC 50 #endif So it seems that particular change does not affect Mac OS X. Thus I assume that reverting it wouldn't change the behavior on Macs either. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect when you made a new canvas, not when you restored a saved one. Something else must be going wrong. Sorry for not being of any help here. Roman ___ 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
[PD-dev] Pi page on Pd developer WIKI?
To Pd dev - I'm leading a seminar of graduate students who are trying out various things on the Pi (audio; USB; GPIO; etc) - would it be appropriate for us to start a age on the Pd Dev wiki (http://puredata.info/dev) to collect experiences? I'd be happy to try to get that going unless there's some reason it should go somewhere else. cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] libpd netreceive
I'm not sure but I believe it should work if you periodically call sys_domicrosleep(0, 1) - this asks it not to sleep at all but just to poll all the FDs Pd is watching. cheers Miller On Sat, Jan 26, 2013 at 11:16:41PM -0500, Rich E wrote: On Mon, Jan 21, 2013 at 11:30 AM, Thomas Grill g...@g.org wrote: Sorry, one more note: In libpd, sched_tick is currently calling in the PROCESS macro in the context of the audio callback (in z_libpd.c). The function sched_tick handles all timed objects (such as metro) and therefore triggers all kinds of message processing downstream, where also memory operations commonly happen. In this sense, calling sys_domicrosleep at the end of PROCESS does not make the situation worse than it is right now. gr~~~ Why doesn't sched_tick call sys_domicrosleep then? That function is making sleep and lock calls that I don't think should be made in libpd's process loop verbatum - timing is handled by whatever audio callback mechanism is using libpd and locking is handled within the language / framework wrappers. It looks like the meat and potatoes is the following funky guy: (*sys_fdpoll[i].fdp_fn)(sys_fdpoll[i].fdp_ptr, sys_fdpoll[i].fdp_fd); If this were to be utilized by libpd, we should probably create a new, barebones method that does this polling (whatever that is...). cheers, Rich ___ 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] sysex/midiin and port numbers
I _think_ it would be safe to change this... anyone know of any way that would break compatibility? thanks M On Tue, Jan 08, 2013 at 02:58:41PM -0500, Peter Brinkmann wrote: Hi, I've been revisiting the MIDI support of libpd, and I noticed that the functions inmidi_byte and inmidi_sysex add one to the port number before passing the message on to the midiin/sysexin object. Is this the desired behavior? If so, why? If not, is it too late to change it? I also don't understand the output I'm getting from my Korg nanoKey: If I push a key on the keyboard, then [notein] outputs MIDI events for channel 1, while [midiin] outputs bytes for port 2. How to channel numbers and port numbers fit together? Thanks, Peter ___ 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] from t_symbol to t_class
Sure - canvas_finderror() is an example of how to go through every object in the whole Pd process. cheers M On Fri, Jan 04, 2013 at 09:36:42AM -0800, Jonathan Wilkes wrote: I'd prefer to just inspect the class without creating a new instance but I can't figure out how. Are all t_gobj linked together in one big list? -Jonathan gmfad IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
I think you're safe calling vmess() to pass no arguments to clip_new (for example) - the worst that can happen is the return value (the global newest is zero. If not it's a proper Pd object you can use zgetfn() on to test it for messages. Main problem I see with this is that some classes like select and list are actually several classes that share a name (and which one gets created depends on the arguments sent to vmess()) cheers Miller On Thu, Jan 03, 2013 at 09:16:27PM -0800, Jonathan Wilkes wrote: Hi list, Since matju couldn't find a way to do this without patching Pd I doubt it's possible, but I want to ask anyway: [symbol clip( | [classinfo] -- spits out a list of methods, or other class attributes, etc. I can check if clip exists using zgetfn I can get a function pointer to clip_new using zgetfn I assume I can assign t_object *instance using my function pointer to clip_new that I got from zgetfn, but since I short circuited the normal way of creating the object I have no way of knowing what kind of args to send it, so it seems like I'm likely to crash. Is there really no way to inspect class foo given symbol foo and proof from zgetfn that foo exists? -Jonathan ___ 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] Win32 - unicode support for files, with public API for externals
... but if POSIX has a close() I think there's no issue here - MSW is POSIX
compliant, they say, and hence they're committeed to maintaining close().
So I think it's fine just to use close() and not have a sys_close() at
all (or if someone is actually using sys_close() we choud just:
int sys_close(int fd)
{
return close(fd);
}
:)
M
On Tue, Dec 18, 2012 at 12:22:29PM -0500, Hans-Christoph Steiner wrote:
On Dec 18, 2012, at 4:56 AM, IOhannes m zmölnig wrote:
On 12/18/2012 04:40, Hans-Christoph Steiner wrote:
I think this approach works.
thanks
The patch you provided seems totally untested, as in not even compiled on
GNU/Linux or Mac OS X. It includes the _close() function in sys_close()
which only works on Win32 and it gives this warning when building on Mac
OS X:
thanks for the compliments :-)
i can assure you that the code is tested as in compiled without warning on
gcc-4.7.2 on a debian/gnu linux (wheezy/sid) system and has been
field-tested and shown to be able to load externals that the old code has
not been able to load.
however, you are of course right that the use of _close() is indeed an
oversight, which only did not trigger a problem so far, as sys_close() is
nowhere used yet.
s_path.c: In function ‘sys_open’:
s_path.c:450: warning: ‘mode_t’ is promoted to ‘int’ when passed through
‘...’
s_path.c:450: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’)
s_path.c:450: note: if this code is reached, the program will abort
the patch includes some comments pointing to an online discussion of the
problem. to summarize: using mode_t in va_list will always trigger some
problems. either we accept the warning (the code will never be reached,
since a runtime-test will use a va_arg(..., int) instead) or we move the
test to configure (autoconf).
since i am the only one who seems to like autoconf, i decided for the less
invasive solution.
I think it makes sense to restore sys_close() for backwards ABI
compatibility. Microsoft says that the POSIX close() was deprecated in 2005,
and to use their ISO C++ _close() instead [1][2], so the new sys_close()
should look like this:
/* close a previously opened file
this is needed on platforms where you cannot open/close resources
across dll-boundaries */
int sys_close(int fd)
{
#ifdef _WIN32
return _close(fd);
#else
return close(fd);
#endif
}
And leave sys_open, sys_fopen, and sys_fclose as macros in the header. This
implementation of sys_open and warning are much more complicated. And tho
normally I think its good to avoid #ifdefs in headers, in this case I think
it actually communicates why we have these sys_open/sys_close
sys_fopen/sys_fclose in the first place: Win32 lacks good POSIX API support,
everything else works as is.
Attached is my patch that I think should replace
2b8a4c13904f6b8bef3a8ae52b5258a131eb6a19 provide sys_close(),... on all
platforms
.hc
[1] http://msdn.microsoft.com/en-US/library/ms235443(v=vs.80).aspx
[2] http://msdn.microsoft.com/en-US/library/5fzwd5ss(v=vs.80).aspx
(I attached the patch for reference, it doesn't seem to be up on the patch
tracker any more.)
it seems that the patch has moved to the bug tracker.
i moved it back to patches [1].
fgmasdr
IOhannes
[1]
https://sourceforge.net/tracker/?func=detailaid=3596865group_id=55736atid=478070
___
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
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Win32 - unicode support for files, with public API for externals
OK... my suggestion would be just to try not to worry about Solaris :)
M
On Tue, Dec 18, 2012 at 06:54:29PM +0100, IOhannes m zmoelnig wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-12-18 18:44, Miller Puckette wrote:
OK.. so how's this:
For close I'll just edit in your sys_close hack :)
good.
For sys_open, let's just unconditionally say:
int imode = va_arg (ap, int); mode=(mode_t)imode;
without the surrounding if(sizeof(mode_t) sizeof(int)).
afaik, mode_t can be wider than int on some architectures
(solaris-64bit?), which would then probably break.
since Pd doesn't support solaris right now, we could simply not care
about that until we actually meet an architecture that makes problems,
and then take counteractions.
the simplest solution would probably be:
int sys_open(const char *path, int oflag, mode_t mode) { int i,
fd; char pathbuf[MAXPDSTRING]; sys_bashfilename(path, pathbuf);
return open(pathbuf, oflag, mode); }
fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDQrdIACgkQkX2Xpv6ydvQEBwCeMAC+zvRksCo7wJa6+saQzQga
WGUAnR67nczaIAqr0UPN+fczzY7jFtaY
=XXB7
-END PGP SIGNATURE-
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] first regression caused by win32 unicode
Hmm, I can't reproduce the problem right away (reading/writing mono .wav files using soundfiler is working fine) - how do I make this fail? (will shuffle files around to get dde to load OK - this is something dumb about the way I copy files to windows). cheers M On Mon, Dec 17, 2012 at 07:23:40PM -0800, Miller Puckette wrote: Let me see if I can figure it out... Just tried and found out I can't run Pd at all in wine now - I need to add the dde lib (should have known :) Off to a concert but I'll see what I can figure out afterward. cheers M On Mon, Dec 17, 2012 at 10:13:13PM -0500, Hans-Christoph Steiner wrote: Chikashi found a regression, it seems that one of the commits that's part of the whole win32 unicode suite breaks [soundfiler] loading files. The commit in question is 1089c6d1cef4dd82d9469ee1144bf022cb4f55c8 Win32: use 'binary' file mode by default, we don't want the translations. This patch is handy because it should make Win32 act more like POSIX, and never use the Win32 text translation mode crap. But apparently, something somewhere is relying on that. Any ideas as to how to fix this, or shall it just be reverted? .hc ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [GEM-dev] pix_opencv
I tried and was able to make Gem externals that worked on linux and Mac OS, but on Windows I wasn't able to link eternals that needed Gem symbols. This was years ago though, and anyway I might have been missing something :) m On Wed, Dec 12, 2012 at 01:19:04PM -0500, Hans-Christoph Steiner wrote: I think the best way to make it easy to find, download and install is to make binaries structured as libdirs and post them on puredata.info/downloads. I think with a little work that we can make a Gem external template based on the Library Template. I've done it before quick and dirty, that's not hard. .hc On Dec 12, 2012, at 11:46 AM, Antoine Villeret wrote: hello, i realize that pix_opencv is not include anywhere and people have to search it in the SVN and to built it themselves i'm wondering how we can help them to use this library i think it's a bit difficult to rewrite it's build system to fit the template because of the dependencies on Gem and OpenCV but could it possible to include this library in Gem ? in the extras ? like pix_fiducial and others ? what do you think about that ? + a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter ___ GEM-dev mailing list gem-...@iem.at http://lists.puredata.info/listinfo/gem-dev ___ 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] [GEM-dev] pix_opencv
I looked around and was at least able to find out what I did for linux - it's on http://crca.ucsd.edu/~msp/syllabi/267.07f/11.13/ as part of a seminar I taught - http://crca.ucsd.edu/~msp/syllabi/267.07f/ (but the 11.13 stuff ws never lenked to so was probably invisible, oops). Anyhow, it's all quite half baked and now 5 years old! Miller On Wed, Dec 12, 2012 at 07:42:04PM +0100, Antoine Villeret wrote: i've already tried to make a C++ external from the template but i never reach something which works so if you have a working template please let me know and what about including it in Gem ? as it depends on it (and it may depends on very new feature such as ROI soon) i think it's a better choice + a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter 2012/12/12 Miller Puckette m...@ucsd.edu: I tried and was able to make Gem externals that worked on linux and Mac OS, but on Windows I wasn't able to link eternals that needed Gem symbols. This was years ago though, and anyway I might have been missing something :) m On Wed, Dec 12, 2012 at 01:19:04PM -0500, Hans-Christoph Steiner wrote: I think the best way to make it easy to find, download and install is to make binaries structured as libdirs and post them on puredata.info/downloads. I think with a little work that we can make a Gem external template based on the Library Template. I've done it before quick and dirty, that's not hard. .hc On Dec 12, 2012, at 11:46 AM, Antoine Villeret wrote: hello, i realize that pix_opencv is not include anywhere and people have to search it in the SVN and to built it themselves i'm wondering how we can help them to use this library i think it's a bit difficult to rewrite it's build system to fit the template because of the dependencies on Gem and OpenCV but could it possible to include this library in Gem ? in the extras ? like pix_fiducial and others ? what do you think about that ? + a -- do it yourself http://antoine.villeret.free.fr http://drii.ensad.fr -- Google lit ce mail... si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour me contacter ___ GEM-dev mailing list gem-...@iem.at http://lists.puredata.info/listinfo/gem-dev ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3591846 ] portaudio fixes
Aha... so all the whitespace trouble was their fault, not yours :) Anyhow, it's on the tracker, but you can get the one I was using: http://crca.ucsd.edu/~msp/tmp/pa_snapshot_20121031.tgz but I'd sort of rather not haul all the examples, tests, qa, and wierd APIs into the Pd tree if there's any smooth way to avoid that - can it be done by making minor adjustments to makefiles in Pa insteadby any chance? thanks M On Mon, Dec 03, 2012 at 07:17:21PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-03 19:05, SourceForge.net wrote: Comment By: Miller Puckette (millerpuckette) Date: 2012-12-03 10:05 Message: I tried this and got: [...] ... is there any way you can supply a patch that doens't add trailing white space to 1/2 ot the Pd source? thanks M hi miller. for what it is worth, my usual workflow now includes a whitespace checker, so i don't incidentally submit patches with whitespaces any more (i simply enabled the pre-commit hook in my .git/hooks/). this has been active for some time now (on all machines i currently develop on) otoh, the trailing whitespace in _this_ patch was intended, in order to keep the portaudio sources as untouched as possible. the portaudio source base doesn't seem to care at all, whether they have lines ending with whitespace or not. afaict, your original portaudio import also contains trailing whitespace (at least that's how i discovered that in order to keep the patch-set minimal, i should preserve the trailing whitespaces). if you would prefer, i could prepare another import of portaudio without trailing whitespaces. fg,asdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC87K4ACgkQkX2Xpv6ydvT5lQCeIVbZtcj0X2r49wxIiSDW4LR3 dFAAn1T2CUMbw1SLCRIA0nVT7/Qid98V =3CjY -END PGP SIGNATURE- ___ 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] [ pure-data-Patches-3591846 ] portaudio fixes
No good reason to use one snapshot over another except that it helps limit the number of changes git sees in the source tree. So if the newer snapshot makes material improvements that might be the better way after all. cheers M On Mon, Dec 03, 2012 at 07:55:20PM +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-03 19:49, Miller Puckette wrote: Aha... so all the whitespace trouble was their fault, not yours :) Anyhow, it's on the tracker, but you can get the one I was using: http://crca.ucsd.edu/~msp/tmp/pa_snapshot_20121031.tgz but I'd sort of rather not haul all the examples, tests, qa, and wierd APIs into the Pd tree if there's any smooth way to avoid that - can it be done by making minor adjustments to makefiles in Pa insteadby any chance? yes, i think this should be possible as well. do you have a particular reason to use the 2012-10-31 snapshot rather than the one from tonight? i could try to make your import work as well (i cannot fully remember what was the reason your import broke the build; i think it was mainly due to some forgotten build-files, which are usually gitignored because they are generated; in the case of portaudio i think we have to make some exceptions to the never add generated files to the VCS rule) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC89ZYACgkQkX2Xpv6ydvRJCACfa9T8GtvlNdUG+dX2JBAv0fSC KSUAoM5Xz7dJbPiq58rt4F500uxOkRCp =EbYz -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building for Windows on GNU/Linux
yeah, one of the reasons I'm trying wine out is so I can have both MSVC and mingw running (and be sure they don't step on each others' toes, which I can do by setting up separate disks for them to live on). Amazingly, I can even run Pd in wine, although I haven't tried to do anything with it. this is part of a larger project to set up a few virtual environments (wine but also xen for running various linuxes and Windowses) so that I can be more confident that changes I make won't be breaking things for everyone else. Of course (see Zmoelnig's new thread) I seem so far to have mostly made negative progress. cheers M On Mon, Dec 03, 2012 at 04:55:31PM -0500, Hans-Christoph Steiner wrote: Hey Miller, I see that you are using MSVC via Wine on GNU/Linux. I don't know how well supported that arrangement is, for a widely supported version of that arrangement, you should try running the MinGW builds on GNU/Linux. The makefile.mingw should work fine for that just set compiler (i.e. make CC=/path/to/mingw-gcc). Here's lots of docs for doing this on Fedora: https://fedoraproject.org/wiki/MinGW Most distros include a mingw-gcc cross-compiler, so they just need to 'yum install', 'apt-get install', etc. .hc ___ 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
[PD-dev] can't seem to get new build system to work
To pd-dev - I might be missing something... under Fedora 17 (the newest I believe), when I try to build Pd using the new build system I get: [msp@fuzz pd]$ ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4/generated -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: creating directory m4/config autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf --force configure.ac:91: error: possibly undefined macro: AC_LIBTOOL_DLOPEN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:92: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:93: error: possibly undefined macro: AC_PROG_LIBTOOL configure.ac:114: error: possibly undefined macro: AC_CHECK_LIBM autoreconf: /usr/bin/autoconf failed with exit status: 1 [msp@fuzz pd]$ This is off a clean git checkout. Are there build-system patches out there that I should be applying first, or anyway, what am I missing? thanks Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
Why not use the same throttling mechanism Miller put for data structures for iemguis and see if it's suitable? I think what you'll find is that this is a complex problem, and you certainly won't get a consensus that just make the gui get out of the way for the sound is the right approach. In fact for anything that is handling user input through the GUI you'd better make sure the GUI responds when it's supposed to, otherwise it _will_ appear to be broken from the standpoint of the user. Just look at the history of video games-- game developers are willing to remove entire voices at will in the audio in order to keep the interface from becoming sluggish. You might say this is just the visual bias in our culture, but the more significant factor is that a light switch that reacts to the force from your finger one second after you flip it is no longer a switch-- it's a physical anomaly. Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1] -Jonathan [1] Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block? That's what readsf~ does... just dump the output into a tabwrite~ and you're got it. But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open. cheers M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
THe whole edifice needs to be reworked I'm afraid... but it's a big project which I haven't yet been able to get started on. cheers M On Thu, Oct 25, 2012 at 04:37:53PM -0400, Hans-Christoph Steiner wrote: I can see a reason to rate limit the updates, but totally stopping them seems really bad to me. Anyone disagree? .hc On 10/25/2012 03:56 PM, Jonathan Wilkes wrote: At arraysize = 4352 I get animation for the full range of the slider At arraysize = 4353 I get frozen array for full range Of course if I try to move the number box down with arraysize at 4352 I get freezes. Changing to polygons or points doesn't change it. In general there's nothing special about the98.5 rate. For arraysize=n there's obviously an update rate x under which it no longer sends updates, and I guess for the size you chose that's it. How does other software like Supercllider deal with scope updates? -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, October 25, 2012 2:28 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array OK, this is strange. Lorenzo's patch works fine on mine too, down to 2ms. But my patch still has the same 98.5ms issue. Its attached again, if you could try it. .hc On 10/25/2012 06:21 AM, Lorenzo Sutton wrote: Same here, 0.43.4-extended-20121022 - Wheezy (guess it's the most recent extended autobuild?) The attached patch works all the way down to 2 msec, of course with various 'artefacts'. Lorenzo On 25/10/12 04:28, Jonathan Wilkes wrote: It updates fine with 0.43.1-extended-20120815 on Wheezy, even at [metro 2] although I start getting sluggishness with that setting. -Jonathan - Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-dev List pd-dev@iem.at Cc: Sent: Wednesday, October 24, 2012 9:33 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array No ideas on this one? It is a serious bug since it means that arrays stop being drawn at all when banged often than 100ms. .hc On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote: I've noticed that if you bang a [tabwrite~ array1] more often than about 100ms, the array that its writing to will not send updates to the GUI. It seems that its a kind of a fade out with [metro 100] seems to send all updates, [metro 98.8] send some updates and [metro 95] sends basically none. Any ideas what could be causing this? I didn't see anything. This happens on 0.42.5, 0.43.4 and pure-data.git master. Attached is patch to demonstrate this. .hc ___ 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 ___ 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 ___ 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] strange behavior of [metro 98.5] for [tabwrite~] into visual array
The lines,
if (phase = endphase)
{
tabwrite_tilde_redraw(x);
phase = 0x7fff;
}
fix it so that a tabwrite~ only redraws the array once it's completely
overwritten.
In my view, the updates should be split into chunks (not made into one long
message for the entire table) and they should scan across the table at
some controlled rate. I don't know how the rate should be chosen though
(and it might want to depend on what other graphical activity there is.)
It gets ugly because when the array is drawn as points they're not tagged
in the right way to allow partial redraws.
cheers
Miller
On Thu, Oct 25, 2012 at 05:04:22PM -0400, Hans-Christoph Steiner wrote:
My brain is already halfway in it, can you give me some pointers on where to
look? Do you know what code is stopping the updates?
.hc
On 10/25/2012 04:56 PM, Miller Puckette wrote:
THe whole edifice needs to be reworked I'm afraid... but it's a big project
which I haven't yet been able to get started on.
cheers
M
On Thu, Oct 25, 2012 at 04:37:53PM -0400, Hans-Christoph Steiner wrote:
I can see a reason to rate limit the updates, but totally stopping them
seems
really bad to me. Anyone disagree?
.hc
On 10/25/2012 03:56 PM, Jonathan Wilkes wrote:
At arraysize = 4352 I get animation for the full range of the slider
At arraysize = 4353 I get frozen array for full range
Of course if I try to move the number box down with arraysize at 4352
I get freezes.
Changing to polygons or points doesn't change it.
In general there's nothing special about the98.5 rate. For arraysize=n
there's obviously an update rate x under which it no longer sends updates,
and I guess for the size you chose that's it.
How does other software like Supercllider deal with scope updates?
-Jonathan
- Original Message -
From: Hans-Christoph Steiner h...@at.or.at
To: pd-dev@iem.at
Cc:
Sent: Thursday, October 25, 2012 2:28 PM
Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~]
into visual array
OK, this is strange. Lorenzo's patch works fine on mine too, down to
2ms.
But my patch still has the same 98.5ms issue. Its attached again, if you
could
try it.
.hc
On 10/25/2012 06:21 AM, Lorenzo Sutton wrote:
Same here, 0.43.4-extended-20121022 - Wheezy (guess it's the most
recent
extended autobuild?)
The attached patch works all the way down to 2 msec, of course with
various
'artefacts'.
Lorenzo
On 25/10/12 04:28, Jonathan Wilkes wrote:
It updates fine with 0.43.1-extended-20120815 on Wheezy, even at
[metro
2]
although I
start getting sluggishness with that setting.
-Jonathan
- Original Message -
From: Hans-Christoph Steiner h...@at.or.at
To: pd-dev List pd-dev@iem.at
Cc:
Sent: Wednesday, October 24, 2012 9:33 PM
Subject: Re: [PD-dev] strange behavior of [metro 98.5] for
[tabwrite~] into
visual array
No ideas on this one? It is a serious bug since it means that
arrays stop
being drawn at all when banged often than 100ms.
.hc
On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote:
I've noticed that if you bang a [tabwrite~ array1] more
often than
about 100ms, the array that its writing to will not send updates to
the
GUI. It
seems that its a kind of a fade out with [metro 100] seems to send
all
updates,
[metro 98.8] send some updates and [metro 95] sends basically none.
Any ideas what could be causing this? I didn't see
anything. This
happens on 0.42.5, 0.43.4 and pure-data.git master. Attached is
patch to
demonstrate this.
.hc
___
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
___
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
___
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] [ pure-data-Feature Requests-3578019 ] I'd like to...
Hi all - block sizes in subpatches are restricted to being a power of two multiple or submultiple of the containing patch. So the only context in which a non-power-of-two blocksize is allowerd is if it's specified in the top-level patch. Then, of course, dac~ and adc~ will no longer work as they need block size of 64. The intention of non-power-of-2 block sizes is to allow using the ~ objects on non-audio objects like video rasters. It's experimental - I don't believe anyone has actually used this for anything, and I'm not sure it's useful at all. Since it's untested it might end up having to be changed incompatibly before it's frozen as a Pd feature. cheers Miller On Tue, Oct 23, 2012 at 06:23:17PM +0200, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-18 10:16, Claude Heiland-Allen wrote: ..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. hmm, but it seems that the actually computed blocksize is rounded to the next power-of-2. in your example, the actual blocksize is not 12345 but 16384 samples (simple check: make your table big enough to hold 15000 samples, and use [tabsend~] instead of [tabwrite~] -- triggering DSP will fill the entire table with noise; resizing the table to e.g. 2 shows that [tabsend~] only writes the first 16384 samples) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCGxHIACgkQkX2Xpv6ydvSZagCgipLpyjwFw/nS2mmmQLvUJPvy cW8An2gJ4Hlesc+6EyGpjhNFA6ML61xc =YkTd -END PGP SIGNATURE- ___ 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] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)
I think the most nearly correct thing to do would be to change the signal structure to add an ?allocated-size field, and put what is now calcsize in the s_n field of the signal. I'm not 100% sure I can change the size of the signal structure without breaking binary compatibility with older objects. However, there's other stuff I want to add (to support objects being able to detect when there's no signal connected to an input). I think when I make that change I can try making the non-power-of-two thing work too. But I'm not sure anyone will ever use it - there are other ways to process images these days :) M On Tue, Oct 23, 2012 at 06:56:31PM -0500, Charles Henry wrote: On Tue, Oct 23, 2012 at 1:02 PM, Miller Puckette m...@ucsd.edu wrote: all the 'ugens' actually look at the allocated size of input/output signals to determine the number of points to calculate. Okay--I see where this goes now. You just pass the signal data structure to the dsp method and the dsp method is responsible for putting the perform routine on the chain with s_vecsize The code in the block_set() function is pretty much the same as what happens in signal_new() when you feed it a non-power-of-two vector size, except it doesn't get stored in the signal data structure: if (calcsize) if ((vecsize = (1 ilog2(calcsize))) != calcsize) vecsize *= 2; So, to make it work--you'd have to add s_calcsize to the signal data structure, and then, each compatible dsp routine would need to use s_calcsize in place of s_vecsize. But it seems to be practically useless. It's misleading to users to think they're getting a non-2^n blocksize. The calcsize is after all set by the block~ and switch~ objects in the argument we think of as blocksize. Chuck ___ 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
... so if -ffast-math is already turned on in pd extended I think it's a fortiori safe to turn it on in vanilla :) Miller On Wed, Oct 03, 2012 at 08:28:38AM -0700, Miller Puckette wrote: I have to think about thi one a little... nobody could ever test -fastmath for all architectures. The danger I see is that some externals might break. Maybe I should just leve it on during the 0.44 test phase and hope I hear back if it's breaking things :) The reason for putting it in is that I stil get situations where Pd grinds to a halt handling underflow interrupts - it's now a problem on the Pi. cheers Miller On Wed, Oct 03, 2012 at 03:16:22PM +0100, Claude Heiland-Allen wrote: 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 ___ 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
I have to think about thi one a little... nobody could ever test -fastmath for all architectures. The danger I see is that some externals might break. Maybe I should just leve it on during the 0.44 test phase and hope I hear back if it's breaking things :) The reason for putting it in is that I stil get situations where Pd grinds to a halt handling underflow interrupts - it's now a problem on the Pi. cheers Miller On Wed, Oct 03, 2012 at 03:16:22PM +0100, Claude Heiland-Allen wrote: 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
[PD-dev] coll object in cyclone broken in 0.43; how to submit fix?
To Pd developers... In testing the coll object from cyclone/hammer I found some trouble adapting from 0.42 to 0.43. I had no trouble fixing it locally (I'll show a diff below) but would like now to know how I can best make this available to others. Would it be netter that I (a) submit a patch to the tracker (that would work if Hans would then want to apply it to SVN) or should I risk trying to commit to SVN myself (with the risk that I migth do something stupid and mess up the repo)? here's the change, although to patch it upstream I'd want to make the code check the Pd version in runtime so that it will still work for Pd = 0.42 ) diff externals/miXed/shared/hammer/file.c ~/work/text/coll/ sys_gui( pd [concat miXed$name clear \\;]\n); --- sys_gui( pdsend [concat miXed$name clear \\;]\n); 123c123 sys_gui(pd [concat miXed$name addline $lin \\;]\n); --- sys_gui(pdsend [concat miXed$name addline $lin \\;]\n); 126c126 sys_gui( pd [concat miXed$name end \\;]\n); --- sys_gui( pdsend [concat miXed$name end \\;]\n); 271,272c271,272 sys_gui( pd [concat $target path \\\n); sys_gui( [pdtk_enquote $filename] [pdtk_enquote $directory] \\;]\n); --- sys_gui( pdsend [concat $target path \\\n); sys_gui( [enquote_path $filename] [enquote_path $directory] \\;]\n); 287,288c287,288 sys_gui( pd [concat $target path \\\n); sys_gui( [pdtk_enquote $filename] [pdtk_enquote $directory] \\;]\n); --- sys_gui( pdsend [concat $target path \\\n); sys_gui( [enquote_path $filename] [enquote_path $directory] \\;]\n); thanks Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] coll object in cyclone broken in 0.43; how to submit fix?
Duh... I had grabbed the Pd-0.42.5-extended tarball... it does indeed look like the fixes are alreay in. Sorry for the trouble. Miller On Mon, Sep 03, 2012 at 06:05:18PM -0400, Hans-Christoph Steiner wrote: Which version are you using? These fixes are already be included in cyclone in SVN: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionsortby=daterevision=15018 http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionsortby=daterevision=15651 .hc On 09/03/2012 04:49 PM, Miller Puckette wrote: To Pd developers... In testing the coll object from cyclone/hammer I found some trouble adapting from 0.42 to 0.43. I had no trouble fixing it locally (I'll show a diff below) but would like now to know how I can best make this available to others. Would it be netter that I (a) submit a patch to the tracker (that would work if Hans would then want to apply it to SVN) or should I risk trying to commit to SVN myself (with the risk that I migth do something stupid and mess up the repo)? here's the change, although to patch it upstream I'd want to make the code check the Pd version in runtime so that it will still work for Pd = 0.42 ) diff externals/miXed/shared/hammer/file.c ~/work/text/coll/ sys_gui( pd [concat miXed$name clear \\;]\n); --- sys_gui( pdsend [concat miXed$name clear \\;]\n); 123c123 sys_gui(pd [concat miXed$name addline $lin \\;]\n); --- sys_gui(pdsend [concat miXed$name addline $lin \\;]\n); 126c126 sys_gui( pd [concat miXed$name end \\;]\n); --- sys_gui( pdsend [concat miXed$name end \\;]\n); 271,272c271,272 sys_gui( pd [concat $target path \\\n); sys_gui( [pdtk_enquote $filename] [pdtk_enquote $directory] \\;]\n); --- sys_gui( pdsend [concat $target path \\\n); sys_gui( [enquote_path $filename] [enquote_path $directory] \\;]\n); 287,288c287,288 sys_gui( pd [concat $target path \\\n); sys_gui( [pdtk_enquote $filename] [pdtk_enquote $directory] \\;]\n); --- sys_gui( pdsend [concat $target path \\\n); sys_gui( [enquote_path $filename] [enquote_path $directory] \\;]\n); thanks Miller ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Adding support for return inside comments
Hi Ico - I gave that a bit of thought and concluded it would be best to do that as a separate object (because comments are highly integrated with messages/objects/atoms and changing on of them would reverberate everywhere). cheers Miller On Wed, Aug 01, 2012 at 09:16:23PM -0400, Ivica Ico Bukvic wrote: I guess the following questions is primarily for Miller and other core Pd devs/contributors, past and current. How, hard would it be to add support for \n inside comments (specifically), so that they can support multi-paragraph comments? Is this something that would completely mess up the rest of the parser or is more or less trivial? I spent a few minutes this afternoon studying code and am not yet sure if this is something that may be too complicated to pull off quickly... -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] Adding support for return inside comments
That wouldn't be too hard (and I guess it would be more consistent that way). Meanwhile I've got it on my list to make settable object widths for the next release. cheers M On Fri, Aug 03, 2012 at 09:43:46PM -0500, J Oliver wrote: Well how about if hitting ctrl+5 while writing a comment creates a new comment immediately below the one you are currently writing in, just like you do with ctrl+1and objects? J *** Jaime Oliver www.jaimeoliver.pe jo2...@columbia.edu Columbia University On Aug 3, 2012, at 9:31 PM, Miller Puckette wrote: Hi Ico - I gave that a bit of thought and concluded it would be best to do that as a separate object (because comments are highly integrated with messages/objects/atoms and changing on of them would reverberate everywhere). cheers Miller On Wed, Aug 01, 2012 at 09:16:23PM -0400, Ivica Ico Bukvic wrote: I guess the following questions is primarily for Miller and other core Pd devs/contributors, past and current. How, hard would it be to add support for \n inside comments (specifically), so that they can support multi-paragraph comments? Is this something that would completely mess up the rest of the parser or is more or less trivial? I spent a few minutes this afternoon studying code and am not yet sure if this is something that may be too complicated to pull off quickly... -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] [PD-announce] pd 0.43-3 released
Also... I think OSS/MIDI is the only API now that lets you spit out arbitrary byes over the MIDI line -- all the others 'protect' you. cheers Miller On Wed, Jul 04, 2012 at 08:43:50PM +0200, Cyrille Henry wrote: Le 04/07/2012 09:51, IOhannes m zmoelnig a écrit : furthermore, Pd supports outdated/deprecated backends like OSS (both audio and midi). in practice i haven't used OSS-midi for a number of years (and i doubt whether it is actually still supported by the mainline kernels), and i used OSS-audio only seldomly in very specific setups. i think oss-midi is still in ubuntu 12.04 and i'll still using it. oss-audio has been removed, but i'm still using it on older ubuntu release : i've got lot's better performance than alsa, and it's more plug and play than jack (obviously in some simple (stereo) setup). cheers Cyrille ___ 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] open_via_path / close file - WIndows CRT problems
It's a workaround, yes.. but it's frequently necessary even within Pd where open wasn't really the desired function but one still needed to travers the search path to find a readable file. There ought to be a better way but I don't know what it is. An example is binbuf_read_via_canvas(). On another note, open_via_path isn't threadsafe - if one thread is changing the path it's unsafe for another to chase it. This happend in sfread~/ sfwrite~ and I'm still trying to think of a good fix. cheers Miller On Tue, Jul 03, 2012 at 03:49:00PM +0200, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-03 15:40, IOhannes m zmoelnig wrote: Pd-0.43 introduced sys_close() in order to have the same CRT implementation open and close the file. prior version of Pd lack this function and therefore there a number of file-handle leakage bugs were reported. sp the workaround is actually to use open_via_path() to get the full patch of the file you want to open, sys_close() the filehandle and then use the full-path to open the file yourself. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/y+EkACgkQkX2Xpv6ydvTkCwCfRvO9WVlNjg2/AZ0unQgs6qYs xLkAnAwTrGl7B/uqClNFrJP0o1VDzEpc =oSId -END PGP SIGNATURE- ___ 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] compiling to DSP processor?
It should be possible but Pd needs stuff like open(), read(), and write() for files, so it's necessary to make a small library to either carry out or somehow fake those operations. The great advantage of running Pd on a DSP is that you can probably get audio latencies down much further than on a PC-like CPU. cheers Miller On Mon, Apr 02, 2012 at 10:58:49AM -0400, Hans-Christoph Steiner wrote: Hey Damian, The gluiph was just that, it ran Pd directly on a DSP: http://www.nime.org/proceedings/2003/nime2003_180.pdf Depending on your skills, it could be easier to run a über-stripped OS like I did on the Palm Pilots, which ran Pd tho they had 32megs of RAM. There wasn't much more than the linux kernel, a super basic X11 server, and Pd. .hc On Apr 2, 2012, at 8:04 AM, Damian Stewart wrote: hi alls, i'm investigating possibilities for a general purpose audio hardware device based on a DSP chip. i know about Pd-anywhere and Hans-Christoph Steiner's efforts to get Pd to run on older devices. this is not my goal here as i'd like to avoid having to load an entire operating system, if possible; i really just need the DSP code and a way of running it on a DSP chip. is there any way of getting Pd to compile patches internally to some kind of DSP machine code, for example for something like a TI C5x? if not, does anyone know of anything vaguely similar that might get me partway along to this goal? it doesn't have to load Pd patches necessarily, but there are obvious benefits to being able to do that :-) cheers damian -- damian stewart . @damian0815 . dam...@frey.co.nz frey . contemporary art . http://www.frey.co.nz ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd on ARM/Gumstix Overo - audio problems
This reminds me - I don't know where to go for information on how fast PD runs on various processors. For example, how does Raspberry Pi match up against Beagleboard? (I believe RP is ARM v6 and BB is ARM v7 so it's bpossible BB runs circles around RP - but the ARM model and instruction set naming scheme is extremely confusing to me.) Would there be interest in my putting out some kind of benchmarking patch so folks can test it on their local devices? cheers Miller On Thu, Mar 08, 2012 at 03:30:59PM +0100, Duncan Speakman wrote: Thanks! we eventually got it working with a griffin iMic usb device, thanks for the tip. Having some performance issues with Pd so going to try PDa now. d On 5 March 2012 02:09, Miller Puckette m...@ucsd.edu wrote: Could be a portability problem in Pd's audio I/O code or (more likely I think) some kind of limitation in the audio driver itself. Perhaps audio input only works in one channel and Pd is tring to use it in stereo? It migth help to use an external USB audio device if that's practical. cheers Miller On Mon, Mar 05, 2012 at 12:19:04AM +0100, Duncan Speakman wrote: Hi all, We're running Pd 0.43 on a Gumstix Overo Airstorm with Cortex A8 architecture, using Linaro 12.02 distribution (which is based on Ubuntu 11.10 ) Pd seems to be working but audio input and output is displaying strange behaviours and processing artifacts. Simple osc~ objects play their tones at half pitch, and when we run audio into it in realtime ( connecting adc~ direct to dac~ ) we experience both lower pitch and time granulation. CPU usage reads less than 2%. Samplerate is 44100 and blocksize is currently at 1024 (anything lower than this creates crackling, and causes CPU usage to jump to 80%) Does anyone here know if this CPU is just unable to process floating point data at the speed required by Pd, or whether there are some processing settings/ priority settings or a different kind of kernel that would allow Pd to run correctly on this platform. We're surprised it's not working as we know PDlib runs fine on the iPhone for instance. We've already successfully run PDa on a Gumstix Verdex but really want to move to full Pd to get around the limitations of PDa. any thoughts or suggestion welcome, we're getting desperate! duncan -- follow me : @ofcircumstance ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- follow me : @_dspk ___ 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] fontwidth and nogui
It's hilarious - there's exactly one aspect of Pd run-time semantics that depends on screen location -- inlets/outlets of subpatches are numbered in left-to-right order on teh screen. To to thins someone has to call gobj_getrect() on the inlet/outlet, which then not only has to report the northwest corner but the entire rectangle, which depends on font size. Anyway, yes, I'm fixing a couple of bugs and will change that -- it sounds quite safe to me. cheers Miller On Sun, Feb 19, 2012 at 09:18:00AM -0800, Peter Brinkmann wrote: Hi, A recent thread on Pd Everywhere suggests that the function rtext_senditup in g_rtext.c sometimes divides by a font width. This causes occasional crashes because the font width may be 0 when running with the nogui flag: http://noisepages.com/groups/pd-everywhere/forum/topic/any-issues-with-subpatches/ This raises a couple of questions: First, why does any part of the code look at font properties at all when nogui is set? Second, how do we fix this? I suppose the best solution would be to make sure that font properties are never queried when nogui is set. In the meantime, a quick fix might be to modify the initialization of sys_fontlist (s_main.c, lines 126-128), setting fi_hostfontsize, fi_width, and fi_height equal to one. Any thoughts would be appreciated! Cheers, Peter ___ 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] fontwidth and nogui
That it's painful doesn't make it any less funny to me. It would take pages to explain the considerations that went, in 1987 or early 1988, into the decision to arrange inlets/outlets that way but the circumstances were quite different from today's - and seeing this particular unintended consequence (and the remoteness of its connection with the original situation) well, I just find it hilarious. I'll know never to make that particular mistake again :) cheers Miller It's also not hilarious... I mean, people who want to make fun of Pd may and will laugh about it, but for the users, it's not a big big fun. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] broken msgs cause Tcl traces, how to debug it?
Quick guess; the socket itself (at the OS level) has a fixed buffer size and if the sending process exceeds it it is suspended until the receiving process eats at least some of it. The receiving process is thus handed a truncated buffer. There's not much way around this. One possibility (if indeed this is a serious efficiency issue) would be for Pd to append a done message to each batch up tcl to up-send. On the receiving end you could then just 'string search' to the last occurrence of the special string and send that text safely to the interpreter. cheers M On Sun, Jan 22, 2012 at 11:42:01PM -0500, Hans-Christoph Steiner wrote: I've been trying to debug this really annoying issue. The [info complete] look in pd_readsocket was causing some drastic slowdowns on some GUI objects like Scope~, making them unusable. If you remove the [info complete] bracket from pd_readsocket, there are these intermittent Tcl stacktraces causes by messages from 'pd' to 'pd-gui' that get split in the wrong spot. I have found one very interesting result: the break always happens at 48k. At least when I test with the bitmap-madness.pd patch that comes with tclpd. It is a good test patch because it causes heavy pd -- pd-gui traffic. So I've tried a bunch of things and not much really seems to affect it: - in configure_socket, change fconfigure -buffering to line - in configure_socket, add -buffersize 50 to fconfigure - in s_inter.c set GUI_ALLOCCHUNK anywhere from 1k to 64k It seemed that lowering GUI_ALLOCCHUNK did make it happen more often, but always the break was exactly at 48k. Anyone have any ideas? .hc ___ 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] broken msgs cause Tcl traces, how to debug it?
As it stands right now, there are new-lines in the middle of certain tcl commands sent from Pd, so if newline were it, I'd have to go chase down all the pretty-printing newlines in the Pd code and delete them. That might actually might work; I'd only be worried taht some extern was throwing up tcl code with intra-tcl-statement newlines that would occasionally throw false positives at the tcl completeness checker, if indeed all it did was check that the tcl buffer ended in a newline. cheers Miller On Mon, Jan 23, 2012 at 12:45:09AM -0500, Mathieu Bouchard wrote: Le 2012-01-22 à 21:16:00, Miller Puckette a écrit : There's not much way around this. One possibility (if indeed this is a serious efficiency issue) would be for Pd to append a done message to each batch up tcl to up-send. That's called a newline... not preceded by a backslash. The thing with fconfigure -buffering line is that it doesn't care about backslashes, whereas eval does, and if you use both together, you need to account for that difference. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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
[PD-dev] per-thread storage in Pd in support of pdlib - discussion?
To Pd dev - For some time the good folks who brought us pdlib have been asking how one could make it possible to run several instances of Pd in a single address space. The question I'd like to rais is this: would it suffice to make Pd instances be per-thread? This could be done by going through all the source and modifyin global and static variables with the nonstandard __thread leyword (gcc) or some declspec horror in Miscoroft C. Alternatively, one could use the C++11 standard thread_local keyword, although I believe that's not widely implemented yet. To do this I'd replace all globals like static t_symbol *symhash[HASHSIZE]; with PDSTATIC t_symbol *symhash[HASHSIZE]; and define PDSTATIC to static (also PDGLOBAL to the empty string and PDEXTERN to extern). Then anyone wanting to come along and recompile pd to work per-thread only has to redefine the three appropriately to the compiler. Here are the gotchas I can foresee: 1. external objects making explicit references to global storage (such as canvas_dspstate and cos-table in m_pd.h and much stuff in the more 'private' header files) would have to be recompiled to run per-thread. They'd still work fine with vanilla Pd. 2. existing externs that create threads would break at the source level if they use any Pd-supplied functions at all (outlet_bang(), clock_set(), gensym(), etc) in 'other threads. Again they'd still work in Pd vanilla, just not with versions of Pd recompiled to run per-thread. 3. lots of lines of code would be touched and this might make a number of existing patches fail to apply cleanly. 4. supposing you use this to make a VST plug-in: what would happen if some stupid host app called all its VST plug-ins from the same thread? (I think it's normal for hosts always to make a new thread for every VST plug-in instance but I don't know if this is universal). 5. If you wanted to run two instances of Pd in the same thread this wouldn't help. You'd have to spawn new threads and pass control to them to get into the alternate Pds. Comments anyone? thanks Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Yikes... sounds like back to the drawing board. The odd thing is, do make thread-local storage, the good C compiler folks (and linker folks, etc) had to do all the work you'd need to make a switch-all-my-static-storage-when-I-ask-you-to feature which would open up all sorts of other ways to do things. But I don't see any way to adapt it to our needs, given the concerns you raised below. cheers Miller On Sat, Jan 14, 2012 at 10:16:17PM -0500, Peter Brinkmann wrote: Hi Miller, Thanks for your message! I'm afraid thread-local instances would be problematic from the point of view of libpd: * The most common structure of a libpd-based application involves two threads, a GUI thread and an audio thread, where the GUI controls the Pd engine by invoking libpd functions from its thread. This approach would break if Pd instances were thread local. * In many cases, the audio thread is beyond the control of the programmer. For instance, if you want one Pd instance per JACK client, or one Pd instance per audio unit in iOS, then you just register a callback, and you have no real idea which thread will ultimately invoke your callback. * If you use libpd via its Python bindings, then your threading options are limited due to the Global Interpreter Lock. * libpd may also end up doing batch-processing, either by design or as a client running under JACK's freewheel mode, which has implications for threading. I have a few more concerns, but these are the most important ones. The upshot is that libpd may run in such a wide range of settings that it's hard to make assumptions about what kind of approach to threading is appropriate or even available. Cheers, Peter On Sat, Jan 14, 2012 at 4:04 PM, Miller Puckette m...@ucsd.edu wrote: To Pd dev - For some time the good folks who brought us pdlib have been asking how one could make it possible to run several instances of Pd in a single address space. The question I'd like to rais is this: would it suffice to make Pd instances be per-thread? This could be done by going through all the source and modifyin global and static variables with the nonstandard __thread leyword (gcc) or some declspec horror in Miscoroft C. Alternatively, one could use the C++11 standard thread_local keyword, although I believe that's not widely implemented yet. To do this I'd replace all globals like static t_symbol *symhash[HASHSIZE]; with PDSTATIC t_symbol *symhash[HASHSIZE]; and define PDSTATIC to static (also PDGLOBAL to the empty string and PDEXTERN to extern). Then anyone wanting to come along and recompile pd to work per-thread only has to redefine the three appropriately to the compiler. Here are the gotchas I can foresee: 1. external objects making explicit references to global storage (such as canvas_dspstate and cos-table in m_pd.h and much stuff in the more 'private' header files) would have to be recompiled to run per-thread. They'd still work fine with vanilla Pd. 2. existing externs that create threads would break at the source level if they use any Pd-supplied functions at all (outlet_bang(), clock_set(), gensym(), etc) in 'other threads. Again they'd still work in Pd vanilla, just not with versions of Pd recompiled to run per-thread. 3. lots of lines of code would be touched and this might make a number of existing patches fail to apply cleanly. 4. supposing you use this to make a VST plug-in: what would happen if some stupid host app called all its VST plug-ins from the same thread? (I think it's normal for hosts always to make a new thread for every VST plug-in instance but I don't know if this is universal). 5. If you wanted to run two instances of Pd in the same thread this wouldn't help. You'd have to spawn new threads and pass control to them to get into the alternate Pds. Comments anyone? thanks Miller ___ 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
[PD-dev] font size tweak pushed to git... comments?
Also to pd-dev - I noticed font sizes changed from 0.42 to 0.43 and tried to tweak them back to 0.42-style, by having the new font-size-search code in pd-gui.c actually try to find the font sizes that s_main.c later searches (redundantly) for. I should have done this earlier. If this doesn't break anything it migth be worth rolling out a 0.43-2 just so people don't spend all next year with incorrect font sizes...? cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] font size tweak pushed to git... comments?
I Apbert - I don't think it affects font style (oldness or font face itself) but just gets the sizes to be closer to 0.42. I think that if you're on a macintosh, font was boldface in 0.42 and isn't (by default) on 0.43. On linux I don't think that changed from 0.42 to 0.43. cheers Miller On Sun, Jan 15, 2012 at 07:16:44AM +0100, Albert Graef wrote: On 01/15/2012 05:34 AM, Miller Puckette wrote: I noticed font sizes changed from 0.42 to 0.43 and tried to tweak them back to 0.42-style, by having the new font-size-search code in pd-gui.c actually try to find the font sizes that s_main.c later searches (redundantly) for. I should have done this earlier. If this doesn't break anything it migth be worth rolling out a 0.43-2 just so people don't spend all next year with incorrect font sizes...? I must say that I much prefer the looks of 0.43-1. Maybe it's just because I got used to it, but the 0.42'ish fonts look too bold to me now. Does this change really have a big impact on patch layout? I didn't notice any for the patches that I tried. Albert -- Dr. Albert Graf Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ 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] deadly leak
Personally, I'm hoping to put band-aids on as many manaifestations of the problem as I can track down (so thanks for this one :) and then re-design the whole editor creation and destruction strategy for 0.44 - it looks like it can never be fully debugged the way it's stet up now! Miller On Thu, Dec 15, 2011 at 03:18:30AM +0100, Krzysztof Czaja wrote: On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote: ... Wow! You just helped me finally solve this riddle! Could it be really this simple? In canvas_free() call inside g_canvas.c simply add the following 2 lines: if (x-gl_editor) canvas_destroy_editor(x); I added them right below if (x == glist_getcanvas(x)) canvas_vis(x, 0); Now even if the canvas is recreated with the same memory space there is no more double-entry bug. Are there any potential regressions with this model? The canvas is getting freed so I cannot imagine this posing any problems but then again I am sure I may be missing something... this only handles the case when the GOP is part of a toplevel window. The other case is when the GOP's parent isn't toplevel. When the window of such a parent is closed, the canvases themselves aren't destroyed, but the editors should be. So I think the best way is to get rid of sub-editors recursively. I may be mistaken, though, because there are some partial workarounds already in the code. Apparently, Miller had been aware of the issue but then things went their own way, somehow. Krzysztof ___ 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] help compiling pd 0.43 on Windows 7
Um... is MSVC free? Same deal as Microsoft Windows as a whole... cheers M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpd crasher bug from recent change to glist_delete()
Hi Rich and all - I think I've tracked that down and fixed it... I just now pushed the change to the git repo. cheers Miller On Sun, Nov 27, 2011 at 11:15:46AM +1100, Rich E wrote: I just wanted to point out that the recent change to glist_delete() (commit herehttp://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data;a=blobdiff;f=src/g_graph.c;h=cdebbdc981bb35b24d55baaf4c401254b4c65aea;hp=57db6556efe9f60777f15b9d2e9d8f0c627c4aa0;hb=5c78db0883a3450e1cac727aee422ad7f4dd56eb;hpb=c7fb8e4a06d6253890ca2f73dfe4980c8c88fce9) is causing crashes in libpd when closing patches. Not sure if it is actually related, but it seems pretty similar to the bug already submitted herehttp://sourceforge.net/tracker/?func=detailatid=478070aid=3433140group_id=55736, which appeared a few days after the commit that I linked to. I'll place the backtrace here, indicating that there is a stale pointer that is being accessed somewhere (this is on an EXC_BAD_ACCESS): (gdb) bt #0 0x00091e53 in obj_nexttraverseoutlet (lastconnect=0x7124740, destp=0xbfffd4b0, inletp=0xbfffd4b8, whichp=0xbfffd4c0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/m_obj.c:563 #1 0x00035bcd in linetraverser_next (t=0xbfffd4a0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/g_canvas.c:258 #2 0x00037caa in canvas_deletelinesforio (x=0x71230d0, text=0x7123ab0, inp=0x7123c70, outp=0x0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/g_canvas.c:788 #3 0x00047009 in canvas_rminlet (x=0x7123ab0, ip=0x7123c70) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/g_graph.c:311 #4 0x00054374 in vinlet_free (x=0x7123c00) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/g_io.c:86 #5 0x000927f2 in pd_free (x=0x7123c00) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/m_pd.c:29 #6 0x00046605 in glist_delete (x=0x7123ab0, y=0x7123c00) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/g_graph.c:122 #7 0x00037892 in canvas_free (x=0x7123ab0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/g_canvas.c:709 #8 0x000927f2 in pd_free (x=0x7123ab0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/m_pd.c:29 #9 0x00046605 in glist_delete (x=0x71230d0, y=0x7123ab0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/g_graph.c:122 #10 0x00037892 in canvas_free (x=0x71230d0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/g_canvas.c:709 #11 0x000927f2 in pd_free (x=0x71230d0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/pure-data/src/m_pd.c:29 #12 0x000bdfe7 in libpd_closefile (x=0x71230d0) at /Users/r/code/pd/Libpd/pd-for-ios/libpd/libpd_wrapper/z_libpd.c:343 Cheers, Rich ___ 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] maximum array display size 2000 points?
Hi all -- There's indeed a limit of 2000 (if drawn as points) or 1000 (if as a polygon) -- this is in lines such as: if (ndrawn 2000 || ixpix = 3000) break; and if (ndrawn = 1000) goto ouch; in plot_vis() in g_template.c. I don't know how far Tcl/Tk can be pushed, but try deleting those lines and see what happens :) cheers Miller On Tue, Oct 25, 2011 at 07:59:27PM +0200, João Pais wrote: ah you meant where as in which os, and not in which situation? I am in XP, and Katja should be in some kind of linux, afaik. I didn't test it in any other system than mine. On Tue, 2011-10-25 at 15:51 +0200, João Pais wrote: look at the thread, besides explanations there's an example file. Forgive my blindness, but I still couldn't find the answer to my question in the thread. Are you implying it happens on any Pd flavor / OS? ROman On Tue, 2011-10-25 at 10:53 +0200, João Pais wrote: Hi. I just wanted to call the developers' attention to the thread at http://lists.puredata.info/pipermail/pd-list/2011-10/092037.html. For a project I'm working on it would be great to know the reasons for this, and if there is a fix that can be made. Thanks, Can you specify where this happens? Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-extended-0.43 appearance
Last I checked things were completely inconsistent and no version (normal or extended) got the same font sizes across platforms. If anyone can figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts which everyone will have - and there simply don't seem to be natively available fonts with comparable sizes between Pc/Mac/linux. cheers Miller I'll check that again. It seemed to me that the Pd-vanilla looked very much the same on OS X and Linux, at least since 0.43. I haven't checked Windows yet. Also I had the impression that Pd-vanilla doesn't have a different appearance across different Linuxes anymore. I remember it being dependent on some DPI setting, but I haven't encountered that issue anymore. I tried to get these changes into vanilla, but I guess Miller didn't want them. I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details. Also, you can see the changes that pd-extended makes to puredata but looking at the pd-extended.git in the 'patch_series' branch. Thanks for the explanations. Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-extended-0.43 appearance
Oh -- I misunderstood. I like the idea of making this an option (eitehr growing to the standard box size or huggung the actual size of the font we're getting). cheers Miller On Fri, Oct 21, 2011 at 07:43:17PM -0400, Hans-Christoph Steiner wrote: I think we're talking about the box sizes rather than the font sizes. Those can just be hard-coded to a certain size in pixels, then the font can be measured to fit into those boxes. That's the approach that Pd-extended has been doing since 0.41 or 0.40, I forget which. That's how it works in Pd vanilla 0.43 too. To handle font size differences, the box sizing needs to be handled in Tcl, as well as the mouse and click handling. For something like clicking to edit an object box, Pd only needs to know what the new text is once the editing is done. Roman, I think the thing to do is to measure the boxes for each release in question on each platform so we know where the problem lies. That's what I did back in the day to make the boxes the same pixel sizes. .hc On Oct 21, 2011, at 7:02 PM, Miller Puckette wrote: Last I checked things were completely inconsistent and no version (normal or extended) got the same font sizes across platforms. If anyone can figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts which everyone will have - and there simply don't seem to be natively available fonts with comparable sizes between Pc/Mac/linux. cheers Miller I'll check that again. It seemed to me that the Pd-vanilla looked very much the same on OS X and Linux, at least since 0.43. I haven't checked Windows yet. Also I had the impression that Pd-vanilla doesn't have a different appearance across different Linuxes anymore. I remember it being dependent on some DPI setting, but I haven't encountered that issue anymore. I tried to get these changes into vanilla, but I guess Miller didn't want them. I've already spent a lot of time on it, so I've moved on since it works in Pd-extended. There should be a whole history of the discussion on pd-dev, i.e. the details of the issues. I don't remember them, I'm sure it was some annoying technical details. Also, you can see the changes that pd-extended makes to puredata but looking at the pd-extended.git in the 'patch_series' branch. Thanks for the explanations. Roman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing path and libs from Pd-extended preferences GUI
I'm not sure this really happens but... if you add startup loads to preferences through Pd venilla, then if they don't load or crash for Pd extended, this would be made more confusing if the libraries weren't visible from a dialog somewhere. On the other hand, you could fix fix Pd extended actually to ignore lib preferences altogether (although respect them on the command line for 'experts' -- then it would mke sense to get rid of the dialog and perhaps people would be very grateful for the simplification. cheers Miller On Tue, Sep 20, 2011 at 11:58:47AM -0400, Hans-Christoph Steiner wrote: Please give an example of how this would make this more confusing. My experience is the exact opposite and it is exactly this problem that leads me to want to remove those preferences. The are a big source of confusion and problems, and most Pd-extended users do not use them. I am not proposing removing them from Pd-vanilla, only Pd-extended. I think globally loading libraries is a broken idea. If you remember in the days before Pd-extended, patches that relied on external libraries were mostly unsharable. It could take a long time to track down all the dependencies, etc. and you couldn't be sure which [wrap], [split], [prepend], [scale], etc. the patch needed. Having the configuration in the patch means at worst you know what you need to get it running. At this point I've taught Pd to 10 year olds, high school kids, college kids, masters students, and all sorts of people in workshops, college courses, and patching circles. I also answer a lot of questions on email, on forums, and on IRC. It is from this experience that I am coming from on this issue. I have no desire to control people, I do have a strong desire to make Pd-extended very user friendly to newbies and a excellent editing experience for advanced users. And those that like the Pd-vanilla way are welcome to use it, Pd-extended will remain compatible with patches from Pd-vanilla as long as I work on it. Of course, it is not possible to maintain 100% compatibility when going from Pd-extended to Pd-vanilla since extended includes many more objects. There is also pd-l2ork, desiredata, etc. for those who want different approaches. .hc On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote: Whenever I see the words this would _make_ people... alarm bells start ringing for me. Yes, the proposed behaviour is perfectly correct, logical, and consistent. And utterly the wrong thing to do IMHO. It would frighten off newcomers and disorientate students. It's why we create the cushion of fairy stories for kids, to soften the harsh realities of the _actual_ world. Later on you learn that there isn't a magic library fairy that loads everything, but it helps you cope with the first steps. If anybody made PD that broken out of the box it would require lots of work to fix in order to make it fit to teach with again. On 2011-09-19 19:32, Hans-Christoph Steiner wrote: Hey Miller, I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult? ___ 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] removing path and libs from Pd-extended preferences GUI
OK that assuages most of my doubts. I hadn't realized Pd extended has separate preferences; this is excellent news (preferences carrying over between the 2 was a major headache for me at one point in the past :) I'd still suggest that, if you wnt to not have startup lib loading in the GUI it should get cleaned out of the preferences too - but I suspect you've already thought of that. cheers Miller On Tue, Sep 20, 2011 at 02:37:32PM -0400, Hans-Christoph Steiner wrote: Hey Miller, If I follow what you are saying, that you can create preferences in the Pd-vanilla preferences GUI that Pd-extended will then load, that is no longer true. Pd-extended has a different preferences file from Pd-vanilla (~/.pdextended, ~/Library/Pd/org.puredata.pdextended.plist, etc). It is a bit confusing that Pd-extended is loading libraries globally at startup, you can see those in the debug output in the Pd window. Ultimately, I think Pd-extended should not load any libraries by default. That will be a big transition that will take more prep work, so I think we should defer that to a later release. .hc On Tue, 2011-09-20 at 11:16 -0700, Miller Puckette wrote: I'm not sure this really happens but... if you add startup loads to preferences through Pd venilla, then if they don't load or crash for Pd extended, this would be made more confusing if the libraries weren't visible from a dialog somewhere. On the other hand, you could fix fix Pd extended actually to ignore lib preferences altogether (although respect them on the command line for 'experts' -- then it would mke sense to get rid of the dialog and perhaps people would be very grateful for the simplification. cheers Miller On Tue, Sep 20, 2011 at 11:58:47AM -0400, Hans-Christoph Steiner wrote: Please give an example of how this would make this more confusing. My experience is the exact opposite and it is exactly this problem that leads me to want to remove those preferences. The are a big source of confusion and problems, and most Pd-extended users do not use them. I am not proposing removing them from Pd-vanilla, only Pd-extended. I think globally loading libraries is a broken idea. If you remember in the days before Pd-extended, patches that relied on external libraries were mostly unsharable. It could take a long time to track down all the dependencies, etc. and you couldn't be sure which [wrap], [split], [prepend], [scale], etc. the patch needed. Having the configuration in the patch means at worst you know what you need to get it running. At this point I've taught Pd to 10 year olds, high school kids, college kids, masters students, and all sorts of people in workshops, college courses, and patching circles. I also answer a lot of questions on email, on forums, and on IRC. It is from this experience that I am coming from on this issue. I have no desire to control people, I do have a strong desire to make Pd-extended very user friendly to newbies and a excellent editing experience for advanced users. And those that like the Pd-vanilla way are welcome to use it, Pd-extended will remain compatible with patches from Pd-vanilla as long as I work on it. Of course, it is not possible to maintain 100% compatibility when going from Pd-extended to Pd-vanilla since extended includes many more objects. There is also pd-l2ork, desiredata, etc. for those who want different approaches. .hc On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote: Whenever I see the words this would _make_ people... alarm bells start ringing for me. Yes, the proposed behaviour is perfectly correct, logical, and consistent. And utterly the wrong thing to do IMHO. It would frighten off newcomers and disorientate students. It's why we create the cushion of fairy stories for kids, to soften the harsh realities of the _actual_ world. Later on you learn that there isn't a magic library fairy that loads everything, but it helps you cope with the first steps. If anybody made PD that broken out of the box it would require lots of work to fix in order to make it fit to teach with again. On 2011-09-19 19:32, Hans-Christoph Steiner wrote: Hey Miller, I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult? ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http
Re: [PD-dev] pd-0.43.0 port to NetBSD
Oh... that's good news. I think I'd better pump 0.43-1 out first and then apply this for 0.42 since if there are more tweaks needed it will take time for them to become apparent. cheers Miller On Sat, Sep 17, 2011 at 01:22:21AM +0200, Thomas Klausner wrote: Hi Miller, I can't evaluate the changes here that have to do with the build system but can work on getting rid of alloca dependencies. I didn't know there were any platforms left that didn't support alloca. (In fact I was celebrating that I would be able to replace more malloc calls with alloca to simplify things here and there.) Thanks for the reply. The problem is not that alloca() is not supported, it's just that the alloca.h header is not available on all systems. Gnulib documents it as: Portability problems fixed by Gnulib: This header file is missing on some platforms: FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, AIX 4.3.2, mingw. http://www.gnu.org/software/hello/manual/gnulib/alloca_002eh.html The ubuntu man page says: BUGS The alloca() function is machine and compiler dependent. On many systems its implementation is buggy. Its use is discouraged. The Mac OS X man page claims similarly. The NetBSD man page says: CAVEATS Few limitations can be mentioned: o The alloca() function is machine dependent; its use is discouraged. o The alloca() function is slightly unsafe because it cannot ensure that the pointer returned points to a valid and usable block of mem- ory. The allocation made may exceed the bounds of the stack, or even go further into other objects in memory, and alloca() cannot deter- mine such an error. Avoid alloca() with large unbounded allocations. o Since alloca() modifies the stack at runtime, it causes problems to certain security features. See security(7) for a discussion. On NetBSD, alloca() is provided by stdlib.h. Perhaps the easiest way is to let configure check for alloca.h and stdlib.h and include one or the other, depending on what's available on the system. Would you like diffs for that? Thomas ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing path and libs from Pd-extended preferences GUI
Hi Hans - Perhaps better would be to make it read-only so one can query it. I'm not sure, but there still might be complications for people switching back and forth between vanilla and extended, for example, which would be easiest to resolve if the GUI tools were there :) M On Sun, Sep 18, 2011 at 03:31:41PM -0400, Hans-Christoph Steiner wrote: For next Pd-extended release, the same set of libraries that have been loading automatically at start-up would continue to be loaded as usual. It is just that there wouldn't be a GUI for people to modify that list of libraries that are loaded at startup. I think most Pd-extended users don't use the startup libs preference already, so I am guessing most people wouldn't notice. .hc On Sunday, September 18, 2011 8:09 PM, João Pais jmmmp...@googlemail.com wrote: you'll have lots of newbies complaining that their objects don't load? (it's a good way to force everyone to use namespaces) I am thinking for the next release of Pd-extended, that the preferences panels for loading libs and adding paths should be removed. [import] and [declare] cover all it can do in a better way, and people who really want to have libs and paths loaded globally on start-up can use either a manually written preferences file or the command line flags. I could see maybe keeping the paths GUI, but I don't see any good reasons to keep the startup libs GUI. Anyone have objections? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-0.43.0 port to NetBSD
Hi all --
I can't evaluate the changes here that have to do with the build system
but can work on getting rid of alloca dependencies. I didn't know there
were any platforms left that didn't support alloca. (In fact I was celebrating
that I would be able to replace more malloc calls with alloca to simplify
things here and there.)
cheers
Miller
On Thu, Sep 15, 2011 at 03:15:05AM +0200, Thomas Klausner wrote:
Hi!
I've ported pd-0.43.0 to NetBSD.
It compiles fine and it does stuff.
I'm new to pd, so I can't evaluate yet if everything's fine.
I've imported the resulting package into pkgsrc as pkgsrc/audio/pd.
It will soon be visible at
http://pkgsrc.se/audio/pd
The patches might need cleanup before they can be included into pd,
but even in their current state they show the issues I had to solve.
There are three more issues I fixed with sed:
1. hardcoded path to tclsh in tcl/pkg_mkIndex.tcl
2. path to audio device in src/s_audio_oss.c
3. paths to documentation, which I moved to ${PREFIX}/share/doc/pd to
follow pkgsrc conventions
Please let me know about the best way to get these or similar patches
integrated.
Thanks,
Thomas
$NetBSD: patch-Makefile.am,v 1.1.1.1 2011/09/15 01:05:05 wiz Exp $
Fix path to documentation (installed following pksrc conventions).
Avoid creating unnecessary(?) empty directory.
--- Makefile.am.orig 2010-08-18 23:42:59.0 +
+++ Makefile.am
@@ -37,11 +37,7 @@ endif
## FIXXXME
## $(pkglibdir) is used throughout the other Makefile.amS
## simply ignoring the special case for other OSs...
-if LINUX
-libpddir = $(pkglibdir)
-else
-libpddir = $(prefix)
-endif
+libpddir = $(prefix)/share/doc/pd
# Symlinks don't work on Windows/MinGW but they do on Cygwin.
bin:
@@ -51,6 +47,7 @@ locales:
make -C po all
install-data-local:
+mingw-install-data-local:
$(INSTALL) -d $(DESTDIR)$(libpddir)/startup
$(INSTALL) -d $(DESTDIR)$(libpddir)/startup/disabled
$NetBSD: patch-extra_bonk~_bonk~.c,v 1.1.1.1 2011/09/15 01:05:05 wiz Exp $
alloca.h is not portable.
--- extra/bonk~/bonk~.c.orig 2010-08-19 01:37:00.0 +
+++ extra/bonk~/bonk~.c
@@ -82,11 +82,7 @@ void *bonk_class;
static t_class *bonk_class;
#endif
-#ifdef _WIN32
#include malloc.h
-#elif ! defined(_MSC_VER)
-#include alloca.h
-#endif
/* bonk~ - */
$NetBSD: patch-extra_pd~_pd~.c,v 1.1.1.1 2011/09/15 01:05:05 wiz Exp $
Add missing include (for SIGPIPE).
Define extensions for NetBSD.
--- extra/pd~/pd~.c.orig 2010-07-28 20:55:17.0 +
+++ extra/pd~/pd~.c
@@ -6,6 +6,7 @@
*/
#include stdio.h
+#include signal.h
#include string.h
#include unistd.h
#include stdlib.h
@@ -56,6 +57,15 @@ static char pd_tilde_dllextent[] = .l_i
pd_tilde_dllextent2[] = .pd_linux;
#endif
#endif
+#if defined(__NetBSD__)
+#ifdef __x86_64__
+static char pd_tilde_dllextent[] = .n_ia64,
+pd_tilde_dllextent2[] = .pd_netbsd;
+#else
+static char pd_tilde_dllextent[] = .n_i386,
+pd_tilde_dllextent2[] = .pd_netbsd;
+#endif
+#endif
#ifdef __APPLE__
static char pd_tilde_dllextent[] = .d_fat,
pd_tilde_dllextent2[] = .pd_darwin;
$NetBSD: patch-extra_sigmund~_sigmund~.c,v 1.1.1.1 2011/09/15 01:05:05 wiz
Exp $
alloca.h is not portable.
--- extra/sigmund~/sigmund~.c.orig2010-07-28 20:55:17.0 +
+++ extra/sigmund~/sigmund~.c
@@ -26,11 +26,7 @@ for example, defines this in the file d_
#include math.h
#include stdio.h
#include string.h
-#ifdef _WIN32
#include malloc.h
-#elif ! defined(_MSC_VER)
-#include alloca.h
-#endif
#include stdlib.h
#ifdef _MSC_VER
#pragma warning( disable : 4244 )
$NetBSD: patch-src_Makefile.am,v 1.1.1.1 2011/09/15 01:05:05 wiz Exp $
Add missing libraries to linker line.
--- src/Makefile.am.orig 2011-02-27 03:22:57.0 +
+++ src/Makefile.am
@@ -6,7 +6,7 @@ pd_LDFLAGS =
pdsend_CFLAGS =
pdreceive_CFLAGS =
pd_watchdog_CFLAGS =
-LIBS =
+LIBS = $(LIBOSSAUDIO) $(PTHREAD_LDFLAGS) $(PTHREAD_LIBS) -lm
INCLUDES = @INCLUDES@
SUFFIXES = .@EXTENSION@ .@SHARED_LIB@
$NetBSD: patch-src_configure,v 1.1.1.1 2011/09/15 01:05:05 wiz Exp $
Fix unportable test(1) construct.
--- src/configure.orig2011-03-21 01:41:34.0 +
+++ src/configure
@@ -5407,7 +5407,7 @@ then
then
fat=no
fi
-if test x$fat == xyes;
+if test x$fat = xyes;
then
MORECFLAGS=-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-arch i386 -arch ppc -Wno-error
$NetBSD: patch-src_d__array.c,v 1.1.1.1 2011/09/15 01:05:05 wiz Exp $
Detect endianness on NetBSD.
--- src/d_array.c.orig2010-07-28 20:55:17.0 +
+++ src/d_array.c
@@ -502,7 +502,7 @@ static void tabread4_tilde_setup(void)
#include sys/endian.h
#endif
-#if defined(__FreeBSD__) ||
Re: [PD-dev] preparing phasor~Co. for double precision Pd
Hi all -- I'm not sure it's done right, but my intention in s_audio_pa.c is to use 'float' when talking to the portaudio API and t_sample to talk to the rest of Pd -- so t_sample could be made double without affecting portaudio. The only situation I can imagine in which t_sample might want to differ from t_float is to do ficed-point audio... but I think nowadays that's almost never needed. cheers Miller On Wed, Jul 27, 2011 at 05:56:01PM -0400, Hans-Christoph Steiner wrote: On Jul 27, 2011, at 5:47 PM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2011 11:11 PM, Hans-Christoph Steiner wrote: like you've covered that already. As for 64-bit floats to output, a quick hack to get things working is to just hammer samples down to 32-bits... i don't think that's such a great idea. loads of problems (mainly with granular synthesis or other applications where you want to access large tables sample accurately in the signal(!) flow) can simply be fixed by making signals be 64bit too. and then, quite some infrastructure code makes no clear separations between t_float and t_sample, so it might be simpler to make Pd use doubles throughout and not just for one type of numbers. I'm saying only as the final output stage to portaudio as a temporary hack to get things working. Its not a good idea otherwise. .hc “We must become the change we want to see. - Mahatma Gandhi ___ 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] struct _canvasenvironment
It's in m_pd.h - that's a pretty good guarantee of stability (although not 100% perfect I'm afraid.) One caution -- if soneone 'saves' the patch into a new directory, the canvas's directory will then change -- so it's best not to store the result of canvas_settid() but to call it each time it gets used. cheers Miller On Wed, Jul 13, 2011 at 01:46:06PM -0700, Jonathan Wilkes wrote: --- On Wed, 7/13/11, IOhannes m zmoelnig zmoel...@iem.at wrote: From: IOhannes m zmoelnig zmoel...@iem.at Subject: Re: [PD-dev] struct _canvasenvironment To: pd-dev@iem.at Date: Wednesday, July 13, 2011, 8:31 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-13 20:11, Jonathan Wilkes wrote: Hello, Why is struct _canvasenvironment in g_canvas.c instead of g_canvas.h? I want to take a t_object inside g_text.c and-- if it's an abstraction-- get its name and dir. I can get the name but cannot get the dir because struct _canvasenvironment isn't in g_canvas.h. Would it break things if it were moved there? maybe because it is considered an opaque type? it's a way of telling you: t_canvasenvironment is private property, do not trespass. you don't have right of ways and if the next time you drop by, the owner decided to change everything, you are not supposed to complain. Oops, I overlooked canvas_getdir. But am I not supposed to trespass into this function since it's not in g_canvas.h? mfgasdfr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4d5GoACgkQkX2Xpv6ydvR5CgCgmk4QxjBdeDW58g9G/KxVnVtT gfEAn0Rw8pouk0ikU4+DXVAEBBrY3+gn =Y2de -END PGP SIGNATURE- -Inline Attachment Follows- ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] struct _canvasenvironment
Oops, yep, that's what I meant... typed too fast. cheers M Did you mean canvas_getdir? If that's the case I think I'm safe, since I'm only using it if the canvas in question is an abstraction. (And it's an absolute path.) I don't think this would lead to any problems. Also, in the canvas get method patch I put on the tracker it just calls canvas_getdir and returns the result. -Jonathan I'm planning to go through those Real Soon Now :) M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] is OOURA fft algorithm still used?
Hmm, I think Pd is using both OOURA and Mayer, which have different APIs, because I haven't taken the time to rewrite the Mayer API to use OOURA. cheers Miller On Sun, May 29, 2011 at 12:34:36PM +1000, Rich E wrote: So is it just in there so that you can compile it in if you feel like changing the makefile, or why is d_fft_fftsg.c included in the source? Miller, why not use OOURA instead of Maynard, now that we know it is faster and more versatile? I could have sworn that about 1 year ago, pd was using the OOURA algorithm. On Tue, May 17, 2011 at 3:25 PM, Rich E reakina...@gmail.com wrote: Hi all, Is the OOURA fft algorithm (d_fft_fftsg.c) ever used in pd? I can't really tell from the makefile (granted, I don't really know how to use the autotools system), but I cannot see the file ever compiled into pd during the make. I though that OOURA was the fastest and most flexible fft algorithm included in pd.. cheers, Rich ___ pd-l...@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Finding overlap
Unfortunately not. I've been planning to make this possible for many years but the details get confusing. cheers Miller On Fri, Apr 01, 2011 at 01:10:42PM +0100, Andrew Hassall wrote: Is it possible to find the signal overlap within an external, I know you can find the length and sample rate of a signal from the struct _signal, are there any functions to find the overlap? Thanks Andy ___ 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] erase object text
Can't be done -- the actual text editing is done in Pd and the TCL code is just to display the current state of affairs down in Pd. There might be a way to do it via messages to Pd though -- for instance, simlulating the necessary mouse/keyboard actions. cheers Miller On Fri, Apr 01, 2011 at 08:49:40PM +0200, yvan volochine wrote: hi, is there a way to erase the text from an object box that's being edited (in tcl) ? I tryed with pdtk_sekectall and pdtk_text_set but I couldn't get it to work (pd keeps the 'old' text). cheers, _y ___ 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] status of verbose() in 0.43?
Hi all, Sorry to reopen this old thread -- I think there's a more recent message from HC but I can't find it right now. I wonder if, in the interest of putting 0.43 out, we should just hide the verbosity level control and let all printout through for 0.43, then try to figure out how to do this correctly for 0.44. I'm worried that the verbosity level and the verbose flag (in the search path menu) aren't coordinated. and I think they really should be. We would need to figure out whether verbosity can just be a level or should be a bitfield (file open attempts, warnings, blah blah). Also, the filtering almost certainly should be done down in Pd, not in the Tcl code, unless there's a significant amount of printout coming from the Tcl layer which I think there isn't. I still need to test Pd on a couple more hardware/software combinations, but would dearly love to get the damn thing done so I can start working on some things I'm delaying for 0.44. thanks Miller On Wed, Feb 23, 2011 at 05:50:56PM -0500, Hans-Christoph Steiner wrote: On Feb 23, 2011, at 5:38 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-23 09:05, IOhannes m zmoelnig wrote: On 2011-02-22 23:26, Hans-Christoph Steiner wrote: This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future. well, the thing is that for now we only have to reserve an additional variable objectID for the logpost(), which could be NULL/empty. logpost(objectID, level, msg,...) then, time permitting, fill in the missing code on both the C and the tcl side. i only try to avoid re-defining functions in each release. anyhow, here is a draft for how this would work (to be applied on top of pd-extended.git#fac011b1) apart from changing the logpost() functions, it also adds a new global method to Pd that allows for selecting/highlighting an object based on a symbolic representation of it's address. like alway, most work was spent in trying to figure out things in tcl :-) Now I'm starting to think that these would be appropriate levels, and use both the number and the name for the Log menu: 0 fatal 1 error 2 normal 3 info ALL .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] git repository, portaudio broken on windows
In case any Pd developers out there try running the newest git version on windows, don't try running portaudio -- I broke it and probably won't be able to fix it for a few days. The mmio (normal) audio API works the same as usual. cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] asio not starting on last pd-extended relsease
HI all -- I'm not aware of any trouble... I may not be able to test this till I get back to San Diego in January though. thanks for flagging this Miller On Mon, Nov 15, 2010 at 11:14:55AM +0100, patko wrote: Hello, I've figured out that I couldn't use asio in that 0.45-5 release, I'm also working over some compilation and got these messages from the compiler: g++ -DPD -DPD_INTERNAL -DMSW -DNT -DPA_NO_DS -DUSEAPI_MMIO -DPA_NO_WASAPI -DUSEAPI_PORTAUDIO -DPA19 -DPA_LITTLE_ENDIAN -mms-bitfields -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -W -Wstrict-prototypes -Wno-unused -Wno-unused-parameter -Wno-parentheses -Wno-switch -O3 -funroll-loops -fomit-frame-pointer -I../../pd/portaudio -I../../pd/asio -I../../pd/portaudio/include -I../../pd/portaudio/src/common -c -o ../../pd/portaudio/src/hostapi/asio/iasiothiscallresolver.o ../../pd/portaudio/src/hostapi/asio/iasiothiscallresolver.cpp cc1plus.exe: warning: command line option -Wstrict-prototypes is valid for Ada/C/ObjC but not for C++ g++ -DPD -DPD_INTERNAL -DMSW -DNT -DPA_NO_DS -DUSEAPI_MMIO -DPA_NO_WASAPI -DUSEAPI_PORTAUDIO -DPA19 -DPA_LITTLE_ENDIAN -mms-bitfields -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -Wall -W -Wstrict-prototypes -Wno-unused -Wno-unused-parameter -Wno-parentheses -Wno-switch -O3 -funroll-loops -fomit-frame-pointer -I../../pd/portaudio -I../../pd/asio -I../../pd/portaudio/include -I../../pd/portaudio/src/common -c -o ../../pd/portaudio/src/hostapi/asio/pa_asio.o ../../pd/portaudio/src/hostapi/asio/pa_asio.cpp cc1plus.exe: warning: command line option -Wstrict-prototypes is valid for Ada/C/ObjC but not for C++ ../../pd/portaudio/src/hostapi/asio/pa_asio.cpp: In function `PaError IsFormatSupported(PaUtilHostApiRepresentation*, const PaStreamParameters*, const PaStreamParameters*, double)': ../../pd/portaudio/src/hostapi/asio/pa_asio.cpp:1425: warning: 'asioDeviceIndex' might be used uninitialized in this function ../../pd/portaudio/src/hostapi/asio/pa_asio.cpp: In function `PaError OpenStream(PaUtilHostApiRepresentation*, PaStream**, const PaStreamParameters*, const PaStreamParameters*, double, long unsigned int, PaStreamFlags, int (*)(const void*, void*, long unsigned int, const PaStreamCallbackTimeInfo*, PaStreamCallbackFlags, void*), void*)': ../../pd/portaudio/src/hostapi/asio/pa_asio.cpp:1877: warning: 'asioDeviceIndex' might be used uninitialized in this function before going ahead, I'm asking to the list if this is a known problem, if I'm using the good asio version (or which one should I use?) best regards. -- Patrice Colet ___ 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] proposed /usr/bin/pd-gui command
Wow, 52 bytes of pure eloquence... I imagine, throw it in pd/tcl and adjust makefiles accordingly :) M On Tue, Aug 31, 2010 at 01:39:50AM -0400, Hans-Christoph Steiner wrote: Hey all, I noticed that pd-gui.tcl is installed into /usr/local/bin/pd-gui.tcl, but it doesn't work for me there. I wrote a quick sh script called 'pd-gui' which does work for me. Its attached. The only question I have is whether this should just be generated by the makefile, or included in the git repo and tarballs. I am currently favoring the later. .hc ___ 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] 0.43 omission: 'set-startup' and 'set-path'
OTOH, the path is always the global path, not the one belonging to any specific patch - so it's probably useless to the gui anyway, hmm. Things like [declare] can set the global path, IIRC. ::pd_path and ::pd_startup are not useless in pd-gui, they are used for loading GUI plugins and building the Help Browser based on installed libraries, and could be used in a lot of other things. .hc [declare] sets a path local to the patch it's in. There might have to be changes in declare allowing abstractions to change the path even without having the owning patch change (this is the subject of much comfusion and worry :) [declare] also loads 'libraries', which are then global. Probably when that happens it would be apropriate for pd to throw the info up to the gui (but not via the startup variable -- that would need to reflect only what's there by default when starting Pd afresh). 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. cheers M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 meetup on IRC?
I have an informal meeting showing up at 18:00 UTC, hope to keep it to 1/2 hour, but anyway am on now if that helps :) M On Fri, Jul 16, 2010 at 11:50:57AM -0400, Hans-Christoph Steiner wrote: On Jul 16, 2010, at 4:20 AM, IOhannes zm?lnig wrote: hi On 07/15/2010 10:33 PM, Hans-Christoph Steiner wrote: We are kind of meeting now a bit, but we should do it tomorrow if you can IOhannes. obviously i was safe and sound at home last eveneing when you tried to IRC. i'm leaving for hols on monday and will probably be offline tomorrow and the day after tomorrow as well, so today would be a perfect chance to meet up at IRC (for more than 2 weeks) 19:00UTC is ok i would prefer 18:00UTC though... Either 18:00 or 19:00 works for me. Plus I'll probably be in #dataflow for the next few hours before that anyway. .hc I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup (creator of C++) ___ 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'
Hi Hans -- the vwait line didn't seem correct to me (could return right after Pd says to clear pd_path, before the other messages bubble up to append the various directories to it). I ended up fixing Pd to volunteer the path and startup stuff before sending pdtk_pd_startup so that none of the tcl side of things should be needed any longer. OTOH if you were planning to send pd set-startup etc at some later point in the tcl code, this would need to be supported in Pd...(?) cheers Miller On Fri, Jul 16, 2010 at 03:58:24PM -0400, Hans-Christoph Steiner wrote: Hey Miller, I just noticed that you left out a key part of pd-gui-rewrite in 0.43. There is the 'set-startup' and 'set-path' messages which allows pd-gui to get the state of those things without having to open the respective preference dialog panels. The changes are in m_glob.c and s_path.c, as well as these lines in pd-gui.tcl: pdsend pd set-startup ;# get ::startup_libraries and ::startup_flags lists pdsend pd set-path;# get the ::pd_path list vwait ::pd_path ;# wait for 'pd' to respond .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ 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] uploading Pd git repository to sourceforge
Should be fixed now (in git repo) thanks Miller On Thu, Jul 15, 2010 at 12:38:59PM -0700, Miller Puckette wrote: Sure enough... will debug. thanks M ` On Thu, Jul 15, 2010 at 08:18:41PM +0100, Claude Heiland-Allen wrote: 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 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] uploading Pd git repository to sourceforge
THanks for the feedback. I'm not sure what to do about the autobuild problems but mean to work on that. (Me, I use the old-fashioned cd src; ./configure; make method which I hope to maintain in parallel with the autobuild thing in order to avoid letting unintended dependencies creep in). The extra/makefile stuff belongs to the old-fashioned system. Maybe this just needs clearer documentation... cheers Miller On Wed, Jul 14, 2010 at 03:03:00PM -0400, Stephen Sinclair wrote: Hello! Thanks for the git repo, it's a much preferable way to follow Pd development for me.. Just for some feedback, here's my session trying to compile it.. $ ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 aclocal: couldn't open directory `m4': No such file or directory autoreconf: aclocal failed with exit status: 1 $ mkdir m4 $ ./autogen.sh .. snip.. success. $ ./configure .. snip.. success. $ make .. snip .. make[2]: *** No rule to make target `AppMain.tcl', needed by `all-am'. Stop. make[2]: Leaving directory `/home/sinclairs/projects/pd-vanilla/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sinclairs/projects/pd-vanilla' make: *** [all] Error 2 It seems the src/Makefile.am file needs all the .tcl files, but these are actually in the tcl folder, not src. $ cp tcl/*.tcl src/ $ make .. snip .. Making all in extra make[2]: Entering directory `/home/sinclairs/projects/pd-vanilla/extra' make[2]: *** No rule to make target `all'. Stop. Seems like there is no Makefile.am in extra. Saw that extra/makefile exists.. got confused, so I edited Makefile.am to remove extra from SUBDIRS. $ make .. snip.. SUCCESS. I saw that I could cd to each of the subfolders under extra and make each of them individually, since they seem to include extra/makefile while filing in the NAME variable. I would maybe suggest renaming makefile to something like external.mk, since the name makefile suggests to me that I should be able to run make in that folder. Or alternatively just going all the way with automake by providing Makefile.am in each of these folders. In any case if there is no Makefile.am in extra, it shouldn't be included in SUBDIRS.. Steve On Sun, Jul 11, 2010 at 11:33 PM, Miller Puckette mpuck...@imusic1.ucsd.edu wrote: o Pd developers -- After much uncertainty how to proceed, I finally went ahead and 'pushed' my Pd git repository to sourceforgs -- available at http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data or to clone it to your machine (once you have git installed): git clone \ ??ssh://yourn...@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data Unlike the svn version, ths git version isn't tested on all platformss. ??I _think: what I should do is tag the occasional commits that I've tested semi-thoroughly and also commit those to svn (the traditional place I've been uploading tested code to). ??So the svn code will always be clean and the git code variously clean and dirty depending on phase. The git code is based on the Hans/IOhannes gui rewrite -- that alone is such a dramatic improvement that I'm thinking I should just do some audio testing and tuning now, and then call it 0.43. cheers Miller ___ 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] uploading Pd git repository to sourceforge
Hmm... I hadn't tried the 'new' build but apparently am missing something. I'll try adding HC's Makefile.am and see if I can build it that way over here. I don't get the .menubar.file error -- you're in linux, I presume ... could you send the tk backtrace? On Mon, Jul 12, 2010 at 11:03:51AM +0200, IOhannes m zmoelnig wrote: On 2010-07-12 05:33, Miller Puckette wrote: o Pd developers -- After much uncertainty how to proceed, I finally went ahead and 'pushed' my Pd git repository to sourceforgs -- available at http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data or to clone it to your machine (once you have git installed): git clone \ ssh://yourn...@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data cool, thanks. The git code is based on the Hans/IOhannes gui rewrite -- that alone is such a dramatic improvement that I'm thinking I should just do some audio testing and tuning now, and then call it 0.43. the major question i have right now (after cloning the repository): how do you compile it? it seems like you have not fully taken hans's autoconf buildsystem, though there are some definitive traces of it in the repository (e.g. there is ./configure.ac and ./autogen.sh but no ./Makefile.am; as a matter of fact no *.am file (from automake) is there at all) i tried the old way (by running autconf ./configure make in ./src) which compiles fine but i get an error at startup: invalid command name .menubar.file skipping the error, seems to make everything work. fgmasd IOhanhnes ___ 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
[PD-dev] uploading Pd git repository to sourceforge
o Pd developers -- After much uncertainty how to proceed, I finally went ahead and 'pushed' my Pd git repository to sourceforgs -- available at http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data or to clone it to your machine (once you have git installed): git clone \ ssh://yourn...@pure-data.git.sourceforge.net/gitroot/pure-data/pure-data Unlike the svn version, ths git version isn't tested on all platformss. I _think: what I should do is tag the occasional commits that I've tested semi-thoroughly and also commit those to svn (the traditional place I've been uploading tested code to). So the svn code will always be clean and the git code variously clean and dirty depending on phase. The git code is based on the Hans/IOhannes gui rewrite -- that alone is such a dramatic improvement that I'm thinking I should just do some audio testing and tuning now, and then call it 0.43. cheers Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] what is audio I/O stuck... closing audio for?
Well, on some systems, the audio device sometimes hangs, and this stops Pd
dead -- you have to kill it and start over. I haven't seen it happen on a
Mac. So it might be a good idea to #ifdef it away for Mac but keep it in
for windows.
cheers
Miller
On Sun, Apr 25, 2010 at 06:52:40PM -0400, Hans-Christoph Steiner wrote:
So there is some code in m_sched.c which closes the audio device. On
Mac OS X, it gets triggered when the computer goes to sleep, and then
Pd can't play audio any more unless you cycle the DSP or restart Pd.
This is an source of confusion for newbies and annoyance for users. I
don't quite understand why there is this code to close the audio
device? Can I just #ifdef it out for Mac OS X?
/* on 32nd idle, start a clock watch; every
32 ensuing idles, check it */
if (idlecount == 32)
idletime = sys_getrealtime();
else if (sys_getrealtime() - idletime 1.)
{
post(audio I/O stuck... closing audio\n);
sys_close_audio();
sched_set_using_audio(SCHED_AUDIO_NONE);
goto waitfortick;
}
It also seems to get triggered a lot on Windows, but I don't know
why. Perhaps this isn't really needed?
.hc
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
___
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
[PD-dev] gui-rewrite, apple_events.tcl imports pdtk_post?
Hi all, I tried to compile pd-gui-rewrite for macintosh and it complained that pdtk_post couldn't be imported because it already exists. I found two places that imported it and tried removing the line: namespace import ::pdwindow::pdtk_post from apple-events.tcl, after which Pd runs happily. Is there a reason that line is there? (I'm scared to commit anything involving the tcl code now because I don't understand it!) I'm busy trying to sync up with the gui-rewrite code, and was mostly able to use it as is. If this is a good moment for Hans and Guenter I can try committing the small changes I made to get it running...? thanks Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] more information on the gui getting stuck on 0.42.5
If you ask for clock_delay() of 0, it will fire before the next DSP tick, that is to say, as soon as possible. cheers Miller On Thu, Mar 18, 2010 at 12:04:13AM -0400, Ivica Ico Bukvic wrote: -Original Message- From: Miller Puckette [mailto:mpuck...@imusic1.ucsd.edu] Sent: Wednesday, March 17, 2010 10:26 PM To: Ivica Ico Bukvic Cc: Hans-Christoph Steiner; pd-dev@iem.at Subject: Re: [PD-dev] more information on the gui getting stuck on 0.42.5 Hi Ivo - It's unsafe to issue messages from inside a DSP routine, because the message could eventually cause tables to relocate or even a rebuild of the DSP chain. The safe thing is to schedule the message using clock_delay(). examples are snapshot~ and (more complicatedly) fiddle~ and bonk~. cheers Miller Many thanks for the clarification Miller. This helps a lot! BTW, how often does the clock_delay() fire? Are we talking major delays that would effectively render this kind of a bang-based sync useless or is this something that occurs practically as often as dsp calls? Best wishes, Ico ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] more information on the gui getting stuck on 0.42.5
It's an old habit from Max, but is a mistake in the context of Pd. Doesn't make any difference though, 0 is 0 far as I know :) M On Thu, Mar 18, 2010 at 07:49:15PM -0400, Ivica Ico Bukvic wrote: Cool, thanks! One more quick question: what about 0L (zero folowed by an L) I saw included with some clock delay instances inside pd's source? How is that different from just plain 0? Ico Miller Puckette mpuck...@imusic1.ucsd.edu wrote: If you ask for clock_delay() of 0, it will fire before the next DSP tick, that is to say, as soon as possible. cheers Miller On Thu, Mar 18, 2010 at 12:04:13AM -0400, Ivica Ico Bukvic wrote: -Original Message- From: Miller Puckette [mailto:mpuck...@imusic1.ucsd.edu] Sent: Wednesday, March 17, 2010 10:26 PM To: Ivica Ico Bukvic Cc: Hans-Christoph Steiner; pd-dev@iem.at Subject: Re: [PD-dev] more information on the gui getting stuck on 0.42.5 Hi Ivo - It's unsafe to issue messages from inside a DSP routine, because the message could eventually cause tables to relocate or even a rebuild of the DSP chain. The safe thing is to schedule the message using clock_delay(). examples are snapshot~ and (more complicatedly) fiddle~ and bonk~. cheers Miller Many thanks for the clarification Miller. This helps a lot! BTW, how often does the clock_delay() fire? Are we talking major delays that would effectively render this kind of a bang-based sync useless or is this something that occurs practically as often as dsp calls? Best wishes, Ico ___ 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] more information on the gui getting stuck on 0.42.5
Hi Ivo -
It's unsafe to issue messages from inside a DSP routine, because the
message could eventually cause tables to relocate or even a rebuild of
the DSP chain. The safe thing is to schedule the message using
clock_delay().
examples are snapshot~ and (more complicatedly) fiddle~ and bonk~.
cheers
Miller
On Wed, Mar 17, 2010 at 09:39:44PM -0400, Ivica Ico Bukvic wrote:
I finally discovered the problem. It is not pd or pd-extended at all. It
appears that the original implementation of the wiimote object I based
l2ork's threaded version on was causing these issues as some of its
output was callback driven from the external cwiid library, rather than
being pushed by the incoming bang signal. I think this makes sense as
when those messages are thrown out-of-sync in respect to the patch tree
traversal (or whatever method is being used to do this), all kinds of
weird things can happen, like seemingly random truncation of messages
which becomes more prominent when the message activity increases.
Now, that I redesigned the object so that it only outputs stuff through
non-signal outlets when it receives bang (as it should), I've yet to
reproduce a problem which would've been otherwise occurring within
seconds, but only if I used wiimote button messages to trigger gui
events (keyboard events did not cause any problems whatsoever, which
seems to speak in favor of the aforesaid explanation).
So, Hans, this perhaps may be the cause of your problems as well--FWIW
you may want to check any less common pd objects you may be using in
specific patches and see if they allow for out-of-sync outputs that are
threaded separately from Pd's signal tree.
BTW, I would also love to hear thoughts from the hardened Pd devs
regarding this. I haven't had a chance to read carefully through the
external (design documentation which likely covers this), as my objects
were mainly alterations of the existing designs.
Speaking of which, I've also implemented a simple alternative version of
the phasor~ that outputs bang every time it completes a period (or as
close as it gets to this moment based on pd's audio engine buffer which
I believe is 64 bytes). Now I am wondering if having a bang outputted
from a non-signal outlet whose triggering is dictated by the dsp thread
may cause similar problems in the long run and whether I should simply
stick to vanilla ~ kinds of solutions for this purpose.
Here's the relevant code (which is essentially identical to the built-in
phasor with one notable exception towards the bottom):
t_int *disis_phasor_perform(t_int *w)
{
t_disis_phasor *x = (t_disis_phasor *)(w[1]);
t_float *in = (t_float *)(w[2]);
t_float *out = (t_float *)(w[3]);
int n = (int)(w[4]);
double dphase = x-x_phase + UNITBIT32;
union disis_phasor_tabfudge tf;
int normhipart;
float conv = x-x_conv;
tf.tf_d = UNITBIT32;
normhipart = tf.tf_i[HIOFFSET];
tf.tf_d = dphase;
while (n--)
{
tf.tf_i[HIOFFSET] = normhipart;
dphase += *in++ * conv;
*out++ = tf.tf_d - UNITBIT32;
tf.tf_d = dphase;
}
tf.tf_i[HIOFFSET] = normhipart;
x-x_phase = tf.tf_d - UNITBIT32;
//here comes the bang inside the dsp thread
//is this a bad idea?
if (x-x_phase_delta 0.5 x-x_phase 0.5) outlet_bang(x-b_out);
x-x_phase_delta = x-x_phase;
return (w+5);
}
Any advice on this one, particularly from the Pd-dev gurus would be most
appreciated!
Best wishes,
Ico
___
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
