Hi,
I'm working on a patch (not the attached one which is an example that
isolates the problem), where from time to time I need to take a snapshot
of the whole scene and "draw" it as a texture on a rectangle which is on
the background.
(when the patch is finished I think I will be allowed to share it, for
what it's worth)
I have it all working fine, but than I came into a problem: sometimes, I
have to send a message to take the snapshot, and immediately after, send
some other message that changes something on the scene, which has to
happen AFTER the snapshot.
Since I am taking snapshots in the "classic" way, that is, opening a
spigot on the gemlist that comes to the [pix_snap], the snapshot is
actually deferred until the next render; this is a problem because I
need to "defer" any other message that has to take effet just after the
sbapshot; this can be done but i'd like to avoid all the complications.
I thought that a solution would be to force a render just after any
snapshot, by sending a bang to the gemhead that is rendering everithing.
However, the result is not what I expected and I really can't understand
why.
That's why I am asking for your help.
So, the attached patch is a simplification, in which I draw an initially
white square and a sphere. If you hit the big bang (sorry for the pun),
a snapshot of the scene is taken via [pix_snap] and it becomes the
texture of the square. You can use the number box to move the sphere around.
Now, if I make the connection where it says "connect this", what I am
doing is just provoking a bang to the gemhead just after opening the
spigot to the pix_snap. What I would expect is that it should work
exactly the same as before (with the difference that an extra frame is
rendered between two "normal" frames, and that's the moment the snapshot
is taken; but this difference should not be "visible").
However, the observed behaviour is not this. The snapshot that is taken
and "printed" on the texture is not the scene, but some aberration of
it. If you leave the sphere wher it is, it will usually render and snap
an all-black scene; but if you move the sphere to the back, behind the
square, the snapshot will take the sphere very near to the "eye"......
I really don't understand. Doesn't the bang to the gemhead provoke a
full render of everything just the same as it is rendered when a new
frame occurs? Then why is the scene rendered differently when I do the
bang????
I guess this could be further isolated to something regarding the bang
to gemhead, i.e. without involving pix_snap; of course with a "fast"
enough to see what happens during a single extra frame....
Thanks in advance
By the way, thanks to all who gave me example patches some days ago
which have helped me building this patch.
m.
--
Matteo Sisti Sette
matteosistisette(a)gmail.com
http://www.matteosistisette.com
#N canvas 702 93 635 593 12;
#X obj 304 560 gemwin;
#X msg 377 514 destroy;
#X obj 192 96 gemhead;
#X obj 192 131 t a a a;
#X obj 460 217 separator;
#X obj 461 336 square 3;
#X obj 189 256 rotateXYZ 0 0 0;
#X floatatom 347 67 5 0 0 0 - - -;
#X obj 190 184 separator;
#X obj 461 303 pix_texture;
#X obj 43 260 separator;
#X obj 198 400 color 1 0 0;
#X obj 198 425 sphere 1;
#X obj 198 368 translateXYZ 0 0 1;
#X msg 272 487 dimen 400 400 \, create \, 1;
#X obj 41 567 pix_snap 400 400;
#X obj 32 34 bng 30 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 84 382 t b b;
#X msg 81 427 1;
#X obj 42 459 spigot;
#X obj 41 496 t a b;
#X msg 109 462 0;
#X text 306 696 ========;
#X obj 39 530 t a b;
#X obj 41 611 pix_texture;
#X obj 38 312 pix_separator;
#X obj 460 246 pix_separator;
#X obj 460 276 color 1 1 1;
#X obj 186 220 pix_separator;
#X obj 180 38 t b;
#X text 199 74 <== connect this;
#X connect 1 0 0 0;
#X connect 2 0 3 0;
#X connect 3 0 10 0;
#X connect 3 1 8 0;
#X connect 3 2 4 0;
#X connect 4 0 26 0;
#X connect 6 0 13 0;
#X connect 7 0 6 2;
#X connect 8 0 28 0;
#X connect 9 0 5 0;
#X connect 10 0 25 0;
#X connect 11 0 12 0;
#X connect 13 0 11 0;
#X connect 14 0 0 0;
#X connect 15 0 24 0;
#X connect 16 0 17 0;
#X connect 17 0 29 0;
#X connect 17 1 18 0;
#X connect 18 0 19 1;
#X connect 19 0 20 0;
#X connect 20 0 23 0;
#X connect 20 1 21 0;
#X connect 21 0 19 1;
#X connect 23 0 15 0;
#X connect 23 1 15 0;
#X connect 24 1 9 1;
#X connect 25 0 19 0;
#X connect 26 0 27 0;
#X connect 27 0 9 0;
#X connect 28 0 6 0;
Hello,
Can anyone try the latest Purity Debian package I have done ?
It works on Ubuntu 8.04 (LTS) and up and should work on Debian.
http://bitbucket.org/aalex/purity/downloads/python-purity_0.2.4_all.deb
Thomas : Yes, I guess I should check out py/pyext to make this syntax
similar to the one in pyext. Note that Purity wraps PD, as opposed to
being an external within PD.
Cheers !
a
2009/10/21 Thomas Grill <gr(a)grrrr.org>:
>> I guess I am looking for something like:
>>
>> for i in range(20000):
>> Â obj1 = pdobj.osc~(i)
>> Â obj2 = pdobj.throw~("bus-1")
>> Â pdconnect(obj1 0, obj2 0)
>> obj1 = pdobj.receive~("bus-1")
>> obj2 = pdobj.dac~
>> pdconnect(obj1 0, obj2 0 1)
>>
>> and then call this script from within pd itself, hehe...
>
> If you remember the pd convention in Graz, that was exactly what my
> talk was about - the dyn api that i introduced - also available as a
> module for py/pyext. It's still there, in the svn - as soon as my
> server is back up again.
> gr~~~
>
--
Alexandre Quessy
http://alexandre.quessy.net
All,
The Visual Arts Program is looking for a 'new media' person to fill a tenure
track position. Anyone with solid experience creating and teaching
interactive art will have a serious advantage in getting this job.
International applicants are welcome and most of the faculty is European
already. Note that this is not the Media Lab, but a fine arts program in
the same school.
http://visualarts.mit.edu/resources/jobs.html
Don't bother applying for the full time staff position - I took that one.
Hi,
I've found this question already asked in the archives, but not the answer.
Is there a way, in gem, to get the current size of the gemwin? Taking
into account that it could be changed by the user by just dragging its
borders, after its creation.
Thanks
m.
--
Matteo Sisti Sette
matteosistisette(a)gmail.com
http://www.matteosistisette.com
Buenas
i'm trying to get infos about various blobs detected by pix_mulitblob.
but so far i could get the infos of various blobs only consecutively and
not at once.
is this a peculiarity of pix_multiblob?
anyone has different experiences?
thanks for hints
olsen
--
ETs DNA will not be televised
Dear fellow FOSS enthusiasts,
This is probably already old news according to Internet standards but as it
turns out we spent a good time this evening in class not knowing that we got
slashdotted. For those interested in belatedly joining the discussion,
please visit:
http://entertainment.slashdot.org/story/09/12/03/2018253/Introducing-L2Ork-W
orlds-First-Linux-Laptop-Orchestra
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
> I've certainly used patches with
> 500-1000 abstraction instances without problem, I guess I
> haven't tried 4600.
I wouldn't be surprised at all if the "limit" (i.e. the point where
things begins not working) were somwhere between the two numbers.
I had a lot of problems with very big patches, and a lot of times things
that worked perfectly fine with a "dimension" N stopped working with
N+1, where by "dimension" I mean just the "quantity of things" (e.g.
instances of a same abstraction), without the smallest change in
"complexity".
In some cases some developer (I won't tell the name, but it's someone
very important here) was able to find specific bugs and fixed it and
published a new release.
Unfortunately PD becomes somewhat unreliable if not unstable, when
patches get really big. That's very frustrating, because the way it is
'defined' (i.e. the way it is supposed to work) really allows beautiful,
complex, scalable design; but the implementation doesn't support it at
the end. Also, these kind of bugs are very difficult to isolate.
The greatest frustration is when you carefully design something so that
size (e.g. number of instances) shouldn't be a problem, you strongly
test it within a certain 'size' and verify it is rock-solid, and then,
when you have everything working and your project grows a little bit and
you just add a couple more instances of something, it stasrts crashing....
--
Matteo Sisti Sette
matteosistisette(a)gmail.com
http://www.matteosistisette.com
When:
December 4, 2009 at 8 p.m.
Where:
Oscar Peterson Concert Hall - 7141 Sherbrooke St. W. Montreal (take the
105 bus from Metro Vendome)
Cost:
Admission is free of charge. Everyone welcome.
60X60 DANCE CANADA is a project containing 60 solo choreographies to 60
electroacoustic pieces by 60 Canadian composers, each piece 60 seconds
or less in duration. The pieces are sequenced together without pause to
form an exactly one hour long performance. The sound will be projected
in multichannel through 8 loudspeakers, and the dance and music will be
accompanied by live video projection of an analog clock, spectrographic
images, and dance footage. This event is the third (and biggest) of the
Canadian 60x60 Dance, organized by Eldad Tsabary, Violaine Morinville,
Tim Sutton, and Rob Voisey. Through this inter-artistic hour-long
collaborative creation, 60x60 seeks to support and highlight the
contemporary art community. This show is presented in collaboration with
the Canadian Electroacoustic Community (CEC).
Information and poster here:
http://60x60.yaeldad.com/60x60danceCanada.pdfhttp://finearts.concordia.ca/newsandevents/events/60x60-dance.php
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com