Call for Papers and Presentations : Free and Open Source Software Panel Session at CAA 2011

Deadline Extended: May 24, 2010

Fight the Power: Open Source, Free Software, and Critical Digital Practice

We invite proposals for papers and presentations for a panel on creative Free/Open Source Software at the College Art Association Conference in New York, February 9-12, 2011.

Digital technology has become a standard tool for artists working in both new media and traditional forms, just as it has become enmeshed in ever aspect of contemporary life. The Free/Open Source Software movement has recently emerged as an alternative model to the traditional software industry. This panel explores the use of Free Software in the studio and the classroom. What possibilities can it open for students, and how does it impact our teaching? How does it fit into professional creative work? Can the ideas behind “open source” be applied to other forms of collabo-
ration? This panel seeks papers and presentations addressing the use of open source software in studio practice and pedagogy, the state of the art in free creative software, and the nature of cultural production in a digital society.

Please submit proposals and queries to

Ben Chang
ben@bcchang.com

For the full conference call for participation, visit http://www.collegeart.org/proposals/

All participants in the conference must be members of CAA. For more information, visit www.collegeart.org.

After only a little hacking I got pd-extended to build on Ubuntu 9.04 64. Somehow iem_tab didn't make it but everything else looks good so far. I have no idea if I even really did it properly but if anyone wants to try it out you can get it here:

http://transatlab.net/?p=143

I'm trying to use Pd as a simple glue layer to convert gamepad input into midi. I'm having a really hard time getting the joystick object to work reliably. I'm using Ubuntu and a scavenged Rock Band PS2 drumkit. The kit works great in the joystick control panel in the system settings.

In PD, I tried using /dev/input/js0 (which is the joystick), but the joystick object doesn't seem to recognize it. All the /dev/input/event* files are, I guess, what it wants, but I has no access unless running sudo, in which case there are problems getting the Jack midi connection to Hydrogen to work (unless maybe I run Hydrogen sudo also? ). Any hints on how to do this?

Here's a weird annoyance. All text is too big (or, conversely, all boxes are too small - messages, objects, everything). The text spills out over the right edge. The longer the text inside, the more it spills out. I feel like there's maybe some magic Tk options hidden somewhere to fix this ... ?

thanks,

--ben

http://www.pdpatchrepo.info/hurleur/pd.png

