Pd-list July 2003

pd-list@lists.iem.at

127 participants
191 discussions

RE: [PD] FM problems
by Matthew Allen 18 Jul '03

18 Jul '03

Yeah it's the dynamic output matrix that I think is just such an elegant design. Frank thanks for your props! Your work with GUI stuff has really gotten me into doing much more complex 'tricks' with the iemlib (I've mad a couple of complex guis, like a tabbed browser and 16 [bng] objects that show which one was banged last). Some day I'll finish my step sequencer (which contains a lot of these tricks) and send it out. Lately I have been getting more into doing funny GUI logic stuff than writing patches :) m. > -----Original Message----- > From: Frank Barknecht [mailto:fbar@footils.org] > Sent: Friday, July 18, 2003 10:56 AM > To: 'pd-list(a)iem.kug.ac.at ' > Subject: Re: [PD] FM problems > > Hallo, > Hey, this is a wonderful trick. Looks mighty cool! > But the DX7 also had an operator matrix (a static one, though).

1 0

RE: [PD] FM problems
by Matthew Allen 18 Jul '03

18 Jul '03

I took a quick look at your patch this morning, and oddly enough it crashes on my windows machines also. So I dont think it is your feedback loops, and actually with just a quick look at your patch I think you have a lot of unneccesary stuff in there (mostly in the pitch control area.) Maybe this mught be affecting it? Ill try and have a closer look at it this weekend, also If I can get it cleaned up a bit (no extra crap) I'll send my 3-op phase Mod synth to you so you cancompare/contrast. m. -----Original Message----- From: matthijs(a)devdsp.net To: pd-list(a)iem.kug.ac.at Sent: 7/17/2003 5:25 PM Subject: Re: [PD] FM problems Nope, using z~ 64 it still segfaults (using delwrite~ delread~ works, though). nop~ doesn't work either. FWIW, here's a copy of the new patch. Not sure if the z~ externals go where they should, but the basic problem still occurs. Could this be something Linux specific perhaps? On Thu, Jul 17, 2003 at 12:05:48PM -0700, Matthew Allen wrote: > > If you set up z~ to be larger than 1 (like say 64 or whatever your block > > size is) does it still give you the error? Could you send your new patch to > > the list and I can try it here. > > > > m. > > > > > -----Original Message----- > > > From: matthijs(a)devdsp.net [mailto:matthijs@devdsp.net] > > > Sent: Thursday, July 17, 2003 11:57 AM > > > To: Matthew Allen > > > Cc: pd-list(a)iem.kug.ac.at > > > Subject: Re: [PD] FM problems > > > > > > 0.36 on Linux, with whatever version of Zexy comes with the PD externals > > > package on sourceforge. > > > > > > On Thu, Jul 17, 2003 at 11:33:53AM -0700, Matthew Allen wrote: > > > > Hmm, Its running here fine. > > > > > > > > What version of stuff are you running and on what system. I'm running > > > .36 at > > > > home and .37r5 here at work. Both with whatever the latest version of > > > zexy > > > > is. On win2k machines both places. > > > > > > > > m. > > > > > > _______________________________________________ > > PD-list mailing list > > PD-list(a)iem.at > > http://iem.at/cgi-bin/mailman/listinfo/pd-list > > -- > take care, > > Matthijs de Jonge > http://devdsp.net - news and resources for computer musicians > #N canvas 253 265 446 311 10; > #N canvas 0 0 986 634 fmphasemodosc 1; > #X floatatom 72 78 5 0 0 0 - - -; > #X obj 72 143 phasor~; > #X text 65 32 carrier freq; > #X obj 151 289 osc~; > #X floatatom 161 48 5 0 0 0 - - -; > #X obj 58 421 +~; > #X obj 58 463 cos~; > #X obj 161 68 * 0.01; > #X obj 162 126 *; > #X obj 249 69 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 > -1; > #X obj 57 600 outlet~; > #X obj 72 53 inlet; > #X obj 215 38 inlet; > #X text 257 40 modfreq (mainfreq multiplier); > #X obj 484 44 inlet; > #X text 529 43 mod weight; > #X floatatom 482 74 5 0 100 0 - - -; > #X obj 481 102 * 0.01; > #X obj 151 313 *~; > #X obj 614 45 inlet; > #X obj 614 85 * 0.01; > #X obj 290 510 *~; > #X floatatom 615 66 5 0 0 0 - - -; > #X obj 611 134 abs; > #X obj 468 159 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 > -1; > #X floatatom 124 185 5 0 0 0 - - -; > #X obj 71 119 +~; > #X floatatom 227 123 5 0 0 0 - - -; > #X obj 150 337 *~; > #X floatatom 611 158 5 0 0 0 - - -; > #X obj 150 377 +~; > #X obj 612 110 - 1; > #X text 656 41 feedback1 (main output); > #X obj 714 79 inlet; > #X text 764 82 feedback - modifier; > #X text 765 102 feeding back onto itself; > #X obj 717 133 * 0.01; > #X floatatom 718 114 5 0 0 0 - - -; > #X obj 714 182 abs; > #X floatatom 714 206 5 0 0 0 - - -; > #X obj 715 158 - 1; > #X obj 135 209 sig~; > #X obj 146 240 *~; > #X obj 259 206 *~; > #X obj 138 266 +~; > #X obj 614 310 zexy; > #X text 650 311 this loads zexy (d'uh); > #X text 651 332 zexy contains the z~ object; > #X text 649 351 which allows you to delay something; > #X text 651 367 by a set number of samples; > #X msg 613 277 help; > #X obj 347 301 z~ 64; > #X obj 358 565 z~ 64; > #X connect 0 0 8 1; > #X connect 0 0 9 0; > #X connect 0 0 26 0; > #X connect 1 0 5 1; > #X connect 3 0 18 0; > #X connect 3 0 51 0; > #X connect 4 0 7 0; > #X connect 5 0 6 0; > #X connect 6 0 10 0; > #X connect 6 0 21 0; > #X connect 7 0 8 0; > #X connect 7 0 27 0; > #X connect 8 0 25 0; > #X connect 9 0 4 0; > #X connect 11 0 0 0; > #X connect 12 0 4 0; > #X connect 14 0 16 0; > #X connect 16 0 17 0; > #X connect 17 0 18 1; > #X connect 18 0 28 0; > #X connect 19 0 22 0; > #X connect 20 0 21 1; > #X connect 20 0 31 0; > #X connect 21 0 52 0; > #X connect 22 0 20 0; > #X connect 22 0 24 0; > #X connect 23 0 29 0; > #X connect 24 0 4 0; > #X connect 25 0 41 0; > #X connect 26 0 1 0; > #X connect 28 0 30 0; > #X connect 29 0 28 1; > #X connect 30 0 5 0; > #X connect 31 0 23 0; > #X connect 33 0 37 0; > #X connect 36 0 40 0; > #X connect 37 0 36 0; > #X connect 37 0 43 1; > #X connect 38 0 39 0; > #X connect 39 0 42 1; > #X connect 40 0 38 0; > #X connect 41 0 42 0; > #X connect 42 0 44 0; > #X connect 43 0 44 1; > #X connect 44 0 3 0; > #X connect 50 0 45 0; > #X connect 51 0 43 0; > #X connect 52 0 30 1; > #X restore 162 243 pd fmphasemodosc; > #X obj 162 268 outlet~; > #X obj 27 59 vsl 15 128 0 15000 0 0 empty empty Freq 0 -8 0 8 -262144 > -1 -1 0 1; > #X floatatom 27 205 5 0 0 0 - - -; > #X obj 111 60 vsl 15 128 0 1500 0 0 empty empty ModFactor 0 -8 0 8 > -262144 -1 -1 0 1; > #X floatatom 111 204 5 0 0 0 - - -; > #X obj 186 60 vsl 15 128 0 100 0 0 empty empty ModWeight 0 -8 0 8 -262144 > -1 -1 0 1; > #X floatatom 186 205 5 0 0 0 - - -; > #X obj 27 15 inlet; > #X obj 110 18 inlet; > #X obj 186 19 inlet; > #X obj 285 64 vsl 15 128 0 100 0 0 empty empty Feedback1 0 -8 0 8 -262144 > -1 -1 0 1; > #X floatatom 285 209 5 0 0 0 - - -; > #X obj 286 22 inlet; > #X obj 352 64 vsl 15 128 0 100 0 0 empty empty Feedback2 0 -8 0 8 -262144 > -1 -1 0 1; > #X floatatom 352 209 5 0 0 0 - - -; > #X obj 353 22 inlet; > #X obj 264 276 dac~; > #X connect 0 0 1 0; > #X connect 2 0 3 0; > #X connect 3 0 0 0; > #X connect 4 0 5 0; > #X connect 5 0 0 1; > #X connect 6 0 7 0; > #X connect 7 0 0 2; > #X connect 8 0 2 0; > #X connect 9 0 4 0; > #X connect 10 0 6 0; > #X connect 11 0 12 0; > #X connect 12 0 0 3; > #X connect 13 0 11 0; > #X connect 14 0 15 0; > #X connect 15 0 0 4; > #X connect 16 0 14 0; > #X coords 0 0 1 1 200 140 1; -- take care, Matthijs de Jonge http://devdsp.net - news and resources for computer musicians <<fm_phasemod_dualfb_linear_segfaults.pd>>

