Pd-list May 2009

pd-list@lists.iem.at

131 participants
200 discussions

Pd FLOSS Manual Update pt 2
by Derek Holzer 06 May '09

06 May '09

So here is part two! The following chapters were newly created during the Book Sprint. We'd really like to see them come together, but we don't think they will be anywhere near ready before we decide to publish the version 1.0. Futher work on these chapters is also appreciated, but only after the chapters we have marked for inclusion in the 1.0 are complete. Writing, editing and proofreading on these chapters can continue as normal, and when we are ready for a second release (now with GEM + SENSORS!) then we will include them. CHAPTERS FOR FURTHER DEVELOPMENT, not to be included in upcoming 1.0 release: GEM SENSORS MIDI NETWORK DATA When the version 1.0 is completed, and these chapters are also fixed, then we can consider a paper publication!!!!!! Here are the issues and places for improvement on each chapter. Again, we welcome improvements to these chapters, but if you are going to spend any time on this manual in the next few weeks, it would make more sense to focus on the chapters marked for publication (see Part 1 of this update): ____GEM_____ -> These chapters need a lot of work to be anywhere near complete! -> My suggestion is to do more tutorial-based stuff, like "how to" sections, rather than break down the material by taxonomy (which is how it is already documented elsewhere). Thus, "How to VJ with Images and Video using GEM" and "How to Create 3D Animations using GEM" would be preferable to existing system. -> Perhaps rather than single GEM heading, each of these could be section heading with chapters beneath them? In such a case, the chapters beneath each section should follow some logical progression from one to the other, leading towards the goal of VJing or doing animations. -> Also some of the examples are far too complex, and rely on arcane systems like [import] or objects with severe nameclashes like [counter] which are traps for new users and should be avoided! * http://en.flossmanuals.net/bin/view/PureData/GEMIntroduction --Check for tone, perhaps more introduction and less credits, explain basic parts better (i.e. "2D and 3D graphics and animation, realtime image and video processing, and particles") --Show screenshot of help patches + examples in Pd Browser? * http://en.flossmanuals.net/bin/view/PureData/GEMBasics --Mention "Red Book" and other technical OpenGL info later, it's not needed in beginners introduction, skip immediately to rendering --Re: [gemwin] question in text ("is this true?"): please verify this information or cut it! --In general, would be good to concentrate on doing things rather than exhaustively explaining technical details --Re: [pix] objects.... save this for chapter on it. --Perhaps what is needed here is overview of GEM functions, and then each chapter can deal with them independently as part of unified tutorials (VJing/Animation) --Section (or new chapter) on setting up second screen for live performance for each OS! * http://en.flossmanuals.net/bin/view/PureData/GEMImagesMoviesAndVideo --This could really use less of reprinting helppatches, and more how to do things, like: ____Using [metro]/[float] counter to drive frame playback (changing playback speed or going backwards) ____Using [mod] and [+] to create smaller loops within film ____Use [random] to "granulate" film ____Use pix effects (where to insert in gemlist)(then refer to later chapter for more details, or work into single VJ tutorial as suggested above) --Section on video formats for each OS is essential!!!! * http://en.flossmanuals.net/bin/view/PureData/GEMVideoMixer --I would like to see [alpha] plus [colorRGB] used in how to do simple crossfader instead of [pix_mix]. --Explanations could be helped more towards clarity. --Re: recommendation to "create abstractions": either explain this inline or direct reader to Patch Management section (to be created) which will cover subpatches, abstractions, etc --Webcam: needs Linux info on getting video devices in, there are probably other flags which need to be shown as well * http://en.flossmanuals.net/bin/view/PureData/GEMPixEffects --Please don't use a PiDiP object [colorgrid] in a GEM tutorial!!!!!!! (Also not cross platform!) --Can this tutorial be done without need to import? (i.e. used normal counter instead of external?) I really don't agree with using objects that have such bad name clash issues, like [counter] --The [send] and [receive] are abbreviated (first bad) and not explained in tutorial (second bad) --In general, examples are too complex, please simplify!!!!!!!!! * http://en.flossmanuals.net/bin/view/PureData/GEMSavingAndRecording --Same problem as above, please don't [import] as it makes it much more complicated to explain whole patch. Basic objects available in Pd-Extended are assumed, anything else should either be skipped or extensively explained in line! --While the toggle for turning gemwin on and off is useful, it is not explained in line and in general adds unneeded complexity to example patch. please simplify! --If this section is about [pix_record] then it would be best to focus on that object and leave fancy stuff out * http://en.flossmanuals.net/bin/view/PureData/GEMScreens --Good place for second screen tutorial? --Per OS instructions with screenshots please! * http://en.flossmanuals.net/bin/view/PureData/GEMBlueGreenScreen --Nothing there * http://en.flossmanuals.net/bin/view/PureData/GEMVideoTracking --Good start but nowhere near complete. need to see more screenshots of video tracking at work, more real world examples --I think list at the end is far far far too ambitious for beginner's manual! (pattern recognition (TUIO), pix_opencv (face recognition), blobs and multiblobs, IR illumination and multitouch technology) * http://en.flossmanuals.net/bin/view/PureData/GEMText --Nothing there * http://en.flossmanuals.net/bin/view/PureData/GEMInteraction --Nothing there * http://en.flossmanuals.net/bin/view/PureData/GEMFrameBuffer --Nothing there * http://en.flossmanuals.net/bin/view/PureData/GEMGLSLShaders --Not much there, and I really consider this far too advanced for a beginners manual. This chapter should be sidelined until absolutely every other topic in GEM has been well covered. * http://en.flossmanuals.net/bin/view/PureData/GEMdShapes --Nothing there --Suggest to merge shapes and animations and some others into general chapter on how to do animation in GEM * http://en.flossmanuals.net/bin/view/PureData/GEMdAnimation --Nothing there --See GEMdShapes notes * http://en.flossmanuals.net/bin/view/PureData/GEMCamera --Nothing there --Low priority for now --See GEMdShapes notes * http://en.flossmanuals.net/bin/view/PureData/GEMLightingFogAmbientColor --Nothing there --Low priority for now --See GEMdShapes notes http://en.flossmanuals.net/bin/view/PureData/GEMParticleSystems --Nothing there --Low priority for now --See GEMdShapes notes ____SENSORS____ -> Suggest renaming chapter to external inputs, and including MIDI, [key] etc * http://en.flossmanuals.net/bin/view/PureData/GameControllers --The [cursor] object has nameclash!!!!!! Which lib? Please avoid libs which need [import] or have nameclash! --Would it be possible to simply open [hid] help file to start with, then explain furhter down how to code it from scratch? --The "minia" HID device is rather obscure hardware which most people will never have. Possibly move it + finished controller shown to some later section that shows people's custom controllers projects, rather than use as example --This chapter could use some better attention, clearer explanations, a "how to" 1, 2, 3 rather than current structure. For example, how to plug in Wingman and control very simple synth! * http://en.flossmanuals.net/bin/view/PureData/Pduino --Good start, but needs work clarifying. --Section on installing the Pduino library needed for each OS --Section on installing Arduino needed for each OS --Section on getting USB serial emulation needed for each OS --Screenshot of "open button" should include submenus --One screenshot uses [pd display values without pegging the CPU] subpatch, which is not explained nor made available. Please avoid this, or explicitly have them open the [pduino] abstraction --Please make circuit diagram and spend some time explaining the circuit (i.e. tell what voltage divider is and how it works) --Re: [autoscale]: what lib is this? Is it in Pd-Extended by default or must it be imported. In general, it would be nice to use some basic maths there instead for simplicity, since we can't assume reader knows what [autoscale] will do. --Best to explain patches in-line as well as in patch comments. In-line text can be text-searched in browser or PDF reader, while comments in images cannot. --Perhaps also better explanation of [send] and [receive], or direct reader to chapter on it. ____MIDI____ * http://en.flossmanuals.net/bin/view/PureData/UsingMidi --This chapter needs some serious work. Again, there is more taxonomy here than tutorial. --I would like to see following: ____Intro to MIDI hardware ____How to set up system for each OS (See Configuring PD chapter) ____Tutorial showing how to plug in keyboard and get notes from proper channel ____Tutorial on how to plug in fader box and get CC info on proper channels ____Tutorial on how to send MIDI from Pd to other apps (FLOSS apps, if possible)(using IAC bus on OSX, MidiOx or similar on Windows and QJackCTL on Linux) --The "pd uc16" example screenshot is needlessly complicated, and graphical bangs like that should be discouraged as they would cause audio glitches on many users' systems if data came in quick enough ____NETWORK DATA____ * http://en.flossmanuals.net/bin/view/PureData/Receive --Needs a lot of work!!!! --Please real world examples rather than taxonomy * http://en.flossmanuals.net/bin/view/PureData/OSC --Please use built in OSC as default, since those are what comes out of the box in Pd Extended, are the simplest and also still the most widely used --If you want to use mrpeach objects, please do this in a separate section or chapter (Advanced OSC, perhaps?) and please be sure to explain in-line how to load non-standard externals (see Configuring Pd chapter, perhaps best to put it there are reference it) Thanks again to everyone who helped out over the weekend, and let's all get busy making this manual the best it can be. Best wishes from Berlin! Derek -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 113: "Make a blank valuable by putting it in an exquisite frame"