Is it possible to print using PD? (I mean, to a printer. not the [print] object

What I'd really like to do is be able to create images in GEM and then print them out ... possible?

I'm making a mesh using GEMglVertex3f, but I can't get a texture to apply to it. Should you be able to connect a pix_texture into a GEMglBegin, or is there another way you have to do it?

Anyone had this problem? Whenever I destroy a gemwin, Pd crashes with a segmentation fault. I'm using pd-extended 0.40.3 on Kubuntu Intrepid.

That works ok for other people, right?

thanks,

-ben

i'd like to use PD to control an old-school modem. I thought it might be possible using comport, but it doesn't seem to do anything. I set the baud rate to 57600 8 N 1, opened the port using "devicename /dev/modem", and then tried "print ATZ", "print "ATDT", "print ATA", etc; but no response, not even the "OK" or "NO CARRIER" that it should get. the modem works fine through other term programs. anyone tried this?

I have an input stream of 0 or 1 values (sensor input). I want a single bang only when the value changes from 0 to 1. In something like Python I might do it like this

newvalue = sensorInput()
if newvalue==1 and oldvalue==0:
bang()
oldvalue=newvalue

but how do you it in Pd?

or another way of putting it, I want to trigger only on the rising edge of the square wave pulse.

I've been trying different convoluted things with spigot, oneshot, expr, etc., but I still get this continuous flow of bangs no matter what. I thought [threshold] would do it, but I can't get that object to do anything at all, and the help example doesn't do anything either.

thanks for any help, this is tying my brain in a knot.

I'm trying to use a firewire capture box with pix_video. Here's my setup:

OS: Ubuntu 8.04
Pd: 0.40.3-extended
capture device: "Hollywood Dazzle"

I can capture using Kino or dvgrab. Coriander can't see the device. Modprobing a variety of different modules, I can get /dev/video1394/0, /dev/dv1394/0, or /dev/raw1394.

In Pd, I've tried setting the device to all of those. When I open the gem window, I just get this error:

get capabilities: Invalid argument

and the window is just white.

I read through an older thread on gem-dev and tried chris clepper's texture mode suggestion, but it didn't change anything.

http://markmail.org/message/56bf6xow2x5eznud

I can't tell if the "get capabilities" error is a death error or just a warning.

thanks in advance,

--Ben

I'd love to see an answer to that too. If you don't get a solid answer, it may be that there hasn't been an empirical test done yet, so if you started one, that'd be a great thing. Meaning, take your video, encode it many, many different ways, and compare the results.

One thing that makes a difference is what you're using the video for - specifically, whether you do a lot of rapid frame-accurate seeks, switching between forward and reverse, etc; or if you're playing long clips straight, perhaps switching between clips occasionally or blending them, etc. Most codecs use temporal compression, so most frames are stored as differences from previous frames. The more sophisticated the codecs get, the more sophisticated this temporal compression is, which gets you higher levels of visual quality at smaller file size. The tradeoff is that if you want to jump to a specific frame, you often have to first jump to a keyframe near where you want to go, and then seek forward, accumulating the frame differencing until you get to the target frame. So for an application involving random access, the keyframe setting may have more of an effect than the actual codec.

Other factors include stuff like your hard drive. Say you have some nice high-res video. If you compress it a lot, each frame doesn't have too much data in it, but it takes a lot of processing power to decode; so if the rest of your patch has a high cpu load, that can slow it down. You can use less compression, so less computation, but if your hard drive is not that fast, at some point it can't get the data off the disk fast enough to display it either.

So there's a lot of variables, which is why maybe an empirical test suite would be a good thing.

btw what do you mean about free stuff online? Do you mean free codecs, like ogg vorbis/theora, or free encoding software, like ffmpeg and mencoder?

Finally got around to learning how to compile and hack on GEM, and I've made some progress on this. Here's what I did.

First, I didn't get the whole deal about the colorspace, so was trying to use RGB with my iSight, which is wrong. "colorspace YUV" was the first step. I got it this far:

v4l2: changed size from 64x64 to 320x240
v4l2: GEM: pix_video: Opened video connection 0xB

However, I kept getting this error:

VIDIOC_DQBUF: stopping capture thread!: Resource temporarily unavailable

Looking through the source for pix_videoNEW, I found where this was happening.

In videoV4L2.cpp, videoV4L2::capturing()

 if (-1 == xioctl (m_tvfd, VIDIOC_DQBUF, &buf)) {
      switch (errno) {
      case EAGAIN:          
        perror("VIDIOC_DQBUF: stopping capture thread!");
        goto stop_capturethread;
      case EIO:
        /* Could ignore EIO, see spec. */
        /* fall through */
      default:
        perror ("VIDIOC_DQBUF");
      }
    }

I don't know what an "EAGAIN" error is. Maybe it means "You should try again!", instead of giving up and closing.

so I took it out, and now I get video in my gem window! yay! it's slow and still has a lot of errors streaming out all the time, but it works!

Edit: ok, that is what EAGAIN means:
"By default VIDIOC_DQBUF blocks when no buffer is in the outgoing queue. When the O_NONBLOCK flag was given to the open() function, VIDIOC_DQBUF returns immediately with an EAGAIN error code when no buffer is available."

http://v4l2spec.bytesex.org/spec/r12878.htm

So it just means a capture buffer isn't filled yet, rather than a total failure. The investigation continues...

Oh for crying out loud:

void GemMan :: destroyWindow()
{
 <snip>

  // reestablish the const glxContext 
  /* this crashes on linux with intel cards */
  gemWinMakeCurrent(constInfo);

}

uhhhh .... so .... what do I do now, exactly? wonder what happens if I take that out...

EDIT:

Yup, that fixed it. Everything seems to work fine, I haven't noticed any problems by removing it ... happy happy happy!

Thanks, I'll try that next. I built my own GEM (easy), but I'm still getting the same behavior. Whenever I close a gemwin, Pd crashes with a segfault.

here's the backtrace from gdb:

#0  0xb6834bb0 in ?? ()
#1  0xb7998510 in glXMakeCurrent () from /usr/lib/libGL.so.1
#2  0xb7c39e32 in gemWinMakeCurrent () from /home/ben/src/gem-0.91-3/src/Gem.pd_linux
#3  0xb7c2845a in GemMan::destroyWindow () from /home/ben/src/gem-0.91-3/src/Gem.pd_linux
#4  0xb7c28c05 in GemMan::render () from /home/ben/src/gem-0.91-3/src/Gem.pd_linux
#5  0x080c351c in m_mainloop () at m_sched.c:372
#6  0x080c6b55 in sys_main (argc=5, argv=0xbfab4ff4) at s_main.c:313
#7  0x080d26cf in main (argc=170465544, argv=0xa290388) at s_entry.c:32

My card is an ATI Mobility Radeon X1600. Probably the culprit is ATI's sucky drivers (Catalyst 8.54.3).

This made me chuckle, here's the point in the code where the crash is happening:

void gemWinMakeCurrent(WindowInfo&nfo) 
{
  if (!nfo.dpy && !nfo.win && !nfo.context)return; // do not crash
  glXMakeCurrent(nfo.dpy, nfo.win, nfo.context);   
}

Note the optimistic comment.

Yeah, I tried that, but it didn't seem to make any difference. Then I went ahead and compiled my own pd from the latest source (0.42-4), and everything looks fine and somehow crisper and more responsive, too took less than 10 minutes to do. nice.

now to go and compile GEM and see if that solves my other difficulties.

btw, I saw some warnings that using Tcl 8.5 was less stable than 8.4, is that still true?

thanks,

--ben

thanks - yeah, I wanted it to be from within Pd, to be automated for an installation. In this case the things to print don't actually HAVE to be generated from within Pd, so we're gonna have them as premade files and then use [shell] and lpr to do it.

take a look at pix_coordinate, it might do what you want ...

I haven't used that example, but if what it's doing is sending a "1" or "0" when the button is pressed or released, then the reason you get bangs for both is that a bang happens whenever any data comes through. here's one way to do it:

[arduino or what-have-you]
|
[select 1]
|
(bang)

I'm using pd 0.40.3-extended for Ubuntu Hardy, from puredata.info.

Interesting, with each problem I have, the universe seems to be pointing me towards using vanilla and building individual libs as needed ...

Thanks, I'll try that. My other machine runs Hardy and it's fine, so must be either something with the Intrepid package or something with that laptop.