PURE DATA forum~

Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Advanced Search

Posted by

In Categories Search child categories

Reply Count

Post time

Sort by

Show results as

Posts Topics

Save preferences Clear preferences

26 result(s) matching "detect-wether-connexion-given-inlet", (0.03 seconds)

Spectral synthesis

I'm trying to play with help patches. For instance, with morphine the errors are these:

morphine~
... couldn't create
error: inlet: expected '' but got 'transition'
... you might be able to track this down from the Find menu.
error: signal outlet connect to nonsignal inle morphine~
... couldn't create
error: inlet: expected '' but got morphine~
... couldn't create
error: inlet: expected '' but got 'transition'
... you might be able to track this down from the Find menu.
error: signal outlet connect to nonsignal inle morphine~
... couldn't create
error: inlet: expected '' but got 'transition'
... you might be able to track this down from the Find menu.
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
t (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
'transition'
... you might be able to track this down from the Find menu.
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
t (ignored)
error: signal outlet connect to nonsignal inlet (ignored)

and then

error: inlet: expected '' but got 'float'

Thanks for the help

posted in technical issues

Recording GEM output to files

Never mind... I think I pretty much got it figured out now. I got a bunch of tiff files on my hard drive. Thanks to Ulrich Kehrer's post on the PD mailing list dated Tue Nov 27 15:02:08 CET 2001:

quote:
"... pix_write has to be the last object of the gem-list (for example you have
to connect the OUTLET of a cube object to the inlet of pix_write)
pix_write's 2nd inlet understands a list of 2 integers which corresponds=20
to the lower left corner of your snapshot (xy position). the 3rd inlet
also accepts a list of 2 integers which is the snapshot's size (xy size).
for example if your gemwin has 640x480 px and you want to grab the whole
win you have send "0 0" to the 2nd and "640 480" to the 3rd inlet. if you
just want to grab a 100x100px area from the center of the gemwin send "270
190" to the 3nd and "100 100" to the 3rd inlet ...
(the messages "vert_pos x y" and "vert_size x y" both to the 1st inlet do
the same as "x y" (position) to the second and "x y" (size) to the 3rd
inlet). was this clear?!?

the snapshots will be saved in the pd/bin directory with successive
numbers as tif files (gemmgem100000.tif).
i didn't find out yet how to tell pix_write a costum place to save the
tiffs and how to change the default name and the starting
number. ...johannes?

with a "metro 40" banging pix_write i grabbed a few seconds with
720x576px at 25fps. it was a patch with 9 cubes spinning around and i
noticed that pd/gem waited with the action until a snapshot was written to
disk. the 5 seconds i "recorded" took about 30 seconds to be saved. i then
got a 125 frame tiff-sequence with a smooth movement just like in the
gemwin. that's cool! can anyone explain this behavior?

cheers,
ulrich

..."

posted in pixel#

Which patch is faster?

These are two abbreviated versions of a patch I'm working on.

As far as I can tell, these two patches do the exact same thing. In both patches, after the right inlet is set, changing the left inlet will either a) send 1's to the object boxes when the inlets are different, or send 0's to the object boxes and then trigger the bangs when the inlets are the same.

Some questions I have:

1. Am I overlooking anything? Are they really exactly the same (in terms of function)?

2. [sel] and [sel 0] apparently work the same if the right inlet is avoided. Is there a good reason to use one and not the other?

3. Which of the two (if any) is cheaper processor-wise, or which of the two is faster (and why)?

4. Is there an even better way to do this?

5. I'm working on Windows XP and I tried using [cputime] but either I don't really know how to use it, or it doesn't work the way I expect it to. I guess what confuses me is that the right inlet is hot, not cold... anyway, any clarification will be appreciated.

This part of the patch will have to fire thousands of times very fast, so speed is definitely a priority. Thanks very much in advance -- this forum is great!

http://www.pdpatchrepo.info/hurleur/which-is-faster.pd

posted in patch~

Lemur with OSCx

Anyone have a rough idea for a patch to send and receive integers and floats to+from a lemur and pd (Jazzmutant Lemur). The one I've got functions with Max/MSP, successful results.

If rig specifications help,

The port I chose for the lemur to utilize with Max/MSP was 8000.
It seems the dumpOSC object has issues with the argument 8000. The object won't create. Additionally, though the oscx seems to have loaded, the prepend send object with arguments /box/led also does not manifest itself and the _help-40h.pd patch and OSCplumbing subpatch seem to offer resolutions to using OSC though I don't know exactly the manner. I've replaced their ports with 8000, nothine at all is printing, though the lemur has been operating properly with Max/msP all the while.

For those familiar with Max/MSP, the code to write a patch receiving lemur messages is: (and all below are objects, no messages, no duplications of objects, if listed twice, then it is same object)

"udpreceive 8000" , outlet connected with "zl nth 1" left inlet, "zl nth 1" 's left outlet to "prepend send" inlet. "zl nth 1" 's right outlet, however was connected with "zl reg" 's right inlet. "prend send" 's left outlet connected with "t b s" 's left inlet. "t b s" 's left outlet connected with "zl reg" 's left inlet. "t b s" 's right outlet connected with "forward" 's left inlet, "zl reg" 's left oulet connected with "forward" 's left inlet.

