Re: [PD-dev] libpd partly working with pd instances

[Miller Puckette]

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  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

[PD-dev] libpd partly working with pd instances

[Miller Puckette]

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 
#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

Re: [PD-dev] oggread~ not working on pd-extended or libpd on windows.

[Miller Puckette]

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  >> 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 .
> >
> >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  >> 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 
> >
> >
> >
> >
> >--
> >Rafael Vega
> >email.r...@gmail.com 
> >
> >
> >
> >
> >--
> >Rafael Vega
> >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

[Miller Puckette]

e_d -> vars, results) != NULL) { 285:  three_d -> lyap_exp = 
> lyapunov((void *) three_d, (t_gotfn) calc, M_var_count, (double *) three_d -> 
> vars);
> 
> ./chaos/threeply.c:
> 150:  if (lyapunov_full((void *) threeply, (t_gotfn) calc, M_var_count, 
> threeply -> vars, results) != NULL) { 240:threeply -> lyap_exp = 
> lyapunov((void *) threeply, (t_gotfn) calc, M_var_count, (double *) threeply 
> -> vars);
> 
> ./chaos/tinkerbell.c:
> 156:  if (lyapunov_full((void *) tinkerbell, (t_gotfn) calc, M_var_count, 
> tinkerbell -> vars, results) != NULL) { 259:tinkerbell -> 
> lyap_exp = lyapunov((void *) tinkerbell, (t_gotfn) calc, M_var_count, (double 
> *) tinkerbell -> vars);
> 
> ./miXed/riddle/riddle.c:
> 873:t_gotfn freefn = zgetfn((t_pd *)rd, gensym("_free"));
> 
> ./miXed/shared/unstable/fragile.c:
> 54:   if (mp->me_fun == (t_gotfn)thiscall) 102:   if (mp->me_name == 
> cname && mp->me_fun != (t_gotfn)thiscall)
> 
> ./miXed/shared/unstable/pd_imp.h:
> 17:t_gotfn me_fun;
> 
> 
> 
> On Feb 22, 2014, at 6:00 AM, pd-dev-requ...@iem.at wrote:
> 
> > From: Dan Wilcox 
> > 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 
> > 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

[Miller Puckette]

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  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

[Miller Puckette]

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
> wrote:
> 
> > 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  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

Re: [PD-dev] Multiple Instance of pdlib

[Miller Puckette]

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 of libpd on Github, I've solved the Pd multiple
> instances problem by letting the linker take care of separating
> the global variables. However, using the linker causing various
> problems, such as making it very difficult to load externals,
> and it should probably also be considered a hack.
> Your plan (the plan I didn't bother doing in my branch) is quite
> undoubtedly the proper way to do it, and hopefully I would have time to
> help. At least I would be helping to debug it afterwards,
> because I would start using this system (in the Radium music editor),
> instead of my own, to embed Pd instances.
> 
> And an advantage to Pd itself might be that the source could be clearer when
> variables that belongs to the instance, actually are denoted as such
> in the text.
> 
> There is also quite microscopic concern, which is that the added
> amount of text could make the source more difficult to read,
> here and there. Maybe a very short variable name for the pd instance,
> such as "p", "pi', would be a good idea. (i.e. not "pure_data_instance").
> 
> 
> 
> On Sat, Dec 7, 2013 at 10:20 PM, Rob Bairos  wrote:
> > Sorry, most of my original post got cut off.
> > Here's the rest (minus the list of symbols) in case its causing a problem:
> >
> >
> > From my understanding, the current proposed solution is to take all statics
> > and globals,
> > encapsulate them in one object, and pass that object to all api calls.
> > Peter further suggested legacy api is maintained by having them call the new
> > api with a default instance object.
> >
> > I did a little bit of hunting, using objdump on the current dll, to get a
> > rough list of all the globals and statics currently involved.
> >
> > Im thinking the *_class and *_sym static pointers are in fact constant, and
> > need only one shared instance.  That would leave about 320 variables
> > remaining.
> > Many of these variables are constant arrays, strings, etc.
> > And many seem to be used only as a shortcut for passing data between two
> > functions, possibly bringing down the number further.
> >
> > Im toying with the idea of taking on this task if anyone's interested.
> > I may require some tips and help from the forum, in terms of creating a
> > branch, explanation of some statics etc.
> >
> > So how feasible is this? Am I on the right track?
> > Thanks very much,
> > Rob Bairos.
> >
> > ___
> > 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] tcl load-path on OSX builds

[Miller Puckette]

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

[Miller Puckette]

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
>  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]

[Miller Puckette]

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)

[Miller Puckette]

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 :
> 
> > 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

[Miller Puckette]

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 
>   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)

