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

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

[PD-dev] libpd partly working with pd instances

To Pd developers... I've adapted Pd to nternally use a "pdinstance" structure to allow multiple schedulers (including DSP chains) to run in one address space. With slight modification (see below) libpd can use this to run separate patches asynchronously. I tried to "instance-ize" all Pd symbols t

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

I THink it should really be: if((x->x_file = sys_fopen(filename->s_name, "r")) == 0) sys_fopen returns NULL (also known as 0) on failure, otherwise a pointer; it makes no sense to check the sign of a pointer as far as I know. cheers Miller On Fri, Apr 04, 2014 at 11:21:37PM -0400, Martin Peach

Re: [PD-dev] libpd iOS 64 bit crash with variadic function pointers

e_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/t

Re: [PD-dev] libpd iOS 64 bit crash with variadic function pointers

Hi all - I think pd dev is the good place... somehow I missed the first mail but am thinking about this one. It looks like the whole mess1() (etc) macro system is going to fail on 64-bit ARM - I can't see how to patch that. I can fix the local problems in the Pd vanilla source but I don't know w

Re: [PD-dev] Multiple Instance of pdlib

t; > > > 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 enoug

Re: [PD-dev] Multiple Instance of pdlib

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 do

Re: [PD-dev] tcl load-path on OSX builds

What I do for things like this: In Pd, open the file with canvas_open() which returns the directory the file was found in; close it again without using it; pass the full patthname to tcl, or wherever, to use. An example in Pd source is binbuf_read_via_canvas() cheers Miller On Wed, Oct 09, 20

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

THanks all for this... I went ahead and patched it (Claude's way, but with an explanatory comment :) On Wed, Sep 11, 2013 at 08:53:12PM +0200, Kjetil Matheussen wrote: > On Tue, Sep 10, 2013 at 8:40 PM, Claude Heiland-Allen > wrote: > > Hi Kjetil, > > > > In my own code I tend to exploit the inco

Re: [PD-dev] portaudio callback problem [WAS:Re: [PD] PA_Terminate]

Hi Patrice - I actually don't have any working ASIO devices which makes it hard for me to figure out what's wrong here. I'll make another attemot to get something installed in the next week or so. Meanwhile, am I reading this right that you get different results depending on whether you put the

Re: [PD-dev] Midi overflow, when receiving Song Position Pointer (os x)

]: *** [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 >

Re: [PD-dev] [pure-data:patches] #513 automake build fixes

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

Re: [PD-dev] Midi overflow, when receiving Song Position Pointer (os x)

OK... maybe got it working now (should be in git repo). THanks for flagging it. M On Fri, Jul 05, 2013 at 04:36:46PM -0700, Miller Puckette wrote: > Hmm... just looking at the code in s_midi_pm.c I can't understand how > it could ever have worked for sysex or 'system' messa

Re: [PD-dev] Midi overflow, when receiving Song Position Pointer (os x)

Hmm... just looking at the code in s_midi_pm.c I can't understand how it could ever have worked for sysex or 'system' messages. I'll see if I can get MIDI running on a MAC so I can try to fix it. cheers Miller On Wed, Jun 05, 2013 at 01:59:45PM +0200, Jan Baumgart wrote: > I've found the bad guy

Re: [PD-dev] width control breaks parsing with [textfile]

On Wed, Jul 03, 2013 at 09:09:26PM +0200, Roman Haefeli wrote: > On Mit, 2013-07-03 at 08:58 -0700, Miller Puckette wrote: > > Just to stir the pot, as it were :) - > > > > The 'f' message is intended to mean 'format' and could be expanded to >

Re: [PD-dev] width control breaks parsing with [textfile]

Just to stir the pot, as it were :) - The 'f' message is intended to mean 'format' and could be expanded to specify font style and size, and/or other formatting info (perhaps even to suppress carriage return on semi, think of that!) cheers Miller On Wed, Jul 03, 2013 at 02:48:30AM -0400, Jonatha

Re: [PD-dev] remove tk scaling