2 1

space background in Gem
by Sebastian Saa 05 May '09

05 May '09

Hello, i need to make a solar system in Gem , Do anybody have an idea of how can i make the space background in Gem? ive tried using a quad primitive and apply a space texture and put it as background, the problem is then i move the camera position it doenst look realistic. I need that the texture always appears at the same position even if i move the camera position . Any idea? thanks S.

5 8

[PD-announce] Theremin Sensors Workshop with Andrei Smirnov
by Derek Holzer 05 May '09

05 May '09

Theremin Sensors Workshop with Andrei Smirnov = 5 days with final concert-presentation = Monday 18 May - Friday 22 May 2009, 12.00-18.00 daily Final presentation Saturday 23 May, 19.00 Location: eNKa / ElsenStr. 52 (2.Hof) Berlin, Germany Telephone: +49 (0)176 20626386 Course Participation fee: 100 euros Registration is required for this workshop and can only be done via email to: eNKa_NK[at]gmx[dot]de, www.myspace.com/enka52 Please register early to ensure a place. Places are limited to 12. This intensive workshop offers hands-on introduction to interactive systems, based on the theremin-sensor technology developed by Andrei Smirnov and based on the same principle as a well known electronic musical instrument the Theremin, invented by Russian inventor Leon Theremin in 1919. The sensors are small and sensitive digital Theremins useful for numerous applications including motion tracking, gestural interfacing, monitoring of small variations of electrical capacitances related to any sorts of conductive materials and media, including metal objects, foil, liquids, water, human body, plants, metal threads, thin plastic films with metallization, all sorts of Christmas stuff etc. As a starting point of the workshop participants will convert their laptops into digital multichannel Theremins to develop further, during the workshop different interactive audio/video installations, motion capturing systems, unusual gestural interfaces, 3D Theremins, digital Terpsitones and other unusual musical instruments. The workshop is oriented on sound and media artists, composers and musicians, who have particular interest in sound art and interactive systems, forgotten history and musical technology in general. The theoretical introductions, which accompany a workshop, give detailed technical overview of sensor technology and construction, basic principles of operation of the theremin based systems, art and music applications, useful concepts and ideas, condensed historical content, mostly related to almost forgotten historical facts. Participants will learn = How to detect different sorts of motion and measure it = How to monitor very small variations of electrical parameters = How to deal with the data acquired = How to integrate these systems into musical performance, dance, video, sound and art installations = How to build multichannel sensor systems based on Arduino microcontrollers = How to program new instruments and perform with them Requirements Each participant should have a computer with an audio input and headphones. All computers and software should be configured and checked in advance (!). Minimal configuration 1. Laptop with PD or MAX/MSP installed 2. Stereo audio input 3. Personal headphones 4. All appropriate cables 5. Appropriate amount of power plugs Useful options Experienced participants interested in development of multichannel theremin-sensor systems should bring multichannel sound cards or Arduino microcontrollers which will be converted into multichannel USB theremins. For those who hate computers and interested in pure analog circuits some breadboards will be very useful. Software Participants should have some skills in PD or MAX/MSP programming. It is also possible to work with any favorite software, oriented on interactive systems development, which allow external control via OSC or MIDI (Supercollider, Isadora etc.). In all cases control data will be provided via MAX/MSP runtime or PD patches from instructor's library. It is important to remember that in many cases the use of extra software will result in significant increase of latency and other possible timing problems. Analog and digital USB sensors for testing, experimenting and performance as well as all appropriate software libraries will be provided by instructor as well as different stuff for antenna construction. ========================================= =Schedule= Day#1 10:00 - 12:00 - Lecture: Introduction to the Theremin Sensors and their applications. 12:00 - 13:00 - questions/break 13:00 - 17:00 - practical workshop Day#2 10:00 - 12:00 - Lecture: Multichannel t-sensor systems: development and programming. 12:00 - 13:00 - questions/break 13:00 - 17:00 - practical workshop. Participants can bring their own materials and antennas to experiment with, or use already prepared stuff. Day#3 10:00 - 12:00 - Lecture: Motion tracking and beyond. Overview and comparison of different concepts. 12:00 - 13:00 - questions/break 13:00 - 17:00 - practical workshop. Participants are working on their projects developing installations and performances for the final presentation. Day#4 10:00 - 12:00 - Lecture: Hot riding t-sensors. Tips and tricks. 12:00 - 13:00 - questions/break 13:00 - 17:00 - practical workshop. Participants are working on their projects developing installations and performances for the final presentation. Last day Last preparations and final presentation of results Schedule will be announced ========================================== Learn More: http://asmir.theremin.ru/tsensors.htm -- ::: derek holzer ::: http://blog.myspace.com/macumbista ::: http://www.vimeo.com/macumbista ::: ---Oblique Strategy # 108: "Look closely at the most embarrassing details and amplify them" _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

