Since I've upgraded to Mac OSX 10.7 Lion, I've noticed Pd-extended 0.42.5
seemed to crash on startup sometimes, while other times it was fine. It finally
dawned on me that OSX is trying to load the previous saved state since I had
CMD-Q'd Pd with windows open. It automatically opens those
I tested this with Pd-Vanilla 0.43-0 and there are no problems. The patch
windows come up nicely.
I tried to test it with a Pd-Extended-0.43.1autobuild but I keep getting load
errors and can't open any patch windows :P Is there a more stable version
somewhere?
As for Pd-Extended 0.42.5, there
That's a good question.
Hrm, well you can easily read and write to arrays which are naturally 1
dimensional. I would first try flattening the image by writing the pixel buffer
into a float array. Then send the width and height as well for reading it back
in pd. There currently isn't a way to
To be honest I don't care.
You can get into semantics all you like but it's a library that can run Pd
patches.
If there are issues with ZenGarden then wouldn't it make sense to bring them
up with the developer? It's not like they couldn't be resolved.
I'm just looking to create a GUI that
Works now.
On Sat, Aug 27, 2011 at 10:53 PM, Hans-Christoph Steiner h...@at.or.atwrote:
Its hosted here, so it looks like their whole internet connection is down:
http://www.poly.edu
.hc
On Aug 27, 2011, at 11:09 AM, Pedro Lopes wrote:
Is autobuild site down?
On Sat, Aug 27, 2011 at 11:16 PM, Mathieu Bouchard ma...@artengine.cawrote:
On Sun, 21 Aug 2011, Hans-Christoph Steiner wrote:
I think with the libpd API, you can write to Pd arrays. That's probably
you're best bet.
You must be meaning the pd API (m_pd.h).
There's nothing
after a few days of waiting (for you) and hard labour (for me), Gem
0.93.1, the 1st bugfix release for the 0.93 series, has been released today.
like always we have fixed numerous bugs and features, and most likely
introduced an equal number of wishlists and showstoppers.
noteable differences
On Sun, 28 Aug 2011, Joe White wrote:
To be honest I don't care.
Ah. Nevermind then.
If there are issues with ZenGarden then wouldn't it make sense to bring
them up with the developer? It's not like they couldn't be resolved.
No, because those issues were created on purpose.
On Tue, 28 Jun 2011, IOhannes m zmoelnig wrote:
the v4l2convert trick mentioned above, is a workaround to make
applications not using libv4l to still be able to benefit from libv4l's
color conversion routines. but really, the application (e.g. GF or Gem)
should use libv4l natively. as far as
hello IOhannes,
is gem 0.93 compiled with mingw, if not, is it planned?
- IOhannes zmölnig zmoel...@iem.at a écrit :
after a few days of waiting (for you) and hard labour (for me), Gem
0.93.1, the 1st bugfix release for the 0.93 series, has been released
today.
like always we have
On 08/28/2011 05:54 PM, Patrice Colet wrote:
hello IOhannes,
is gem 0.93 compiled with mingw, if not, is it planned?
it's not compiled with mingw, and it is not planned for 0.93
Gem currently does not compile with mingw (see recent postings on
gem-dev@), but it would be a nice feature to
If the developer exhibits a capacity for purposefulness, couldn't
that same a sense of purpose be used to undo a mistake? Or do you
suggest the errors were placed there as obstacles with malice
aforethought?
On Sun, 28 Aug 2011 11:34:18 -0400 (EDT)
Mathieu Bouchard ma...@artengine.ca
Okay i will join the gem-dev list when I'll get time to work on it...
before I'd like to finish the pd-extended build system stuff, there still are
problems
to get it working.
Using mingw would be great for me because we will be able to use Gem libs on
gridflow.
- IOhannes zmölnig
On Sun, 28 Aug 2011, IOhannes zmölnig wrote:
Gem currently does not compile with mingw (see recent postings on
gem-dev@), but it would be a nice feature to have for 0.94 (help would
be appreciated; hint, hint :-))
It's not that I would like to have the option of compiling Gem in MinGW,
it's
On Sun, 28 Aug 2011, Andy Farnell wrote:
If the developer exhibits a capacity for purposefulness, couldn't that
same a sense of purpose be used to undo a mistake?
Well, the developer would have to think of those things as mistakes first,
and also, to think of vanilla's ways as being the
- Original Message -
From: Mathieu Bouchard ma...@artengine.ca
To: Andy Farnell padawa...@obiwannabe.co.uk
Cc: pd-list@iem.at
Sent: Sunday, August 28, 2011 1:04 PM
Subject: Re: [PD] [PD-dev] tkwidgets
On Sun, 28 Aug 2011, Andy Farnell wrote:
If the developer exhibits a
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
Can you bypass many of the functions in libpd and use m_pd.h directly?
Sure, but then again maybe m_pd.h is pointless because you can just hack
your binaries with a hex editor. That doesn't mean that that's a good
level of abstraction to work at.
On Sun, 28 Aug 2011, Jonathan Wilkes wrote:
_Submitting_ patches to Miller is easy.
hehe, yeah, I know what you mean, though I really meant getting the
patches accepted.
___
| Mathieu Bouchard tél: +1.514.383.3801
I think reasonable suggestions might be welcome.
Some say the sulphur fumes, screams and maniacal laughter emanating
from Martin and Joe's subterranean laboratory beneath the opera house
catacombs is too intimidating. But I've heard that mortals making offerings
have been spared.
Occasionally.
- Original Message -
From: Martin Peach martin.pe...@sympatico.ca
To: Jonathan Wilkes jancs...@yahoo.com
Cc: András Murányi muran...@gmail.com; pd-list pd-list@iem.at
Sent: Friday, August 26, 2011 2:30 PM
Subject: Re: [PD] [PD-dev] tkwidgets
On 2011-08-26 11:31, Jonathan Wilkes
On Sun, 28 Aug 2011, Dan Wilcox wrote:
and I could imagine sending a giant list would be alot slower then using
an array.
A list is passed by pointer. The first thing that can be slower, is having
to read the atomtype because list elements can be things other than
floats. The second thing
Le 28/08/2011 17:27, IOhannes zmölnig a écrit :
after a few days of waiting (for you) and hard labour (for me), Gem
0.93.1, the 1st bugfix release for the 0.93 series, has been released today.
like always we have fixed numerous bugs and features, and most likely
introduced an equal number of
On 08/28/2011 06:41 PM, Mathieu Bouchard wrote:
On Sun, 28 Aug 2011, IOhannes zmölnig wrote:
Gem currently does not compile with mingw (see recent postings on
gem-dev@), but it would be a nice feature to have for 0.94 (help would
be appreciated; hint, hint :-))
It's not that I would like
On Sun, 28 Aug 2011, IOhannes zmölnig wrote:
i'm aware of the problem. however, the problem is the solution.
What does that mean ?
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC
On 08/28/2011 07:44 PM, Mathieu Bouchard wrote:
On Sun, 28 Aug 2011, IOhannes zmölnig wrote:
i'm aware of the problem. however, the problem is the solution.
What does that mean ?
i meant:
i'm aware of the problem, however i don't see a solution.
it was not meant to be self-referring.
On Sun, Aug 28, 2011 at 1:26 PM, Mathieu Bouchard ma...@artengine.cawrote:
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
Can you bypass many of the functions in libpd and use m_pd.h directly?
Sure, but then again maybe m_pd.h is pointless because you can just hack
your binaries with a hex
Iohannes
Thanks for the clarification regarding Frei0r/freeframe!
From: Jack j...@rybn.orgmailto:j...@rybn.org
Date: Sun, 28 Aug 2011 19:42:30 +0200
To: pd-list@iem.atmailto:pd-list@iem.at
Subject: Re: [PD] [PD-announce] gem 0.93.1
Le 28/08/2011 17:27, IOhannes zmölnig a écrit :
after a few
Is there a how-to for compiling GEM on OSX?
I really want to get started with frei0r and freeframe
pp
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
One major simplification is the use of built-in data types vs custom
structs and unions.
You mean you simplify by making things more low-level ?
const char * is rarely ever called high-level...
With this transition to built-in data types, you can
On Sun, Aug 28, 2011 at 5:04 PM, Mathieu Bouchard ma...@artengine.cawrote:
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
One major simplification is the use of built-in data types vs custom
structs and unions.
You mean you simplify by making things more low-level ?
const char * is rarely
Iohannes, cheers for the bug fix!
On Sun, Aug 28, 2011 at 8:27 PM, Pagano, Patrick
p...@digitalworlds.ufl.edu wrote:
Is there a how-to for compiling GEM on OSX?
I really want to get started with frei0r and freeframe
pp
___
Pd-list@iem.at mailing
That has little to do with Tcl/Tk being slow. That has a lot more to
do with how Pd is implemented. It generates and sends raw Tcl to the
GUI, and if you are moving a lot of stuff, that means a lot of raw Tcl
needs to be generated, sent, parsed, and executed. That definitely
slows
That's an excellent example. In the case I just wrote about, using
Tcl's tag and move could reduce 500 KB/sec of Tcl code to 5KB/sec.
.hc
On Aug 26, 2011, at 9:46 PM, Patrice Colet wrote:
This is very slow because everything selected is moving, this method
makes a very slow dragging,
On Aug 28, 2011, at 12:08 PM, IOhannes zmölnig wrote:
On 08/28/2011 05:54 PM, Patrice Colet wrote:
hello IOhannes,
is gem 0.93 compiled with mingw, if not, is it planned?
it's not compiled with mingw, and it is not planned for 0.93
Gem currently does not compile with mingw (see recent
The 0.43 Pd-extended nightly builds include it, AFAIK.
.hc
On Aug 28, 2011, at 3:27 PM, Pagano, Patrick wrote:
Is there a how-to for compiling GEM on OSX?
I really want to get started with frei0r and freeframe
pp
___
Pd-list@iem.at mailing list
0 0 is problematic on couple platforms. On Mac OS X, the menubar is
always there, so it puts the window header behind on menubar. A
similar problem happens on GNOME.
.hc
On Aug 25, 2011, at 5:33 PM, Jonathan Wilkes wrote:
Ok, fixed the weird resizing issue when the text in the status
Hmm.. maybe that should be the first line of the Tcl main.
cheers
Miller
On Sun, Aug 28, 2011 at 05:16:15AM -0400, Dan Wilcox wrote:
Since I've upgraded to Mac OSX 10.7 Lion, I've noticed Pd-extended 0.42.5
seemed to crash on startup sometimes, while other times it was fine. It
finally
Nah, you're fine. It's a problem with Pd-extended 0.42.5 ... Pd-0.43.0 Vanilla
handles resume fine. :D
On Aug 28, 2011, at 10:58 PM, Miller Puckette wrote:
Hmm.. maybe that should be the first line of the Tcl main.
cheers
Miller
On Sun, Aug 28, 2011 at 05:16:15AM -0400, Dan Wilcox
I was talking about sending a large list through libpd which, I assume, is
doing some sort of copying of floats as it translates from the libpd api to the
internal pd api. At least that's what my ofxPD wrapper does, passes each float
by value to libpd. Someone correct me if I'm wrong.
Besides,
On Mon, 29 Aug 2011, Dan Wilcox wrote:
I was talking about sending a large list through libpd which, I assume,
is doing some sort of copying of floats as it translates from the libpd
api to the internal pd api.
Oh, yeah... if you use z_libpd.h, it copies the floats, whereas with
m_pd.h, you
Test1:
Gnome 3 (Fedora 15) -- no problems
Gnome 2.32.0 (Ubuntu Maverick) -- no problems
OSX 10.7 -- problem: window decoration behind Apple's menubar.
Test2:
Tried a little stand-alone version of my plugin. Still specifying 0 0 screen
coordinates, and
Apple automatically puts the .search
- Original Message -
From: Mathieu Bouchard ma...@artengine.ca
To: Dan Wilcox danomat...@gmail.com
Cc: PD List pd-list@iem.at
Sent: Monday, August 29, 2011 12:54 AM
Subject: Re: [PD] sending image from of / libpd
On Mon, 29 Aug 2011, Dan Wilcox wrote:
I was talking about
On Sun, 28 Aug 2011, Peter Brinkmann wrote:
Well, I'm taking a complicated implementation detail (t_symbol)
but t_symbol is a higher-level structure for wrapping the const char *.
:}
I thought I had already explained this when we had our little chat over
at pd-everywhere, but I'll try
On Sun, 28 Aug 2011, Jonathan Wilkes wrote:
With z_libpd.h, you have an artificial limit of 32 atoms per message
I must be misunderstanding what you've written, because it would break
trivial patches:
[osc~ 440]
|
| [bang(
|/
[print~]
Where's the 32 atoms in a message in your example ?
No, I'm talking about sending a list or typed message with libpd as in:
[list 1 2 3 4 ... 32
|
[s toC++]
The print messaging isn't limited as far as I know.
I think it's reasonable to limit the message size, but 32 may be too small for
some. It would make sense for libpd to have a call that
45 matches
Mail list logo