> > > Anyhow, if by separating the GUI from the core you mean re-writing the Pd > > patch > > editor in Tcl/TK, I think that would create enormous headaches. i enjoyed > > some of those with Max/FTS (in which the GUI layer was responsible for > > editing) and Pd's separation of duties is partly

Re: [PD-dev] remove tk scaling

[discussion of tk scaling deleted...] > What do you gain by removing in? I think we really need to stop wasting time > on little details like this, and instead work towards real fixes. Does anyone > object to the idea of truly separating the GUI from the core? I haven't heard > them. > > .hc >

Re: [PD-dev] remove tk scaling

I looked and every font specification I could find in Pd vanilla has its size specified as negative. So I'm of the belief that taking the "tk scaling 1" out will have NO EFFECT on the sizes of drawn text on canvases in vanilla. Only gotchas I can imagine are: (1) maybe there's something else besi

Re: [PD-dev] remove tk scaling

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

Re: [PD-dev] Message dispatching system

t'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: > > > > > ______

Re: [PD-dev] Message dispatching system

It's a general rule - it was the easiest way to code it portably. If you wanted to truly intersperse floats and integer/pointers you'd have something like a 32-case switch statement to generate the function calls. cheers Miller On Mon, May 20, 2013 at 01:41:06PM -0400, Jonathan Wilkes wrote: > H

Re: [PD-dev] remove tk scaling

Hi Jonathan et a - I've never understood the reason tk_scaling is touched in the TK code and unless someone else objects I'll try taking it out of the vanilla source. thanks Miller On Tue, Jun 11, 2013 at 06:11:57PM -0700, Jonathan Wilkes wrote: > Hi list, > > From tcl/pd-gui: >     # we are no

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