For udpsend, objects look like "/nameoflemurobject.value $1" with left inlet coming from float. left outlet goes to "udpsend (then ip adress) (then port number)"

With a request of any more information, I'll reply. If anything else comes to mind, I'll submit asap. If you desire patcher files for the above listed code, i'll attach it immediately. Ok.

posted in technical issues

\[resolved\] Still Bang

I'm not sure I read you correctly
but I think this is what you want
It follows the middle inlet but if
that stops changing then it follows
the leftmost inlet after a delay set
at the rightmost inlet.

#N canvas 477 470 533 436 10;
#X floatatom 24 207 5 0 0 0 - - -;
#N canvas 0 0 482 472 autowobble 0;
#X obj 117 185 average;
#X obj 117 157 delta;
#X obj 117 89 f;
#X obj 110 344 line;
#X msg 110 320 \$1 100;
#X obj 156 237 == 0;
#X obj 165 45 inlet;
#X obj 37 45 inlet;
#X text 20 26 lfo krate;
#X obj 110 368 outlet;
#X obj 140 273 *;
#X obj 117 237 != 0;
#X obj 76 70 t b;
#X obj 80 268 *;
#X obj 110 296 +;
#X obj 117 132 line;
#X obj 117 110 pack 1 200;
#X obj 291 49 inlet;
#X text 144 23 manual fader;
#X text 285 27 idle time;
#X connect 0 0 5 0;
#X connect 0 0 11 0;
#X connect 1 0 0 0;
#X connect 2 0 16 0;
#X connect 3 0 9 0;
#X connect 4 0 3 0;
#X connect 5 0 10 1;
#X connect 6 0 2 1;
#X connect 6 0 13 1;
#X connect 7 0 10 0;
#X connect 7 0 12 0;
#X connect 10 0 14 1;
#X connect 11 0 13 0;
#X connect 12 0 2 0;
#X connect 13 0 14 0;
#X connect 14 0 4 0;
#X connect 15 0 1 0;
#X connect 16 0 15 0;
#X connect 17 0 16 1;
#X restore 24 179 pd autowobble;
#X obj 24 70 vsl 12 64 1 200 0 0 empty empty lfo-period(ms) 0 -8 0
8 -225280 -1 -1 5400 1;
#N canvas 0 0 450 300 ktrilfo 0;
#X obj 186 93 del 10;
#X obj 144 93 t b f;
#X obj 186 135 f 0;
#X obj 220 136 +;
#X msg 235 104 1;
#X msg 276 104 -1;
#X obj 187 175 >= 127;
#X obj 136 177 <= 0;
#X obj 136 202 sel 1;
#X obj 187 203 sel 1;
#X obj 223 71 max 1;
#X obj 223 47 inlet;
#X text 204 27 sweep rate(ms);
#X obj 225 235 outlet;
#X text 226 262 bang per cycle;
#X text 80 259 int val;
#X obj 104 235 outlet;
#X obj 307 70 loadbang;
#X obj 321 44 inlet;
#X text 324 26 phase reset/start;
#X connect 0 0 2 0;
#X connect 1 0 0 0;
#X connect 2 0 1 0;
#X connect 2 0 3 0;
#X connect 2 0 6 0;
#X connect 2 0 7 0;
#X connect 2 0 16 0;
#X connect 3 0 2 1;
#X connect 4 0 3 1;
#X connect 5 0 3 1;
#X connect 6 0 9 0;
#X connect 7 0 8 0;
#X connect 8 0 4 0;
#X connect 8 0 13 0;
#X connect 9 0 5 0;
#X connect 10 0 0 1;
#X connect 11 0 10 0;
#X connect 17 0 2 0;
#X connect 18 0 2 0;
#X restore 24 143 pd ktrilfo;
#X obj 110 101 vsl 12 64 1 127 0 0 empty empty manual 0 -8 0 8 -225271
-1 -1 1500 1;
#X obj 159 101 vsl 12 64 1 1000 0 0 empty empty hold 0 -8 0 8 -261681
-1 -1 3700 1;
#X text 177 138 hold is NOT milliseconds;
#X text 178 172 internal func but is roughly 1/2*square of hold;
#X text 179 155 It's actually complicated because of aymptotic;
#X text 31 254 The value may jump quickly when the lfo resumes \, need
to add a crossing detector for smooth transition;
#X text 21 10 Autowobble - output follows the k-rate LFO input UNLESS
the manual fader is moved \, but after a delay set by HOLD the output
will resume tracking the LFO;
#X text 358 273 ajf2005;
#X connect 1 0 0 0;
#X connect 2 0 3 0;
#X connect 3 0 1 0;
#X connect 4 0 1 1;
#X connect 5 0 1 2;

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

posted in technical issues

Advanced Search

My live patch

Spectral synthesis

Recording GEM output to files

Which patch is faster?

Lemur with OSCx

\[resolved\] Still Bang