(kinda thinking aloud here)
I guess one of the things that made [ipoke~] work so well (and easy) was
that there was already an ongoing discussion and a readymade group of
interested and able people involved. Although Katja very much did all the
porting the discussion element was crucial. So
( it seems that I had troubles sending this email, so I re-sent it, sorry )
Hi list,
I'm running Pd-extended 0.43.1 with Openbox on Debian Wheezy, and I'm
experiencing some strange windows behaviours.
If I create a new patch, the patch's window is displayed in the top-left
corner, in a way
Hi Nicola,
Probably not much help but I was having exactly this issue on a Raspbian
RPI I was testing with a couple of weeks ago, I'd forgotten until your post
reminded me. Not had time to return to the problem atm but would be well
up for a solution.
Here's hoping.
Julian
BTW First email
I just added Pd-extended beta packages to apt.puredata.info for Ubuntu
oneiric and precise, both 32-bit (i386) and 64-bit (amd64). That means
that apt.puredata.info now has 32-bit (i386) and 64-bit (amd64) builds
for every Ubuntu release since jaunty 9.04. This also covers all recent
Linux Mint
The problem is caused by how Tk and X11 measures window frames: it
measures it including all of the chrome around the window (the
button/title bar on the top, any framing on the bottom, etc.) The
window framing/chrome varies a lot depending on which window manager,
etc. you are using.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-10-02 16:23, Hans-Christoph Steiner wrote:
I just added Pd-extended beta packages to apt.puredata.info for
Ubuntu oneiric and precise, both 32-bit (i386) and 64-bit (amd64).
That means that apt.puredata.info now has 32-bit (i386) and
On 09/28/2012 11:43 AM, Claude Heiland-Allen wrote:
On 28/09/12 16:23, Miller Puckette wrote:
Well, I'm persuadable on this front. I'm concerned with unduly hogging
the object namespace - in general, every time I add an object name I
potentially introduce incompatiblities with someone's
I assume it doesn't - I run Pd in 64 and 32 bits depending on the machine
I'm on but always with 32-bit floating point numbers (for the slight gain in
speed :)
Miller
On Tue, Oct 02, 2012 at 04:53:42PM +0200, IOhannes m zmoelnig wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On
On 10/02/2012 10:56 AM, Hans-Christoph Steiner wrote:
On 09/28/2012 11:43 AM, Claude Heiland-Allen wrote:
On 28/09/12 16:23, Miller Puckette wrote:
Well, I'm persuadable on this front. I'm concerned with unduly hogging
the object namespace - in general, every time I add an object name I
This is in my long-range plan but hasn't yet risen to the level of urgent.
However, this migth be a good moment to get started on this because several
other backward- and even forward-imcompatible needs are also rising to the
fore:
1. there's a bug in hip~ - its DC gain is slightly (and possibly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-10-02 17:15, Miller Puckette wrote:
3. the upsampling inlet~ by default zero-pads its input. This is
incorrect as its DC gain is less than one. (Try using that as
input to a phasor~ for instance - bad surprise!) I want to change
the
in regards to (3), would there have ever been a case where someone would
have deliberately used the zero padding of upsampled inlet as a 'feature'
that their patch depended on
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
I think having a compatibility version stamp in the patch is a good
idea. This ties in well with the experiments I've been doing with
splitting out all of the objects from pd itself. If all of the core
objects are a standard library, then that means its easy to choose which
version of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-10-02 17:15, Miller Puckette wrote:
2. There's no place in the pre-0.43 file format to alow specifying
individual box widths and font sizes; I put an f (=format)
message to the canvas object in 0.43 so that in 0.44 I can make it
set font
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/02/2012 10:53 AM, IOhannes m zmoelnig wrote:
On 2012-10-02 16:23, Hans-Christoph Steiner wrote:
I just added Pd-extended beta packages to apt.puredata.info for
Ubuntu oneiric and precise, both 32-bit (i386) and 64-bit (amd64).
That
I tried to compile on Raspbian wheezy adding deb-src
http://archive.raspbian.org/raspbian; to step 4, as suggested by someone on
your comments.
But in step 5, i get this error:
rsync: failed to connect to 128.238.56.50 (128.238.56.50): Connection
timed out (110)
rsync error: error in socket IO
-extended_0.43.3~20121002-source.tar.bz2
wget
http://blinky.at.or.at:/auto-build/2012-10-02/Pd-extended_0.43.3~20121002-source.debian.tar.bz2
tar xjf Pd-extended_0.43.3~20121002-source.tar.bz2
cd pd-extended
tar xjf ../Pd-extended_0.43.3~20121002-source.debian.tar.bz2
debuild -uc -us
ls -l ../pd
On Tue, Oct 2, 2012 at 5:05 PM, Aaron Thompson
aaron.thomp...@live.co.uk wrote:
Hi Katja,
Thanks for the reply. That seems to have fixed the problem, thanks!
With regards to using the FIR as a fractional delay filter, i'm assuming the
delta float (which feeds to the coefficient calculations)
I'm not sure that any of the Windows, MaacOS, and linux dynamic loading
systems will support having multiple versions of a library loaded in the
same address space. But here's a simpler way anyhow: libraries such as
vanilla could maintain compatibility by querying the version number of
the patch
speaking of #A: would it add any incompatibility, if the
array-loading mechanism could be extended to _all_ objects.
e.g. if an array is saved in-patch, we get something like
snip
#X array array1 3 float 3;
#A 0 -0.5 -0.3 -0.1;
#X array array2 3 float 3;
#A 0 0.5 0.3 0.1;
/snip
Since Pd manually loads the libraries (.pd_linux), it can also manually
map a given function address to the s_thing in the symbol table. There
is no need to load the symbols in a .pd_linux in the sense of a public
shared library, and therefore no nameclashes. Pd could get the address
of the
But there's the trickier problem that static variables would be shared
across all the versions - avan if you can somehow not get different
functions ala sighip_setup() with the same names not to step all over each
other (I'm not convinced that's possible).
Somehow the c library (libc) and the
Actually I think my previous post was wrong - what I was unable to do was
get different sets of static variables for dlopen() - ing the _same file
twice_ -- which isn't what we're talking about here.
But still, I think the libc way is much simpler and likely to be much more
robust.
cheers
M
On
Is the static variable you are talking about the static t_class
declaration in the class C files?
What's the libc way?
The -pre-0.44-hip way would be easy to implement, but it has a number of
problems:
- there will be many flags like this, -pre-0.42-pow, etc. etc.
- there will be no way to
The libc way is just to have one libc and kludge your way through
compatibility problems. For instance, seek() had to be replaced with lseek(),
gets and fgets were left with not-quite-the-same behavior, errno was
magically adapted to become a macro that grabbed a thread variable when
threads
If you think that's the preferrable approach, then shouldn't it be
[newhip~]? One thing libc did not do is break backwards compatibility
of functions. I think the libc example is a better approach than the
-pre-0.44-hip flag or the aliasing to work around the existing versions
of [pow].
My
Right, the two demands I'm trying to reconcile are keeping the name
hip~ (so that old patches remain comprehensible) and yet making hip~
work correctly -- it's a bug fix. Seems to me one ought to be able to fix
bugs without diving into library version confusion.
I think namespaces are very
27 matches
Mail list logo