That sounds sensible... sounds like I can probably do nothing for now (but I'm worried they're going to progressively lock things down harder in the future... this isn't going in a good direction!) M > Again, that adds credibility to a system that adds little more than a pain for > users, and it

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

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

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

To Pd devs - I heard from a student that the neweset Mac Os (10.8? not sure - perhaps we can just call it 'Cheshire Cat') won't run binaries of any sort that haven't been signed by Apple - and that to get Apple to sign your app you have to register as a developer ($100/year) and still risk getti

Re: [PD-dev] new [hip~ ] fixed?

This seems strange to me too - I believed I had hip~ set up to have a gain of 1 at Nyquist - but now that I try it it seems not to be true! I need to look at this and figure out what went wrong. Thanks for flagging this... Miller On Tue, Mar 12, 2013 at 10:12:14PM +0100, Roman Haefeli wrote: >

Re: [PD-dev] potential memory leak in g_graph.c

I don't remember why it's there (and perhaps it's no longer necessary) - but I suspect it had something to do with a subtle problem when deleting a GOP whose interior got mad wieh there was no rtext for the owning object. The rtext eventualy goes away when the window is closed - but perhaps it's a

Re: [PD-dev] sysex/midiin and port numbers

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

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

w 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

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

Drat.. On Macintoshes, if you ask for a window to open at Y location 0 the window decorations end up above teh top of teh screen and you can never move the window. but anyhow I don't understand why the saved patch location gets overridden by the default - I thought the default was only in effect

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

To Pd dev - I'm leading a seminar of graduate students who are trying out various things on the Pi (audio; USB; GPIO; etc) - would it be appropriate for us to start a age on the Pd Dev wiki (http://puredata.info/dev) to collect experiences? I'd be happy to try to get that going unless there's some

Re: [PD-dev] [PD] libpd netreceive

I'm not sure but I believe it should work if you periodically call sys_domicrosleep(0, 1) - this asks it not to sleep at all but just to poll all the FDs Pd is watching. cheers Miller On Sat, Jan 26, 2013 at 11:16:41PM -0500, Rich E wrote: > On Mon, Jan 21, 2013 at 11:30 AM, Thomas Grill wrote:

Re: [PD-dev] sysex/midiin and port numbers

I _think_ it would be safe to change this... anyone know of any way that would break compatibility? thanks M On Tue, Jan 08, 2013 at 02:58:41PM -0500, Peter Brinkmann wrote: > Hi, > I've been revisiting the MIDI support of libpd, and I noticed that the > functions inmidi_byte and inmidi_sysex add

Re: [PD-dev] from t_symbol to t_class

Sure - canvas_finderror() is an example of how to go through every object in the whole Pd process. cheers M On Fri, Jan 04, 2013 at 09:36:42AM -0800, Jonathan Wilkes wrote: > > I'd prefer to just inspect the class without creating a new instance but I > can't > figure out how. >   > Are all t_g

Re: [PD-dev] from t_symbol to t_class

I think you're safe calling vmess() to pass no arguments to clip_new (for example) - the worst that can happen is the "return value" (the global "newest" is zero. If not it's a proper Pd object you can use zgetfn() on to test it for messages. Main problem I see with this is that some classes like

Re: [PD-dev] first regression caused by win32 unicode

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

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

OK... my suggestion would be just to try not to worry about Solaris :) M On Tue, Dec 18, 2012 at 06:54:29PM +0100, IOhannes m zmoelnig wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2012-12-18 18:44, Miller Puckette wrote: > > OK.. so how's this: >

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

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

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

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

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

... but if POSIX has a close() I think there's no issue here - MSW is POSIX compliant, they say, and hence they're committeed to maintaining close(). So I think it's fine just to use close() and not have a sys_close() at all (or if someone is actually using sys_close() we choud just: > int sys_clo

Re: [PD-dev] first regression caused by win32 unicode

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 &

Re: [PD-dev] first regression caused by win32 unicode

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

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

gt; 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 e

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

I tried and was able to make Gem externals that worked on linux and Mac OS, but on Windows I wasn't able to link eternals that needed Gem symbols. This was years ago though, and anyway I might have been missing something :) m On Wed, Dec 12, 2012 at 01:19:04PM -0500, Hans-Christoph Steiner wrote:

Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects

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

Re: [PD-dev] building for Windows on GNU/Linux

yeah, one of the reasons I'm trying wine out is so I can have both MSVC and mingw running (and be sure they don't step on each others' toes, which I can do by setting up separate "disks" for them to live on). Amazingly, I can even run Pd in wine, although I haven't tried to do anything with it.

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

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

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

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

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

To pd-dev - I might be missing something... under Fedora 17 (the newest I believe), when I try to build Pd using the "new build system" I get: [msp@fuzz pd]$ ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4/gene

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

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

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

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

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

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 yo

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

> > Why not use the same throttling mechanism Miller put for data structures > for iemguis and see if it's suitable? > > I think what you'll find is that this is a complex problem, and you certainly > won't get a consensus that "just make the gui get out of the way for the > sound" > is the righ

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

e 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 > > &g

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

THe whole edifice needs to be reworked I'm afraid... but it's a big project which I haven't yet been able to get started on. cheers M On Thu, Oct 25, 2012 at 04:37:53PM -0400, Hans-Christoph Steiner wrote: > > I can see a reason to rate limit the updates, but totally stopping them seems > really

Re: [PD-dev] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)

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 num

Re: [PD-dev] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)

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

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

Hi all - block sizes in subpatches are restricted to being a power of two multiple or submultiple of the containing patch. So the only context in which a non-power-of-two blocksize is allowerd is if it's specified in the top-level patch. Then, of course, dac~ and adc~ will no longer work as they

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

... so if -ffast-math is already turned on in pd extended I think it's a fortiori safe to turn it on in vanilla :) Miller On Wed, Oct 03, 2012 at 08:28:38AM -0700, Miller Puckette wrote: > I have to think about thi one a little... nobody could ever test -fastmath > for all architec

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

I have to think about thi one a little... nobody could ever test -fastmath for all architectures. The danger I see is that some externals might break. Maybe I should just leve it on during the 0.44 test phase and hope I hear back if it's breaking things :) The reason for putting it in is that I

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

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

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

