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 http://at.or.at/hans/pd/installers.html 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://markov.music.gla.ac.uk/ boston.tar.bz2 - 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/.
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:
.hc
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 http://at.or.at/hans/pd/installers.html 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:// markov.music.gla.ac.uk/boston.tar.bz2 - 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@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
-
Hans-Christoph Steiner -
Nick Bailey