[Miller Puckette]

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)

[Miller Puckette]

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]

[Miller Puckette]

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] width control breaks parsing with [textfile]

[Miller Puckette]

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] remove tk scaling

[Miller Puckette]

> 
> > 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

[Miller Puckette]

[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

[Miller Puckette]

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 
> 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

[Miller Puckette]

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:
> >>  hello. does tk scaling affect canvas items?
> >>   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  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

[Miller Puckette]

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 
> >To: Jonathan Wilkes  
> >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

[Miller Puckette]

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

[Miller Puckette]

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:
>  hello. does tk scaling affect canvas items?
>   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  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

Re: [PD-dev] Mac Os now requiring Apple signatures on all SW !?

[Miller Puckette]

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] Mac Os now requiring Apple signatures on all SW !?

[Miller Puckette]

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 
> > To: Jonathan Wilkes 
> > Cc: Miller Puckette ; "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  wrote:
> >>  - Original Message -
> >> 
> >>>  From: Miller Puckette 
> >>>  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 A

[PD-dev] Mac Os now requiring Apple signatures on all SW !?

[Miller Puckette]

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] new [hip~ ] fixed?

[Miller Puckette]

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

[Miller Puckette]

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

[Miller Puckette]

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

[Miller Puckette]

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

Re: [PD-dev] small regression regarding window placement

[Miller Puckette]

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

[PD-dev] Pi page on Pd developer WIKI?

[Miller Puckette]

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

[Miller Puckette]

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  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

[Miller Puckette]

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

[Miller Puckette]

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

[Miller Puckette]

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] first regression caused by win32 unicode

[Miller Puckette]

Yeah... i need to get mingw up and running here someway :)

M
On Tue, Dec 18, 2012 at 01:34:54PM -0500, Hans-Christoph Steiner wrote:
> 
> It seems to be MinGW-only.  I just submitted a patch to get the 
> makefile.mingw working again.  Were you building with msvc?
> 
> .hc
> 
> On Dec 18, 2012, at 1:54 AM, Miller Puckette wrote:
> 
> > 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

___
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

[Miller Puckette]

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] Win32 - unicode support for files, with public API for externals

[Miller Puckette]

try out what I just pushed which is probably no worse than Hannes's..

cheers
M

