Peggy Sylopp wrote:
the 3rd inlet of [newWave] is the "height" inlet. alternatively (but why would you want to do that?) you could use [scaleXYZ 1 1 0.1] ;-)
When I use scale, the wave doesn't move any more.
this seems like you are scaling by "0" (which flattens the surface) (btw, there is a difference between [scale] and [scaleXYZ])
The height inlet I tried before, with value 1 the spike is still very high, it seems it doesn't have enough influence. It seems floats aren't accepted.
the default height value is "1", so using "1" should not make much difference. on my system floats work fine, but since you have problems with both [scaleXYZ] and floating-point height values, please check whether floats work at all.
Does the third value if 'position' have an influence, sometimes it seems like?
yes it does (however, using "height" is something different than modifying the z-value of "position"; the former just scales the z-values of all surface points)
Sometimes the texturing with a video doesn't work, and pd crashs.
It seems to depend on the codec I use, for example cinepak doesn't work, but its installed on the system. In all video and 3D programms I know (After Effects, Combustion, Premiere, 3D Studio Max, Cinema 4D, visualJockey) the installed codecs are working. What codecs do work, what does it depend on?
so you are using w32 ? good to know... the video-decoding API Gem is using on w32(!) is rather old and thus does not support all the "newest" codecs. however, you can use AVISynth or some other frameserver (i have only tried AVISynth) to do the actual decoding.
I tried i! t with Pd version 0.38.0, but the newWave-patch didn't work. how does it not work ?
It simply doesn't show waves or they don't move, only when starting the patch a big resonance elongation, which explodes the surface.
that is very weird, because i don't think there is anything that would explain the different behaviour on various pd-versions (the only thing that comes to my mind is, that you are probably loading another version of Gem when using pd-0.37)
mfg.a.dr IOhannes
Hi Peggy,
It seems floats aren't
accepted.
floats are working fine on my installation of GEM (0.90.1) with pd 0.37 / 0.38.4 on win2k. I agree that the default height values are pretty high, I found values ranging from .01 to 0.3 useful.
Sometimes the texturing with a video doesn't
work, and pd crashs.
It seems to depend on the codec I use, for example
cinepak doesn't work,
as johannes already stated, gem's codec support under windows is a bit oldschool. gem does not use the direct show api, which is pretty much the standard nowadays. so if you have a specific direct show codec installed that is working with other applications, you cannot take it for granted that this codec will also work with gem. codecs that are definitely working are indeo (version 3.2, all others don't!) and huffyuv lossless. The former produces bad-looking clips and does start to stutter if you're using frame rates higher than 25 fps. huffyuv is okay quality-wise, also seeking works fine, but playing more than 3 clips simultanously pretty much maxes out even recent cpus. mpeg4 (xvid, divx) is a no-go, since seeking in these files produces funny-looking artifacts if you don't hit a key frame. avisynth is worth a look, but then again, it is not possible to produce an avs script from within pd (unless you are using an external scripting language like python) - so you have to create them manually. they should look something like
[myscript.avs) directshowsource("\path\andnameofyourclip.avi") converttorgb32
gem handles those faked avis quite fine, although seeking does take a long time.
having said all this, you should also note that newWave tends to screw up textures quite badly - see http://lists.puredata.info/pipermail/pd-list/2005-04/027464.html
hope this helps (and doesn't discourage you from using gem - it's till great!), thoralf.
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Can anyone see what the problem here is, it should output a bang when it receives a 12 and then reset the counter?
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
#N canvas 175 299 452 302 10; #N canvas 87 293 452 302 reset 1; #X obj 176 85 + 1; #X floatatom 107 139 5 0 0 0 - - -; #X obj 98 13 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1 ; #X obj 104 52 metro 500; #X obj 139 190 select 12; #X msg 213 49 0; #X obj 106 85 f; #X obj 136 239 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X connect 0 0 6 1; #X connect 1 0 4 0; #X connect 2 0 3 0; #X connect 3 0 6 0; #X connect 4 0 5 0; #X connect 4 0 7 0; #X connect 5 0 6 1; #X connect 6 0 1 0; #X connect 6 0 0 0; #X restore 96 76 pd reset;
hi rory,
execution order :-)
in your patch, it is undetermined whether the "+ 1" branch of your patch gets processed before the "select 12" one or the other way round. In the latter case, your check gets processed before the "+ 1" statement, which renders it useless. inserting a "trigger f f" makes your patch determined, see the attached version ...
with kind regards, thoralf.
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Cheers, that about the millionth time I have made that mistake! Rory.
--- Thoralf Schulze thoralf_schulze@yahoo.de wrote:
hi rory,
execution order :-)
in your patch, it is undetermined whether the "+ 1" branch of your patch gets processed before the "select 12" one or the other way round. In the latter case, your check gets processed before the "+ 1" statement, which renders it useless. inserting a "trigger f f" makes your patch determined, see the attached version ...
with kind regards, thoralf.
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com