4 4

Re: [PD] GEM and transparency
by bbogart＠ryerson.ca 18 Jul '03

18 Jul '03

hey Johannes, I do a lot with separator and groups, usually I have a series of abstractions which stand in for geometry, and being able to use an argument as the render order makes a lot more sense that trying to trigger a undetermined number of objects to go in the correct order. Ben ----- Original Message ----- From: zmoelnig(a)iem.at Date: Friday, July 18, 2003 9:42 am Subject: Re: [PD] GEM and transparency > Zitiere bbogart(a)ryerson.ca: > > > Hey Martin, > > > > your problem is render-order not transparency. transparency only > workstrue > > > Gemheads with smaller numbers get rendered first (0-1-2-3-4 > etc..) and > > the same goes for separators, > hey, this is news to me. > i cannot think of any way how to achieve this (from the > programmer's side, of > course), without getting a *lot* of timing problems. > if you really need a specific rendering order with several > separators, you'll > have to do what you have to do in pd to acchieve a certain order > of message- > execution (basically Gem is message based): use "trigger" > > sketch: > > [gemlist( > | > [t a a] > | | > [gemlist2( [gemlist1( > > > > > > I've attached a demo example to make things more clear > > > i'll have a look at this. > however, i will *strongly* recommend to not rely on a feature like > the ordering > of several gem-sublists by giving an argument to [separator]. > it will be really confusing to ignore pd's way of handling such > problem. > > mfg.as.r > IOhannes > > _______________________________________________ > PD-list mailing list > PD-list(a)iem.at > http://iem.at/cgi-bin/mailman/listinfo/pd-list >

1 0

pix_alpha and RGB
by Martin Dupras 18 Jul '03

18 Jul '03

Another quick one: In the help file for pix_alpha, it says that pix_alpha handles the RGB values of a pix. If I connect it to a chain [gemhead] | [pix_video] | [pix_texture] | [pix_alpha] pix_alpha complains with "error: Gem: pix object cannot handle RGB image". Is that a bug, or am I missing something? - martin

1 0

line and line~
by august 18 Jul '03

18 Jul '03

hmm. did pd0.36 allow [*~] to take a signal on it's right input? i did a patch that worked fine at a friends house with pd0.36 under windows and now under linux with 0.37 it don't seem to work right. and, does anyone else get clicks when they connect and use a slider or a [line] to a [*~] ?? what worked smoothly with [line~] on the right inlet of [*~] no longer works. doing a [line] to the right inlet of [*~] makes clicks. any suggestions. I must be missing something. -august.

5 9

Re: [PD] GEM and transparency
by bbogart＠ryerson.ca 18 Jul '03

18 Jul '03

Hey Martin, your problem is render-order not transparency. transparency only works in one direction, so you have to tell Gem the stacking order from back to front for things to look properly transparent. Gemheads with smaller numbers get rendered first (0-1-2-3-4 etc..) and the same goes for separators, just specify the render order (back to front) as an argument to the sepatators. I've attached a demo example to make things more clear Ben ----- Original Message ----- From: Martin Dupras <martin.dupras(a)uwe.ac.uk> Date: Thursday, July 17, 2003 7:30 pm Subject: [PD] GEM and transparency > I have a peculiar problem. > > I'm taking a video feed with pix_video then applying it as a > texture to > three squares, each connected to [alpha] and [colorRGB v1 v2 v3], > wherethe first square is red only, the second green, and the third > blue. > Now I want to superimpose the three squares so that I can > translate them > independently. > > One approach that I tried was using one gemhead, the pix_video and > textures2 objects, then using separator to feed to the three > squares. It > works but if I set the transparency of any square to anything > other than > 0, the black obscures the squares behind. > > I tried another approach, where I used three different chains, but > thenonly one of the chains can access the video feed. > > Questions: > > 1) is there a way to make transparency work such that "black" > pixels are > transparent? > > 2) is there a way to make several [pix_video] objects access the same > video feed? > > Many thanks! > > - martin > > > > _______________________________________________ > PD-list mailing list > PD-list(a)iem.at > http://iem.at/cgi-bin/mailman/listinfo/pd-list >

2 1

"expensive" sqrt~
by Roman Haefeli 18 Jul '03

18 Jul '03

hi does anybody know an external like (sqrt~), but with a higher resolution than 8-bit? thnaks --------------------------------- Gesendet von http://mail.yahoo.de Jetzt buchen! Tolle Best Price Angebote bei Expedia.de, dem groÃen Online-ReisebÃ¼ro.

3 2

fluid~ : add_history unresolved?
by Larry Troxler 18 Jul '03

18 Jul '03

Hi, does anyone know where add_history is defined? When I create a fluid~, this is what happens: /usr/lib/pd/extra/fluid~.pd_linux: /usr/lib/pd/extra/fluid~.pd_linux: undefined symbol: add_history fluid~ ... couldn't create Thanks! Larry

2 2

Re: [PD] FM problems
by matthijs＠devdsp.net 18 Jul '03

18 Jul '03

Nope, using z~ 64 it still segfaults (using delwrite~ delread~ works, though). nop~ doesn't work either. FWIW, here's a copy of the new patch. Not sure if the z~ externals go where they should, but the basic problem still occurs. Could this be something Linux specific perhaps? On Thu, Jul 17, 2003 at 12:05:48PM -0700, Matthew Allen wrote: > > If you set up z~ to be larger than 1 (like say 64 or whatever your block > > size is) does it still give you the error? Could you send your new patch to > > the list and I can try it here. > > > > m. > > > > > -----Original Message----- > > > From: matthijs(a)devdsp.net [mailto:matthijs@devdsp.net] > > > Sent: Thursday, July 17, 2003 11:57 AM > > > To: Matthew Allen > > > Cc: pd-list(a)iem.kug.ac.at > > > Subject: Re: [PD] FM problems > > > > > > 0.36 on Linux, with whatever version of Zexy comes with the PD externals > > > package on sourceforge. > > > > > > On Thu, Jul 17, 2003 at 11:33:53AM -0700, Matthew Allen wrote: > > > > Hmm, Its running here fine. > > > > > > > > What version of stuff are you running and on what system. I'm running > > > .36 at > > > > home and .37r5 here at work. Both with whatever the latest version of > > > zexy > > > > is. On win2k machines both places. > > > > > > > > m. > > > > > > _______________________________________________ > > PD-list mailing list > > PD-list(a)iem.at > > http://iem.at/cgi-bin/mailman/listinfo/pd-list > > -- > take care, > > Matthijs de Jonge > http://devdsp.net - news and resources for computer musicians > #N canvas 253 265 446 311 10; > #N canvas 0 0 986 634 fmphasemodosc 1; > #X floatatom 72 78 5 0 0 0 - - -; > #X obj 72 143 phasor~; > #X text 65 32 carrier freq; > #X obj 151 289 osc~; > #X floatatom 161 48 5 0 0 0 - - -; > #X obj 58 421 +~; > #X obj 58 463 cos~; > #X obj 161 68 * 0.01; > #X obj 162 126 *; > #X obj 249 69 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 > -1; > #X obj 57 600 outlet~; > #X obj 72 53 inlet; > #X obj 215 38 inlet; > #X text 257 40 modfreq (mainfreq multiplier); > #X obj 484 44 inlet; > #X text 529 43 mod weight; > #X floatatom 482 74 5 0 100 0 - - -; > #X obj 481 102 * 0.01; > #X obj 151 313 *~; > #X obj 614 45 inlet; > #X obj 614 85 * 0.01; > #X obj 290 510 *~; > #X floatatom 615 66 5 0 0 0 - - -; > #X obj 611 134 abs; > #X obj 468 159 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 > -1; > #X floatatom 124 185 5 0 0 0 - - -; > #X obj 71 119 +~; > #X floatatom 227 123 5 0 0 0 - - -; > #X obj 150 337 *~; > #X floatatom 611 158 5 0 0 0 - - -; > #X obj 150 377 +~; > #X obj 612 110 - 1; > #X text 656 41 feedback1 (main output); > #X obj 714 79 inlet; > #X text 764 82 feedback - modifier; > #X text 765 102 feeding back onto itself; > #X obj 717 133 * 0.01; > #X floatatom 718 114 5 0 0 0 - - -; > #X obj 714 182 abs; > #X floatatom 714 206 5 0 0 0 - - -; > #X obj 715 158 - 1; > #X obj 135 209 sig~; > #X obj 146 240 *~; > #X obj 259 206 *~; > #X obj 138 266 +~; > #X obj 614 310 zexy; > #X text 650 311 this loads zexy (d'uh); > #X text 651 332 zexy contains the z~ object; > #X text 649 351 which allows you to delay something; > #X text 651 367 by a set number of samples; > #X msg 613 277 help; > #X obj 347 301 z~ 64; > #X obj 358 565 z~ 64; > #X connect 0 0 8 1; > #X connect 0 0 9 0; > #X connect 0 0 26 0; > #X connect 1 0 5 1; > #X connect 3 0 18 0; > #X connect 3 0 51 0; > #X connect 4 0 7 0; > #X connect 5 0 6 0; > #X connect 6 0 10 0; > #X connect 6 0 21 0; > #X connect 7 0 8 0; > #X connect 7 0 27 0; > #X connect 8 0 25 0; > #X connect 9 0 4 0; > #X connect 11 0 0 0; > #X connect 12 0 4 0; > #X connect 14 0 16 0; > #X connect 16 0 17 0; > #X connect 17 0 18 1; > #X connect 18 0 28 0; > #X connect 19 0 22 0; > #X connect 20 0 21 1; > #X connect 20 0 31 0; > #X connect 21 0 52 0; > #X connect 22 0 20 0; > #X connect 22 0 24 0; > #X connect 23 0 29 0; > #X connect 24 0 4 0; > #X connect 25 0 41 0; > #X connect 26 0 1 0; > #X connect 28 0 30 0; > #X connect 29 0 28 1; > #X connect 30 0 5 0; > #X connect 31 0 23 0; > #X connect 33 0 37 0; > #X connect 36 0 40 0; > #X connect 37 0 36 0; > #X connect 37 0 43 1; > #X connect 38 0 39 0; > #X connect 39 0 42 1; > #X connect 40 0 38 0; > #X connect 41 0 42 0; > #X connect 42 0 44 0; > #X connect 43 0 44 1; > #X connect 44 0 3 0; > #X connect 50 0 45 0; > #X connect 51 0 43 0; > #X connect 52 0 30 1; > #X restore 162 243 pd fmphasemodosc; > #X obj 162 268 outlet~; > #X obj 27 59 vsl 15 128 0 15000 0 0 empty empty Freq 0 -8 0 8 -262144 > -1 -1 0 1; > #X floatatom 27 205 5 0 0 0 - - -; > #X obj 111 60 vsl 15 128 0 1500 0 0 empty empty ModFactor 0 -8 0 8 > -262144 -1 -1 0 1; > #X floatatom 111 204 5 0 0 0 - - -; > #X obj 186 60 vsl 15 128 0 100 0 0 empty empty ModWeight 0 -8 0 8 -262144 > -1 -1 0 1; > #X floatatom 186 205 5 0 0 0 - - -; > #X obj 27 15 inlet; > #X obj 110 18 inlet; > #X obj 186 19 inlet; > #X obj 285 64 vsl 15 128 0 100 0 0 empty empty Feedback1 0 -8 0 8 -262144 > -1 -1 0 1; > #X floatatom 285 209 5 0 0 0 - - -; > #X obj 286 22 inlet; > #X obj 352 64 vsl 15 128 0 100 0 0 empty empty Feedback2 0 -8 0 8 -262144 > -1 -1 0 1; > #X floatatom 352 209 5 0 0 0 - - -; > #X obj 353 22 inlet; > #X obj 264 276 dac~; > #X connect 0 0 1 0; > #X connect 2 0 3 0; > #X connect 3 0 0 0; > #X connect 4 0 5 0; > #X connect 5 0 0 1; > #X connect 6 0 7 0; > #X connect 7 0 0 2; > #X connect 8 0 2 0; > #X connect 9 0 4 0; > #X connect 10 0 6 0; > #X connect 11 0 12 0; > #X connect 12 0 0 3; > #X connect 13 0 11 0; > #X connect 14 0 15 0; > #X connect 15 0 0 4; > #X connect 16 0 14 0; > #X coords 0 0 1 1 200 140 1; -- take care, Matthijs de Jonge http://devdsp.net - news and resources for computer musicians

1 0

GEM and transparency
by Martin Dupras 18 Jul '03

18 Jul '03

I have a peculiar problem. I'm taking a video feed with pix_video then applying it as a texture to three squares, each connected to [alpha] and [colorRGB v1 v2 v3], where the first square is red only, the second green, and the third blue. Now I want to superimpose the three squares so that I can translate them independently. One approach that I tried was using one gemhead, the pix_video and textures2 objects, then using separator to feed to the three squares. It works but if I set the transparency of any square to anything other than 0, the black obscures the squares behind. I tried another approach, where I used three different chains, but then only one of the chains can access the video feed. Questions: 1) is there a way to make transparency work such that "black" pixels are transparent? 2) is there a way to make several [pix_video] objects access the same video feed? Many thanks! - martin

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
20
Older →

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 July 2003