debugging WAS: [PD-dev] Inconsistency in behaviour using Gem... my fault?

Hans-Christoph Steiner hans at
Wed Nov 1 17:29:00 CET 2006

First off, its helpful to split off multiple questions into multiple  
emails.  Most people don't expect a new topic at the bottom of a long  
email.  If you write really long ones like this, then you're  
questions will most likely be overlooked.  I skimmed to the bottom  
and saw the stuff about debugging.

Debugging is an area that could use some work.  I know that Max/MSP  
has a stepper but I have heard from some that its useless, while  
others say they sometimes find it useful.  Right now, the [print] is  
the main debug mechanism.  But you can make print much easier to  
use.  That's basically the most used functionality of gdb: live,  
interactive printf() of variables.

Here's a super quick demo:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: debugs.pd
Type: application/octet-stream
Size: 650 bytes
Desc: not available
URL: <>
-------------- next part --------------


On Nov 1, 2006, at 4:23 AM, Nick Bailey wrote:

> Hi pd community. I have a suspected bug but before I raise it with  
> the Mac developers, I thought I'd ask some experts to make sure it  
> isn't my fault.
> Using pd 0.39-2 on Linux (Debian Sid) to do my development, but  
> wanting to deploy on my Mac Powerbook using "Pd-extended" 0.39-2  
> beta4 from on the Mac  
> (there's a 5th beta release on that site, but it won't even start  
> for me).
> Problem involves a Gem patch. We want to divide a photograph up  
> into tiles, so each can individually cross-fade between one photo  
> and the next. I made a first rough cut of a UI to do this called  
> imageMixer.pd on my Linux box (it's at http:// 
> - 465K). After playing with  
> it for a while, I attemted to transfer it to my PowerBook, and it  
> sort of worked, but when rendering was switched on, I got a  
> continuous message:
> 	separator : state->numTexCoords 4 != m_state.numTexCoords 0
> repeated over and over again. The separator in question turns out  
> to be in [pd tile] which is in [pd tile_array] (at the bottom right  
> of the patch).
> Playing around a bit more, I came up with imageMixer-mac39.pd. This
> gets rid of the separator in [pd tile] and just has a gemhead  
> feeding both pix_image. This works fine on the Mac (though I was  
> led to believe you had to use a [separator] here... why not? Should  
> it not work?) but on the linux box it doesn't fade between two  
> different images, it fades between image and black.
> The final attempt (imageMixer-2.1.pd) simply moves the gemhead  
> outside of [pd tile] and back into [pd tile_array]; this works on  
> both machines.
> Now, this is my first ever pd patch (except for a very simple one I  
> wrote to demonstrate writing an LPC pd plugin to my students), and  
> certainly my first outing with Gem, so it's very likely I've just  
> missed the plot with the semantics of gemheads, separators etc. It  
> does look to me like there might be a bug in separator on Pd- 
> extended for the Mac though. It is after all a test release.  
> Consequently any comments directed to me regarding RPI (removal of  
> pig-ignorance) or style criticisms would be very well received. If  
> people think it's a bug, I'll file a report with the Mac packager  
> (or maybe s/he's already reading this?)
> One last question. pd/Gem was certainly a rapid development tool  
> for the concert which is going to be in Boston MA in a few days'  
> time, but apart from the judicial use of [print] and numbers,  
> staring at the code, and bleating for help from my postgraduates,  
> are there any better ways of debugging patches? You'll have guessed  
> from my email address that I'm from a different programming  
> background, and use gdb and the like much more frequently. I've  
> certainly learned to be very strict about versioning. Messing  
> around for an hour or so with a patch, then not being able to use  
> diff to see what one's ended up changing makes one take particular  
> care in that direction!
> Thanks in advance for your helpful advice and comments,
> Nick/.
> _______________________________________________
> PD-dev mailing list
> PD-dev at


There is no way to peace, peace is the way.       -A.J. Muste

More information about the Pd-dev mailing list