To Pd developers... In testing the coll object from cyclone/hammer I found some trouble adapting from 0.42 to 0.43. I had no trouble fixing it locally (I'll show a diff below) but would like now to know how I can best make this available to others. Would it be netter that I (a) submit a patch to

Re: [PD-dev] [PD] Adding support for "return" inside comments

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

Re: [PD-dev] Adding support for "return" inside comments

Hi Ico - I gave that a bit of thought and concluded it would be best to do that as a separate object (because comments are highly integrated with messages/objects/atoms and changing on of them would reverberate everywhere). cheers Miller On Wed, Aug 01, 2012 at 09:16:23PM -0400, Ivica Ico Bukvic

Re: [PD-dev] [PD] [PD-announce] pd 0.43-3 released

Also... I think OSS/MIDI is the only API now that lets you spit out arbitrary byes over the MIDI line -- all the others 'protect' you. cheers Miller On Wed, Jul 04, 2012 at 08:43:50PM +0200, Cyrille Henry wrote: > > > Le 04/07/2012 09:51, IOhannes m zmoelnig a écrit : > > >furthermore, Pd supp

Re: [PD-dev] open_via_path / close file - WIndows CRT problems

It's a workaround, yes.. but it's frequently necessary even within Pd where "open" wasn't really the desired function but one still needed to travers the search path to find a readable file. There ought to be a better way but I don't know what it is. An example is binbuf_read_via_canvas(). On an

Re: [PD-dev] compiling to DSP processor?

It should be possible but Pd needs stuff like open(), read(), and write() for files, so it's necessary to make a small library to either carry out or somehow fake those operations. The great advantage of running Pd on a DSP is that you can probably get audio latencies down much further than on a P

Re: [PD-dev] Pd on ARM/Gumstix Overo - audio problems

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

Re: [PD-dev] Pd on ARM/Gumstix Overo - audio problems

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 Mill

Re: [PD-dev] fontwidth and nogui

That it's painful doesn't make it any less funny to me. It would take pages to explain the considerations that went, in 1987 or early 1988, into the decision to arrange inlets/outlets that way but the circumstances were quite different from today's - and seeing this particular unintended consequ

Re: [PD-dev] fontwidth and nogui

It's hilarious - there's exactly one aspect of Pd run-time semantics that depends on screen location -- inlets/outlets of subpatches are numbered in left-to-right order on teh screen. To to thins someone has to call gobj_getrect() on the inlet/outlet, which then not only has to report the northwes

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

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

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

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 h

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

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 calle

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

Quick guess; the socket itself (at the OS level) has a fixed buffer size and if the sending process exceeds it it is suspended until the receiving process eats at least some of it. The receiving process is thus handed a truncated buffer. There's not much way around this. One possibility (if inde

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

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

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

Also to pd-dev - I noticed font sizes changed from 0.42 to 0.43 and tried to tweak them back to 0.42-style, by having the new font-size-search code in pd-gui.c actually try to find the font sizes that s_main.c later searches (redundantly) for. I should have done this earlier. If this doesn't br

Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?

wheel 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

[PD-dev] per-thread storage in Pd in support of pdlib - discussion?

To Pd dev - For some time the good folks who brought us pdlib have been asking how one could make it possible to run several instances of Pd in a single address space. The question I'd like to rais is this: would it suffice to make Pd instances be per-thread? This could be done by going through

Re: [PD-dev] deadly leak

Personally, I'm hoping to put band-aids on as many manaifestations of the problem as I can track down (so thanks for this one :) and then re-design the whole editor creation and destruction strategy for 0.44 - it looks like it can never be fully debugged the way it's stet up now! Miller On Thu,

Re: [PD-dev] help compiling pd 0.43 on Windows 7

> > Um... is MSVC free? > Same deal as Microsoft Windows as a whole... cheers M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] libpd crasher bug from recent change to glist_delete()

Hi Rich and all - I think I've tracked that down and fixed it... I just now pushed the change to the git repo. cheers Miller On Sun, Nov 27, 2011 at 11:15:46AM +1100, Rich E wrote: > I just wanted to point out that the recent change to glist_delete() (commit > here