On Tue, Dec 18, 2012 at 06:42:17PM +0100, IOhannes m zmoelnig wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 2012-12-18 18:22, Hans-Christoph Steiner wrote:
> > /* 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 }
> 
> yes, that's how i would do it.
> > 
> > 
> > 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".
> > 
> 
> if somebody had to implement sys_fopen() and friends, then i would
> understand why you want to minimize the effort, and replace it with
> ifdef's.
> but check the code: somebody already has implemented sys_fopen(),...
> so there is no reason to save labour time.
> 
> 
> there could be a very simple way to implement sys_open() without all
> the vararg headache. make it:
> > int sys_open(const char*name, int flags, mode_t mode);
> 
> that is, force the users to always supply the mode.
> this would make the header much cleaner (it's clear which arguments
> need to be present).
> 
> this way, sys_open() would not be 100% compatible with POSIX open().
> but afaik the reason for the vararg hell is really, that POSIX decided
> to introduce an extra argument to open() at some later point, and did
> not want to add yet another function.
> open() will happily ignore the 3rd argument if it doesn't need it.
> 
> 
> fgmadrs
> IOhannes
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlDQqvUACgkQkX2Xpv6ydvQMoACgj6qsuUMpGwPkBatyC0Tvf9UF
> lm8Anio5wbFfG0WjPb4CcDU0fgnmaF6z
> =bTtX
> -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] Win32 - unicode support for files, with public API for externals

[Miller Puckette]

OK.. so how's this:

For close I'll just edit in your sys_close hack :)

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)).

I'll hack that in by hand and push to see how it floats :0

M

On Tue, Dec 18, 2012 at 12:35:07PM -0500, Hans-Christoph Steiner wrote:
> 
> Windows is most definitely not POSIX compliant.  If it was, we wouldn't be 
> having this discussion since the Win32 open() would just work.  It has lots 
> POSIX compliant things, but is also missing many key ones.  For example, 
> WIN32 does not define any of the POSIX open() flags (O_CREAT, O_TRUNC, etc.) 
> but instead uses _O_CREAT, _O_TRUNC, etc.  The WIN32 open() permissions flags 
> its uses work differently than POSIX.
> 
> Microsoft marked close() as deprecated in 2005.  It seems worthwhile to heed 
> that.
> 
> The other issue with this patch is the giant warning it gives on Mac OS X:
> s_path.c: In function ‘sys_open’:
> s_path.c:456: warning: ‘mode_t’ is promoted to ‘int’ when passed through ‘...’
> s_path.c:456: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’)
> s_path.c:456: note: if this code is reached, the program will abort
> 
> .hc
> 
> On Dec 18, 2012, at 12:28 PM, Miller Puckette wrote:
> 
> > ... 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

Re: [PD-dev] Win32 - unicode support for files, with public API for externals

[Miller Puckette]

... 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=detail&aid=3596865&group_id=55736&atid=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] first regression caused by win32 unicode

[Miller Puckette]

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] first regression caused by win32 unicode

[Miller Puckette]

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

Re: [PD-dev] [GEM-dev] pix_opencv

[Miller Puckette]

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 :
> > 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] [GEM-dev] pix_opencv

[Miller Puckette]

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] adding a built-in [change] object to the built-in GUI objects

[Miller Puckette]

I'd suggest cacheing the pixel value, not the value value.  It's an easy
fix and I can go through and do it while I'm waiting for other bugs to
surface after trying to make all the 0.44-critical changes on the pile.
(these are resolving my having broken the "new build system" in my impoartation
of portaudio, and also finally acting on the hip~ and inlet~ bugs.)

cheers
Miller

On Fri, Nov 30, 2012 at 11:20:53PM -0500, Hans-Christoph Steiner wrote:
> 
> Lots of patches use the built-in GUI objects for displays, and often a fast 
> stream of events is hooked straight up to the GUI object, causing the GUI 
> object to send many pointless updates, like draw commands when the number 
> hasn't changed, or multiple draw commands per screen refresh cycle.
> 
> I propose to only send the GUI update commands when the relevant value has 
> changed.  I think this should apply to both the main element, like the slider 
> knob, and the label for that GUI object, since that's often used as a 
> display.  The code change is pretty simple, but I was wondering if people 
> thought there could be any problems caused by this
> 
> Here is the needed change, for example, for the hslider knob:
> 
> index b352fb9..88681fc 100644
> --- a/src/g_all_guis.h
> +++ b/src/g_all_guis.h
> @@ -185,6 +185,7 @@ typedef struct _hslider
>  t_iemgui x_gui;
>  int  x_pos;
>  int  x_val;
> +int  x_prev_val;
>  int  x_center;
>  int  x_thick;
>  int  x_lin0_log1;
> index 470771a..e1a3c83 100644
> --- a/src/g_hslider.c
> +++ b/src/g_hslider.c
> @@ -33,7 +33,7 @@ static t_class *hslider_class;
>  static void hslider_draw_update(t_gobj *client, t_glist *glist)
>  {
>  t_hslider *x = (t_hslider *)client;
> -if (glist_isvisible(glist))
> +if (glist_isvisible(glist) && x->x_val != x->x_prev_val)
>  {
>  int r = text_xpix(&x->x_gui.x_obj, glist) + (x->x_val + 50)/100;
>  int ypos=text_ypix(&x->x_gui.x_obj, glist);
> @@ -57,6 +57,7 @@ static void hslider_draw_update(t_gobj *client, t_glist 
> *glist)
>  x->x_thick = 0;
>  }
>  }
> +x->x_prev_val = x->x_val;
>  }
>  }
> 
> 
> 
> ___
> 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] building for Windows on GNU/Linux

[Miller Puckette]

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

Re: [PD-dev] [ pure-data-Patches-3591846 ] portaudio fixes

[Miller Puckette]

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] [ pure-data-Patches-3591846 ] portaudio fixes

[Miller Puckette]

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

[PD-dev] can't seem to get new build system to work

[Miller Puckette]

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

[PD-dev] clearing out "old" build system

[Miller Puckette]

To Pd developers -

I'm finally gearing up to clean out the "old build system" which, I believe,
will entail removing these files from pd/src:

config.h.in
configure
configure.in
install-sh
makefile.clean
makefile.dependencies
makefile.in

... any objections? (i.e. is anyone but me still using this who can't
move forward to the "new' system (cd pd; autogen.sh; ./configure;
make) ?

I'm planning on leaving makefile.nt and makefile.mingw around for luddites,
and also will probably supply a makefile.gnu as a fallback for when,
I predict inevitably, the "new build system" crumbles under its own weight.

cheers
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

[Miller Puckette]

> > 
> > But the question of how to smoothly update table graphics without messing up
> > real-time behavior is still wode open.
> 
> Ideally there would be some way of sharing the table memory with the GUI 
> process.  Then the GUI process would just read that table using the clock of 
> the screen refresh, at something like 60Hz, and handling the drawing itself.  
> Then the DSP code could be totally ignorant of the drawing.  That would also 
> make it easy to set the DSP processing priority higher than the redrawing 
> priority.
> 
> .hc
> 
The difficulty with that is that you'd have to obtain a lock on the table in
order to safely read its contents from the GUI layer - and then, the real-time
layer could block on the lock and you'd get occasional hiccups in performance.

By the time you've made the interface lock-free, as far as I can see, you're
retty much stuck with a fifo of some type.  Admittedly, the way Pd and Tk
handle the fifos is currently laughably inefficint - but that's incrementally
fixable, whereas getting table updates to work well with a FIFO at all is
more fundamental I think.

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

[Miller Puckette]

I don't know any good way to do that.  But in general memory alocation also
should be done in advance if you want robust real-time behavior, so in
practice I'd make a list of the lengths of each readable soundfile in
advance.

cheers
Miller

> >> 
> >>  [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.
> 
> And how do I set the right size for the array?
> 
> -Jonathan
> 
> > 
> > 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

[Miller Puckette]

> 
> 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

[Miller Puckette]

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 
> >>>> 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 
> >>>>>>>   To: pd-dev List 
> >>>>>>>   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 whe

Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array

[Miller Puckette]

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 
> >> 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 
> >   To: pd-dev List 
> >   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] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)

[Miller Puckette]

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  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] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)

[Miller Puckette]

Sure enough... a quick search for dc_calcsize verifies that it's not
used anywhere although set - all the 'ugens' actually look at the allocated
size of input/output signals to determine the number of points to calculate.

I'm not sure how to fix this - and anyway I don't have any real patches that
use this 'feature' that would permit me to test it :)

M

On Tue, Oct 23, 2012 at 07:41:08PM +0200, IOhannes m zmölnig wrote:
> On 10/23/2012 06:30 PM, Miller Puckette wrote:
> >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.
> >
> 
> yes, i'm aware of that.
> i only wanted to say that in real live, i haven't been able to
> construct a patch that would do non-power-of-two processing, even if
> it was in a top-level patch without any fancy input/output.
> e.g. claude's example patch doesn't do non-power-of-two
> block-processing but instead falls back to the next greater 2^n
> blocksize.
> 
> so if somebody (miller?) could post a simplistic patch that really
> does block-processing with an odd number of samples, that would be
> great.
> 
> 
> fgmadsr
> 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] [ pure-data-Feature Requests-3578019 ] I'd like to...

[Miller Puckette]

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] Pd-cvs Digest, Vol 92, Issue 2

[Miller Puckette]

... 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

[Miller Puckette]

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

Re: [PD-dev] coll object in cyclone broken in 0.43; how to submit fix?

[Miller Puckette]

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=revision&sortby=date&revision=15018
> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&sortby=date&revision=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

[PD-dev] coll object in cyclone broken in 0.43; how to submit fix?

[Miller Puckette]

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] [PD] Adding support for "return" inside comments

[Miller Puckette]

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] Adding support for "return" inside comments

[Miller Puckette]

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] [PD-announce] pd 0.43-3 released

[Miller Puckette]

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

[Miller Puckette]

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?

[Miller Puckette]

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

[Miller Puckette]

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  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] Pd on ARM/Gumstix Overo - audio problems

[Miller Puckette]

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

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

Re: [PD-dev] fontwidth and nogui

[Miller Puckette]

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] fontwidth and nogui

[Miller Puckette]

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] Can anyone on windows 7 confirm TCL bug?

[Miller Puckette]

On Fri, Feb 10, 2012 at 12:12:42PM -0500, Hans-Christoph Steiner wrote:
> 
> On Feb 10, 2012, at 4:24 AM, Roman Haefeli wrote:
> 
> > Hi Miller
> > 
> > On Thu, 2012-02-09 at 09:21 -0800, Miller Puckette wrote:
> >> To Pd dev -
> >> 
> >> Several of my students have windows 7, on which the TCL line
> >> "package require registry" seems to fail (not able to find or load
> >> the file tclreg12.dll).  I put a report on Sourceforge:
> >> 
> >> http://sourceforge.net/tracker/?func=detail&aid=3484492&group_id=55736&atid=478070
> >> 
> >> Woed any of you have ready access to a windows 7 mchine to see if you
> >> can replicate this?  I don't have one and it might be a while before I can
> >> get hold of one.
> > 
> > I can confirm this problem. Here is what I get in the Pd-window:
> > 
> > [snip]---
> > 
> > This on Windows 7 Enterprise SP1 with Pd-0.43.1.
> > 
> > I didn't have time to 'play' with the problem. If there is anything
> > specific I can test, please let me know.
> 
> 
> Can you tell me if Pd-extended 0.43 is also affected?
> 
> .hc
> 

I don't know - I'll e-mail one of the reporting students and see if I
can find out.

cheers
M

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

[PD-dev] Can anyone on windows 7 confirm TCL bug?

[Miller Puckette]

To Pd dev -

Several of my students have windows 7, on which the TCL line
"package require registry" seems to fail (not able to find or load
the file tclreg12.dll).  I put a report on Sourceforge:

http://sourceforge.net/tracker/?func=detail&aid=3484492&group_id=55736&atid=478070

Woed any of you have ready access to a windows 7 mchine to see if you
can replicate this?  I don't have one and it might be a while before I can
get hold of one.

thanks
Miller

___
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?

[Miller Puckette]

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

Re: [PD-dev] broken msgs cause Tcl traces, how to debug it?

[Miller Puckette]

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] font size tweak pushed to git... comments?

[Miller Puckette]

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 Gr"af
> 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

[PD-dev] font size tweak pushed to git... comments?

[Miller Puckette]

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] per-thread storage in Pd in support of pdlib - discussion?

[Miller Puckette]

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  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] per-thread storage in Pd in support of pdlib - discussion?

[Miller Puckette]

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] deadly leak

[Miller Puckette]

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

[Miller Puckette]

> 
> 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()

[Miller Puckette]

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
> here)
> 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
> here,
> 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?

[Miller Puckette]

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

[Miller Puckette]

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] Pd-extended-0.43 appearance

[Miller Puckette]

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] removing path and libs from Pd-extended preferences GUI

[Miller Puckette]

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 everyth

Re: [PD-dev] removing path and libs from Pd-extended preferences GUI

[Miller Puckette]

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

[Miller Puckette]

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"
>  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

[Miller Puckette]

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] pd-0.43.0 port to NetBSD

[Miller Puckette]

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 
> -#elif ! defined(_MSC_VER)
> -#include 
> -#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 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -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 
>  #include 
>  #include 
> -#ifdef _WIN32
>  #include 
> -#elif ! defined(_MSC_VER)
> -#include 
> -#endif
>  #include 
>  #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

Re: [PD-dev] preparing phasor~&Co. for double precision Pd

[Miller Puckette]

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] replace spaces in list class names with hyphens

[Miller Puckette]

I think that's the only one.

cheers
M

On Fri, Jul 15, 2011 at 02:00:07PM -0400, Hans-Christoph Steiner wrote:
> 
> Besides [list], what are other exceptions to the rule of the class
> being all characters before the first space?  It might just be
> easier to code in an exception for [list].
> 
> .hc
> 
> On Jul 15, 2011, at 1:41 PM, Miller Puckette wrote:
> 
> >THere isn't a 1-to-1 correspondence between the string that invokes an
> >object and its class -- hence, "list" can give rise to several
> >different
> >classes, but also, there are sometimes multiple classes in Pd that
> >have
> >the same "class name", like "select".  The string was originally only
> >there to help in pringing out error messages, (i.e. human
> >readable), not
> >as a way to disamiguate anything.
> >
> >I think the only way to know everything relevant is to know the whole
> >argument list and parse it, ouch...
> >
> >cheers
> >Miller
> >
> >On Fri, Jul 15, 2011 at 09:46:38AM -0700, Jonathan Wilkes wrote:
> >>
> >>
> >>--- On Fri, 7/15/11, IOhannes m zmölnig  wrote:
> >>
> >>>From: IOhannes m zmölnig 
> >>>Subject: Re: [PD-dev] replace spaces in list class names with
> >>>hyphens
> >>>To: pd-dev@iem.at
> >>>Date: Friday, July 15, 2011, 10:18 AM
> >>>-BEGIN PGP SIGNED MESSAGE-
> >>>Hash: SHA1
> >>>
> >>>On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
> >>>>I've got a working tooltip prototype going, and I just
> >>>noticed that all the list classes screw up things on the tcl
> >>>side, because with "list append" (for example) it suddenly
> >>>looks like there is one more arg to the proc.
> >>>>
> >>>>Are there any other objects that have a space in the
> >>>creator name?  If not, could we just make it official
> >>>that creator names can't have spaces, and change all the
> >>>"list foo" creators objects to "list-foo"?
> >>>>
> >>>>This would be transparent to the user*, since they can
> >>>still type "list foo" and list_new will instantiate the
> >>>right class.  (Although going forward I would suggest
> >>>using "list-foo" as it is the standard for all the listabs
> >>>abstractions.)
> >>>>
> >>>
> >>>while i was always opposed to using object names with
> >>>spaces [1], i
> >>>don't think that we should forbid it at all. i would rather
> >>>have the GUI
> >>>side have an idea of what is the object name and what are
> >>>the arguments
> >>>(e.g. "create {list split} {1}" rather than "text list
> >>>split 1") than to
> >>>add arbitrary limitations.
> >>>
> >>>some externals use "proxy objects" for full-fledged
> >>>non-first inlets,
> >>>and those proxies tend to have "hard to type" names as
> >>>well. how do your
> >>>tooltips deal with those?
> >>
> >>So if object "foo" has a 2nd inlet controlled by a proxy object
> >>"bar", which class is referred to by t_object *ob of
> >>glist_drawio in g_text.c: foo or bar?
> >>
> >>>
> >>>gfmasdr
> >>>IOhannes
> >>>
> >>>[1]
> >>>https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
> >>>-BEGIN PGP SIGNATURE-
> >>>Version: GnuPG v1.4.11 (GNU/Linux)
> >>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >>>
> >>>iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
> >>>EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
> >>>=XO7J
> >>>-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
> 
> 
> 
> 
> 
> 
> 
> "[T]he greatest purveyor of violence in the world today [is] my own
> government." - Martin Luther King, Jr.
> 
> 
> 
> 
> ___
> 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] replace spaces in list class names with hyphens

[Miller Puckette]

THere isn't a 1-to-1 correspondence between the string that invokes an
object and its class -- hence, "list" can give rise to several different
classes, but also, there are sometimes multiple classes in Pd that have
the same "class name", like "select".  The string was originally only
there to help in pringing out error messages, (i.e. human readable), not
as a way to disamiguate anything.

I think the only way to know everything relevant is to know the whole
argument list and parse it, ouch...

cheers
Miller

On Fri, Jul 15, 2011 at 09:46:38AM -0700, Jonathan Wilkes wrote:
> 
> 
> --- On Fri, 7/15/11, IOhannes m zmölnig  wrote:
> 
> > From: IOhannes m zmölnig 
> > Subject: Re: [PD-dev] replace spaces in list class names with hyphens
> > To: pd-dev@iem.at
> > Date: Friday, July 15, 2011, 10:18 AM
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
> > > I've got a working tooltip prototype going, and I just
> > noticed that all the list classes screw up things on the tcl
> > side, because with "list append" (for example) it suddenly
> > looks like there is one more arg to the proc.
> > > 
> > > Are there any other objects that have a space in the
> > creator name?  If not, could we just make it official
> > that creator names can't have spaces, and change all the
> > "list foo" creators objects to "list-foo"?
> > > 
> > > This would be transparent to the user*, since they can
> > still type "list foo" and list_new will instantiate the
> > right class.  (Although going forward I would suggest
> > using "list-foo" as it is the standard for all the listabs
> > abstractions.)
> > > 
> > 
> > while i was always opposed to using object names with
> > spaces [1], i
> > don't think that we should forbid it at all. i would rather
> > have the GUI
> > side have an idea of what is the object name and what are
> > the arguments
> > (e.g. "create {list split} {1}" rather than "text list
> > split 1") than to
> > add arbitrary limitations.
> > 
> > some externals use "proxy objects" for full-fledged
> > non-first inlets,
> > and those proxies tend to have "hard to type" names as
> > well. how do your
> > tooltips deal with those?
> 
> So if object "foo" has a 2nd inlet controlled by a proxy object "bar", which 
> class is referred to by t_object *ob of glist_drawio in g_text.c: foo or bar?
> 
> > 
> > gfmasdr
> > IOhannes
> > 
> > [1]
> > https://sourceforge.net/tracker/index.php?func=detail&aid=1544083&group_id=55736&atid=478072
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > 
> > iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
> > EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
> > =XO7J
> > -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] struct _canvasenvironment

[Miller Puckette]

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] struct _canvasenvironment

[Miller Puckette]

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  wrote:
> 
> > From: IOhannes m zmoelnig 
> > 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] [PD] is OOURA fft algorithm still used?

[Miller Puckette]

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  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] tcl registry pd-0.43

[Miller Puckette]

Hmmm.  yep, maybe the right policy would be simply to throw all of tk/tcl
in Pd... I've been trying to avoid bloat but there's a real potential for
lots of features breaking on Pcs if I try to hold to the policy of "only
include what is being used".

I have to crank up my PC anyway to see about a bug report (asio4all seems
not to work with 0.43) but probably won't be able to get to it this weekend -
I have lots of bureaucrap awaiting me...

cheers
Miller


On Sun, Apr 10, 2011 at 12:31:30PM -0400, Hans-Christoph Steiner wrote:
> 
> On Apr 7, 2011, at 3:13 AM, yvan volochine wrote:
> 
> >On 04/06/2011 08:04 PM, Hans-Christoph Steiner wrote:
> >>
> >>According to the Tcl/Tk 8.4 docs, it should be included. What if you
> >>just try to use 'registry' without the 'package require registry'?
> >>
> >>http://tcl.tk/man/tcl8.4/TclCmd/registry.htm
> >
> >it should but it's not.
> >running tclsh84.exe shipped with pd-0.43 win binary:
> >
> >package require registry
> >>> "Unknown command registry"
> 
> 
> Miller, do you think you could add the libs that come with Tcl/Tk to
> your included  version?  There are two folders called 'reg1.2' and
> 'dde1.3' that should go into pd/lib directly, they come with Tcl/Tk
> in tcl/library/.  These will also be needed to support making a
> double-clicked file open in the currently running instance of Pd.
> Really everything in tcl/library/ should be included so we have a
> full Tcl/Tk install.
> 
> Yvan, it should also be possible to include the 'reg1.2' folder in
> your plugin folder for making a plugin that people can use now.  I
> think its just a matter of adding the local folder to the auto_path,
> so adding something like this to the plugin:
> 
> set auto_path [linsert $auto_path 0 \
>   [file join $::current_plugin_loadpath "openrecent-plugin"]
> 
> .hc
> 
> 
> 
> 
> 
> 
> "Free software means you control what your computer does. Non-free
> software means someone else controls that, and to some extent
> controls you." - Richard M. Stallman
> 
> 
> 
> ___
> 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

[Miller Puckette]

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] Finding overlap

[Miller Puckette]

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