dollarsign expansion in qlist
by Matt Barber 05 May '09

05 May '09

Hello, I'm sure this question has been asked numerous times. Is it possible to read a qlist from a file which has been edited and saved beforehand, in order to send messages to a receive symbol that has a $0 -- say, [r $0-test]? Thanks, Matt

2 2

Piksel09 :: Call for Projects
by h220 05 May '09

05 May '09

[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]] ** Piksel09 november 19-22 2009 Bergen, Norway [[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]] Piksel [1] is an international event for artists and developers working with Free/Libre and Open Source technologies in artistic practice. Part workshop, part festival, it is organised in Bergen, Norway,and involves participants from more than a dozen countries exchanging ideas, coding, presenting art and software projects, doing workshops, performances and discussions on the aesthetics and politics of FLOSS & art. This years event - Piksel09 - continues the exploration of free/libre and open source technologies and it’s myriad of expressions within the arts. Piksel09 is organised in collaboration with Gallery 3,14 [2] and Lydgalleriet [3] which will host this years exhibitions, Bergen Kunstmuseum [4] hosting the presentations and panels, and Bergen Kunsthall/Landmark [5] hosting the evening events. [[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]] ** open CALL for PROJECTS For the exhibitions and other parts of the programme we currently seek projects in the following categories: 1. Installations Projects to be included in the exhibitions at Galleri 3,14 and Lydgalleriet. The works must be programmed by and running on free and open source software and/or open/DIY hardware. 2. Audiovisual performance Live art realised by the use of free and open source software. We specially encourage live coding and open/DIY hardware projects to apply. 3. Presentations Innovative DIY hardware and audiovisual software tools or software art released under an open licence. (Also includes presentations of artistic projects realised using these technologies.) 4. Workshops Hands on workshops utilising free software and/or open/DIY hardware for artistic use. !!!!!!!!!! Deadline - july 15. 2009 !!!!!!!!!! Please use the online submit form at: http://piksel.no/ocs or send documentation material - preferably as a URL to online documentation with images/video to piksel09 [AT] piksel [DOT] no [[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]] Contact: Piksel att: Gisle Fr0ysland Georgernes Verft 12 5011 Bergen Norway More info: http://www.piksel.no Piksel09 is supported by Arts Council Norway, City of Bergen Cultural Office, Hordaland County Cultural Office and others. links: [1] http://www.piksel.no [2] http://www.stiftelsen314.com [3] http://www.lydgalleriet.no [4] http://www.bergenartmuseum.no [5] http://www.kunsthall.no/default.asp?k=6 --

