I just upgraded to Pd-extended 0.43.4 but cant find any pd.tk file anymore as there was in 0.42.5...
I am trying to edit the names of the menus of the patch windows so that they would take less space.
Maybe someone knows a way of starting patches without menus that would be nice too.
Today I made the plunge and set out to migrate my EWOCvj video mixer from ArchLinux to Ubuntu, together with the leap from Pdextended 0.42.5 to 0.43.4. Everything goes well so far, except for some new behaviour I did not expect... When using the same abstraction several times in a patch, and when this abstraction contains a [netreceive XXXX] object, in 0.42 this would connect every single abstraction in the patch to port XXXX. Now in 0.43, only one of the netreceive objects is created, the other ones give a "couldnt create" error. In this case (the videomixer) this is a sizeable problem.
Because of ongoing work on videomixer EWOCvj, a pdp external supplying support for the latest GPU-driven video effects standard freeframeGL 1.5 is high on my wishlist.
Since I know of no-one currently working on this (anyone?) I might take the task onto myself if there would be more interested persons on this forum... In the meanwhile I'll see if I can get myself access to the right documentation.
EWOCprojects proudly presents the all new and fully-featured Pure Data video mixer application called EWOCvj.
The application is quite a beast to set up, requiring a Linux setup, installation of Pd-extended and compilation of some custom Pd externals. EWOCvj is under continual development but can be used and is already used for variable VJ tasks. To use the program one needs one or two quadcore computers (PAL 25f 720x576 output) or dual core (15f 320x240 - not yet supported) and the application is specifically written to be used with the Vestax VCI-100 MIDI mixing'n'scratching deck, you won't be able to use it without one, maybe future will see a mouse-only interface? When using two computers, one can VJ with two persons, the video database being on both machines, with one preparing videos with loop and effect settings and sending all this data to the other machine, where the other person performs the live mix. EWOCvj features 46 realtime video effects with 5 effects per deck (two decks A and and per-deck saturation settings, 10 video wipes, a normal and inverse chroma key, one video+effect monitor per deck, Quicktime recording of monitors or mix, 32 video bank in 4 saveable 8 video parts, 8 videos in preset bank for direct triggering with Korg NANOpad2 and another NANOpad2 serves as loop input recorder/player. Videos and parts can be sent to other locations on the same or other machine. Most effects have a parameter, controlled by a turning knob. The video database consists of Quicktime movies 720x576 25f and one needs to transcode to the dv codec.
We know this program needs a load of setup and hardware, thats why we would really like to know if anyone is using it on any projects, also feedback and feature requests are always welcome. Also arrangements can be made if help is wanted getting the setup together. Consider this program "feedback-ware", if you use it, let us know at email@example.com!
Project webpages at http://www.ewocprojects.be
Documentation still under construction. Let us know if you need help!
Good day to you all. This day sees the first release of a few external blocks for the pure data pdp video system. Release is alpha and consists of a zip file of raw c files. These can be compiled on any Linux system(only one to be tested) with the command:
gcc pdp_fisheye.c -o pdp_fisheye.pd_linux -shared -fPIC -Ipdsourcedir -Ipdpincludedir
Replace "pdp_fisheye" by the name of the source file you want to compile. Replace "pdsourcedir" with the location of your pd src directory and replace "pdpincludedir" with the location of your pdp include directory.
After compilation move the .pd_linux files to some directory, add this directory to your library path in PD and add the names of the externals (eg. pdp_fisheye) to your external startup list.
This EWOCprojects pack consists of 4 new pdp blocks:
* pdp_brightness: very simple and crude video brightness adjustment
right inlet is brightness amount ranging from about -300 to 300
* pdp_colorkey: the pdp_compose block from pidip never really worked out for me,
I got inter-pdp-stream flicker on my VJ patch and it created strange coloured
borders and was difficult to set to a colour precisely. This is why I made a new
"chroma"keyer better named colorkey which is flickerless, very precise and
sharp. Inlets are video1, video2, red value(0->255), green value(0->255),
blue value(0->255) and finally tolerance(0->about 60000).
* pdp_fisheye: pdp_freeframe crashes on me and I needed a fisheye for the
VJ patch so I wrote my own. Inlets video and fisheye amount(0->several hundreds).
* pdp_wipe: very fresh and going into the VJmixer also is this brand new video wipe system. In contrast to pdp_transition it is not speed based but controllable by an amount parameter that can for example be set by some crossfader or software slider. This way it is possible to set the value someway inbetween for picture-in-picture or splitscreen video setups. Featured are standard wipe, pushpull wipe, squash wipe, sphere wipe, rectangle wipe, zoomed rectangle wipe, clock wipe, double clock wipe, bar wipe and pattern wipe. Inlets are video1, video2, switch A and B around(0 or 1), wipe amount(float between 0 and 1), x value(this is x pos in pixels for circle, rect and zoomed rect, can also be negative AND is x divisions for bar and pattern wipe), same goes for y value, number of wipe(0->9) and wipe variant/direction(0->depends on wipe). One right outlet gives number of variants for selected wipe, you can feed this eg. into a Hradio block prepending the message with "number".
Remember this is a prerelease which Im rolling out to pick up reactions concerning refinements, extra ideas for wipes and all other feedback. Will be creating help files, putting everything in one library and be doing general nice things like supplying makefiles soon... Oh yes, also the colorkey and wipe system will only work with videos that are the same size.(anyone know a quick way in C to resize pdp packets?)
.Gert De Roost.
My VJ patch uses 4 Pd instances and to avoid screen clutter I set the pd.tk "wm geometry" parameter such that the main Pd windows appear in the bottom right corner of the screen; this works well.
Problem is, though, that when my patch opens an openpanel or savepanel, it is also opened almost offscreen; seems the openpanel/savepanel derives its position from the main window position...
How can I change this behaviour and set the panels to open onscreen, either in absolute or relative coordinates? I looked into pd.tk a bit, but am no expert and have not found a solution yet...
I am currently testing pdp_frei0r. I am especially interested in the bluescreen0r effect, since I currently have problems using pdp_compose (I'll post about this later). It does, however, do nothing on my ArchLinux pdextended 0.42.5 system. I open my pluginsdir, select effect 19 (bluescreen0r) and set parameter Color like this:
[ param 0 200 200 200 (
to select a light gray
then I do for parameter Distance:
[ param 1 200 (
This should at least give some noticeable effect, but the front video (first inlet) just keeps playing...
Does the bluescreen0r effect not work with Pd? Anyone using it succesfully?
Any thoughts on this would be wildly appreciated...
I am busy creating a VJing system using pd and pdp. At the moment it has 25 effects available (pidip also) but if I would be able to use pdp_freeframe, I would be able to offer loads more... Problem is, on 5 different laptops, pdp_freeframe always segfaults pdextended, only constant factor being the Linux distribution, namely Archlinux (which does have very up to date packages, maybe some dependency too new?). Pd crashes whenever I try to load a directory(containing any number of PetesPlugins *.so files) into pdp_freeframe.
Has anyone succesfully used pdp_freeframe, if yes, what is your setup? I have compiled PetesPlugins and pdvjtools myself.
I can use pix_freeframe instead but I don't like the prospect of the stream converting overhead I'd be having between pdp and Gem...
Should I contact the pdp_freeframe author?
Any ideas welcome,