Re: [PD-dev] maximum array display size 2000 points?

Hi all -- There's indeed a limit of 2000 (if drawn as points) or 1000 (if as a polygon) -- this is in lines such as: if (ndrawn > 2000 || ixpix >= 3000) break; and if (ndrawn >= 1000) goto ouch; in plot_vis() in g_template.c. I don't know how far Tcl/Tk can

Re: [PD-dev] Pd-extended-0.43 appearance

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

Re: [PD-dev] Pd-extended-0.43 appearance

Last I checked things were completely inconsistent and no version ("normal" or extended) got the same font sizes across platforms. If anyone can figure out how to make that work robustly I'm all for it. One headache is that I've tried to make PD use natively available fonts which everyone will ha

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

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 lat

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

I'm not sure this really happens but... if you add startup loads to preferences through Pd venilla, then if they don't load or crash for Pd extended, this would be made more confusing if the libraries weren't visible from a dialog somewhere. On the other hand, you could fix fix Pd extended actuall

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

Hi Hans - Perhaps better would be to make it read-only so one can query it. I'm not sure, but there still might be complications for people switching back and forth between vanilla and extended, for example, which would be easiest to resolve if the GUI tools were there :) M On Sun, Sep 18, 2011

Re: [PD-dev] pd-0.43.0 port to NetBSD

Oh... that's good news. I think I'd better pump 0.43-1 out first and then apply this for 0.42 since if there are more tweaks needed it will take time for them to become apparent. cheers Miller On Sat, Sep 17, 2011 at 01:22:21AM +0200, Thomas Klausner wrote: > Hi Miller, > > > I can't evaluate t

Re: [PD-dev] pd-0.43.0 port to NetBSD

Hi all -- I can't evaluate the changes here that have to do with the build system but can work on getting rid of alloca dependencies. I didn't know there were any platforms left that didn't support alloca. (In fact I was celebrating that I would be able to replace more malloc calls with alloca t

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

Hi all -- I'm not sure it's done right, but my intention in s_audio_pa.c is to use 'float' when talking to the portaudio API and t_sample to talk to the rest of Pd -- so t_sample could be made double without affecting portaudio. The only situation I can imagine in which t_sample might want to

Re: [PD-dev] replace spaces in list class names with hyphens

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

Re: [PD-dev] replace spaces in list class names with hyphens

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

Re: [PD-dev] struct _canvasenvironment

Oops, yep, that's what I meant... typed too fast. cheers M > > Did you mean canvas_getdir? If that's the case I think I'm safe, since I'm > only using it if the canvas in question is an abstraction. (And it's an > absolute path.) I don't think this would lead to any problems. > > Also, in

Re: [PD-dev] struct _canvasenvironment

It's in m_pd.h - that's a pretty good guarantee of stability (although not 100% perfect I'm afraid.) One caution -- if soneone 'saves' the patch into a new directory, the canvas's directory will then change -- so it's best not to store the result of canvas_settid() but to call it each time it gets

Re: [PD-dev] [PD] is OOURA fft algorithm still used?

Hmm, I think Pd is using both OOURA and Mayer, which have different APIs, because I haven't taken the time to rewrite the Mayer API to use OOURA. cheers Miller On Sun, May 29, 2011 at 12:34:36PM +1000, Rich E wrote: > So is it just in there so that you can compile it in if you feel like > chang

Re: [PD-dev] tcl registry pd-0.43

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 b

Re: [PD-dev] erase object text

Can't be done -- the actual text editing is done in Pd and the TCL code is just to display the current state of affairs down in Pd. There might be a way to do it via messages to Pd though -- for instance, simlulating the necessary mouse/keyboard actions. cheers Miller On Fri, Apr 01, 2011 at 08:

Re: [PD-dev] Finding overlap

Unfortunately not. I've been planning to make this possible for many years but the details get confusing. cheers Miller On Fri, Apr 01, 2011 at 01:10:42PM +0100, Andrew Hassall wrote: > Is it possible to find the signal overlap within an external, I know > you can find the length and sample rate

  1   2   3   >