1 0

Crash on WindowsVista
by jack＠rybn.org 04 May '09

04 May '09

Pd crash on Pd-extended 0.40.3 downloaded on http://puredata.info/downloads (stable). The problem occur with [route] and/or [select]. Here the patch. ++ Jack

3 4

throw~/catch~ headroom
by brandon zeeb 04 May '09

04 May '09

Hey PD-List, Has the throw~/catch~ system been designed to have a different available headroom than standard [+~] and [*~] objects? I've been designing a few polyphonic patches and have decided to use throw~/catch~ instead of hard-wiring the summing bus. I've found that when the signal approaches 1.0, distortion occurs. Has this been designed as such for a reason? Cheers, ~Brandon

4 4

Re: [PD] throw~/catch~ headroom
by IOhannes m zmölnig 03 May '09

03 May '09

hi including the mailing list again, as i guess that you already know what i am talking about... Andy Farnell wrote: > > A patch with N contributory signals, like an additive synth. > The mix is (s1 + s2 + s3 ... sN) / N > If each voice has a small DC offset then the sum will eventually drift > outside the bounds -1.0 +1.0. When it happens in Pd the output goes silent. what you are describing is valid for _any_ signal addition (whether it uses throw~/catch~, an explicit [+~] or implicit addition by connecting several signal-cords to a single inlet~. apart from that it is not true at all. if each voice has a small DC offset of Âµ (for the lack of epsilon on my keyboard), where Âµ is max(abs(DCn)) then the sum of the offsets will be Âµ*N and since you are normalizing by N the resulting offset will be Âµ (since Âµ is actually an upper boundary of the real offsets, the real resulting offset will be guaranteed to be no more than Âµ) > > In some systems a certain safe way of working is to just add carelessly, > do the division and then use a single DC trap at the end to remove any > accumulated error in the sum. > > Most times this works fine in Pd. > > Otherwise you'd need N divisions and N [hip~] all before the sum which > is expensive. how come you assume a difference in the 2 approaches? since [hip~] is a linear-time-invariant system, applying it to the sum of the signals should yield the same result as applying it to each signal and then summing them. the differences are mainly in needed CPU-power; and you might get different artefacts due to floating-point precision. > > But sometimes, with at least 8 normalised signals, you get silence > at the [catch~ sum] even though there seems to be headroom. what do you need by "headroom"? "headroom" is usually used when a signal must not go beyond a certain threshold and you want to make sure that you stay clear off this threshold; this is important when dealing with fixed-point numbers, (e.g. as used by dacs on soundcards) there is nothing comparable with floating-point numbers. Pd uses floating point numbers throughout to represent signals. if you add to in-phase signals of amplitude 1, you will get a new signal of amplitude 2. no problem. the only problem arises is, when you send this signal to the [dac~], which acts as a link to a fixed-point unit (your soundcard), and thus superimposes the limitations of this device to the signal it receives: it will clip the signal between -1..+1 and quantize to whatever your audio API needs. if your signal has a DC offset above +1 (or below -1) then you will hear nothing. (and of course there are other problems with floating point, like adding a very big signal to a very low signal; or adding 10^8 0dbFS signals) but this really has nothing to do with [catch~] and applies to all adding of signals. > > I went looking at the dsp_add() function trying to clarify the way Pd > sums many signals. And also considered creation order issues and > which blocks are being summed... adding signals is usualy done by applying the "+" operator to corresponding samples :-) > > Replicating the problem is hard, but I had one just last week, a complex > musical patch (rjdj) that stopped working when you mixed in some more channels. > (though each individual channel seemed fine and had only tiny drift) so what was the output of the [catch~] bus? if you still have a version of this non-working patch lying around i would be happily have a look at it. > > In the end a hack I found always works is to use delay buffers > to replace throw/catch pairs. but a delay-buffer is a replacement for [send~]/[receive~] and not for [throw~]/[catch~]. it is a 1-to-n distribution rather than a n-to-1 summation. > > Another possible solution is to stage the bus, so have, say 8 signals throw > to bus-submix1 and another to bus-submix2 and then combine the two submix > buses. that's even more confusion. why would several stages lower the effect (rather than enlarge it)? > > Maybe someone more familiar with the code can speculate what is going on? > unfortunately my eee's speakers will not output much below 130 Hz so i cannot fully appreciate your patch now... however, attached is a slightly modified version with the sole purpose of proving that the two parts create the same result. (the only non-obvious part is the order-forcing of throw~-before-catch~ in order to make the 2 patches play sample-synchronously. mfgasdr IOhannes #N canvas 0 0 1001 529 10; #N canvas 0 0 916 353 direct 0; #X obj 109 92 osc~ 400; #X obj 110 133 *~; #X text 105 63 a raised signal with DC offset; #X obj 182 133 *~; #X obj 181 92 osc~ 401; #X obj 256 132 *~; #X obj 255 91 osc~ 402; #X obj 328 131 *~; #X obj 327 90 osc~ 403; #X obj 398 130 *~; #X obj 397 89 osc~ 404; #X obj 469 128 *~; #X obj 468 87 osc~ 405; #X obj 538 128 *~; #X obj 537 87 osc~ 406; #X obj 609 126 *~; #X obj 608 85 osc~ 407; #X obj 355 220 /~ 8; #X obj 354 246 hip~ 1; #X obj 334 275 outlet~; #X obj 350 45 inlet; #X connect 0 0 1 0; #X connect 0 0 1 1; #X connect 1 0 17 0; #X connect 3 0 17 0; #X connect 4 0 3 0; #X connect 4 0 3 1; #X connect 5 0 17 0; #X connect 6 0 5 0; #X connect 6 0 5 1; #X connect 7 0 17 0; #X connect 8 0 7 0; #X connect 8 0 7 1; #X connect 9 0 17 0; #X connect 10 0 9 0; #X connect 10 0 9 1; #X connect 11 0 17 0; #X connect 12 0 11 0; #X connect 12 0 11 1; #X connect 13 0 17 0; #X connect 14 0 13 0; #X connect 14 0 13 1; #X connect 15 0 17 0; #X connect 16 0 15 0; #X connect 16 0 15 1; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 20 0 0 1; #X connect 20 0 4 1; #X connect 20 0 6 1; #X connect 20 0 8 1; #X connect 20 0 10 1; #X connect 20 0 12 1; #X connect 20 0 14 1; #X connect 20 0 16 1; #X restore 117 129 pd direct sum; #N canvas 0 0 995 492 thrown 0; #X obj 356 423 outlet~; #X obj 558 82 inlet; #N canvas 0 0 943 342 stage1 0; #X obj 141 134 osc~ 400; #X obj 142 175 *~; #X obj 214 175 *~; #X obj 213 134 osc~ 401; #X obj 288 174 *~; #X obj 287 133 osc~ 402; #X obj 360 173 *~; #X obj 359 132 osc~ 403; #X obj 430 172 *~; #X obj 429 131 osc~ 404; #X obj 501 170 *~; #X obj 500 129 osc~ 405; #X obj 570 170 *~; #X obj 569 129 osc~ 406; #X obj 641 168 *~; #X obj 640 127 osc~ 407; #X obj 142 219 throw~ sum; #X obj 213 245 throw~ sum; #X obj 288 208 throw~ sum; #X obj 359 234 throw~ sum; #X obj 431 206 throw~ sum; #X obj 502 232 throw~ sum; #X obj 571 204 throw~ sum; #X obj 640 230 throw~ sum; #X obj 558 82 inlet; #X obj 375 305 outlet~; #X connect 0 0 1 0; #X connect 0 0 1 1; #X connect 1 0 16 0; #X connect 2 0 17 0; #X connect 3 0 2 0; #X connect 3 0 2 1; #X connect 4 0 18 0; #X connect 5 0 4 0; #X connect 5 0 4 1; #X connect 6 0 19 0; #X connect 7 0 6 0; #X connect 7 0 6 1; #X connect 8 0 20 0; #X connect 9 0 8 0; #X connect 9 0 8 1; #X connect 10 0 21 0; #X connect 11 0 10 0; #X connect 11 0 10 1; #X connect 12 0 22 0; #X connect 13 0 12 0; #X connect 13 0 12 1; #X connect 14 0 23 0; #X connect 15 0 14 0; #X connect 15 0 14 1; #X connect 24 0 0 1; #X connect 24 0 3 1; #X connect 24 0 5 1; #X connect 24 0 7 1; #X connect 24 0 9 1; #X connect 24 0 11 1; #X connect 24 0 13 1; #X connect 24 0 15 1; #X restore 355 223 pd stage1; #N canvas 0 0 450 300 stage2 0; #X obj 222 213 /~ 8; #X obj 222 189 catch~ sum; #X obj 223 237 hip~ 1; #X obj 153 120 inlet~; #X obj 223 259 outlet~; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 2 0 4 0; #X restore 355 313 pd stage2; #X text 378 271 just for order-forcing; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 0 0; #X restore 223 128 pd thrown sum; #X text 118 70 play with adding more throw signals until it breaks ; #X obj 143 164 -~; #X obj 143 186 env~; #X floatatom 143 208 5 0 0 0 - - -; #X obj 223 186 env~; #X floatatom 223 208 5 0 0 0 - - -; #X obj 93 186 env~; #X floatatom 93 208 5 0 0 0 - - -; #X msg 468 104 \; pd dsp 1; #X obj 202 110 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X connect 0 0 3 0; #X connect 0 0 8 0; #X connect 1 0 3 1; #X connect 1 0 6 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 6 0 7 0; #X connect 8 0 9 0; #X connect 11 0 0 0; #X connect 11 0 1 0;

1 0

Re: [PD] CDM articles about Pd - contribution?
by Marco Donnarumma 03 May '09

03 May '09

@Luigi / list: let's say... for ex. i wouldn't like to write about how to do a video mixer in pd. Many people are working on manuals, doing an excellent work. My idea is: 1_ To show to a broad audience what Pd is capable to do with *audio/video processing *and/or* physical computing* in the *live video - live media*enviroment. This doesn't mean that the example should be hyper-basic, neither hyper-complex. The target of this "action" on CDM is the audience who already patch something, somehow. I want to show that there is no need to buy ableton+the newest max to do suggestive* audiovideo processing*, or *sound-reactive video*, or *video-reactive sounds *but instead you can use Pd and be really happy with it. I keep on noticing that many people has the stereotype of Pd as a rough software, which can build nice stuff, but with incredible and unhuman efforts, having the screen fullfilled of chords building strange shapes. This is scary for most of them. We know that one can use Pd this way, but on the other hand one can build wonderful (easthetically and practically) patches. i saw through this list amazing pieces, even little utilities... i remember a monome sequencer which was a jewel also because of its great interface, and another patch which was creating fluid movements of semi-transparent - multicolor circles. The examples i would like to collect don't have to be absolutely innovative (if they are then,.. great!) but also simple utilities which fit in the description above. Naturally all the example i will write about will be linked to their author. 2_On the other side i would like to open a window on the Pd community, reporting the most important announcements: from a new release, the publication of a book, a call for the next conference and so on... highlighting the activity of the community. @Jose: that sounds great, but i think there is a lot to say about that, isn't it? Maybe it's something to be divided in episodes? -- Marco Donnarumma aka The !S.A.D! Multimedia Artist, Live Performer Roma, IT LAB: http://www.thesaddj.com | http://www.flxer.net EVENT: http://www.liveperformersmeeting.net

1 0

core distribution for audio/GEM?
by potax flan 02 May '09

02 May '09

Hi all, in a patch i'm writing which uses audio objects and simple GEM processes, i get audio clicks whenever GEM is rendering stuff. Since i'm doing this on a fairly new dual-core mac, i was wondering, is there a way to separate processes or even patches (gem/audio) so that each core takes care of different tasks? sorry if this is too dumb but it'd e truly great to take advantage of that kind of thing instead of having to use 2 machines best, p

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list May 2009